Bạn đã dùng Claude được một tuần và vẫn cứ gõ đi gõ lại cùng một thứ. Mỗi lần commit code, bạn lại dán ba quy tắc về định dạng commit. Mỗi lần viết tài liệu, bạn lại giải thích lại phong cách của mình. Claude làm tốt, rồi quên ngay khi cuộc trò chuyện kết thúc, và ngày mai bạn lại gõ tất cả từ đầu.
Một skill sẽ giải quyết vấn đề đó. Đó là một thư mục nhỏ bạn viết một lần, dạy Claude một quy trình làm việc vĩnh viễn, để nó áp dụng trong mọi phiên làm việc mà bạn không cần yêu cầu.
Đây là cách nó hoạt động, trong nháy mắt: một skill là một thư mục với một tệp bên trong. Claude luôn giữ một dòng tóm tắt về nó trong tầm nhìn, và chỉ tải toàn bộ hướng dẫn khi yêu cầu của bạn khớp. Đó là toàn bộ cơ chế.
Trong hướng dẫn này, chúng ta sẽ xây dựng một skill thực tế từ đầu: commit-messages, skill viết git commit theo đúng định dạng của bạn. Nếu bạn đã cài Claude và không có gì khác, bạn có thể làm theo từng bước.
Những gì bạn sẽ có được
Về cốt lõi, một skill là một thư mục với một tệp bắt buộc, SKILL.md. Ba thư mục tùy chọn sẽ xuất hiện sau khi skill phát triển:
1your-skill-name/2├── SKILL.md # Bắt buộc - tệp skill chính3├── scripts/ # Tùy chọn - mã thực thi4├── references/ # Tùy chọn - tài liệu tham khảo5└── assets/ # Tùy chọn - mẫu, v.v.
Bản thân SKILL.md có hai phần: một tiêu đề ngắn cho Claude biết khi nào nên dùng skill, và các hướng dẫn bên dưới cho Claude biết làm gì. Lý do cho sự phân chia này rất quan trọng. Claude đọc tiêu đề liên tục, vì vậy nó luôn biết skill tồn tại, nhưng nó chỉ tải hướng dẫn khi yêu cầu của bạn khớp. Hãy ghi nhớ sự khác biệt đó, bởi vì hầu hết mọi thứ khác trong hướng dẫn này đều xuất phát từ nó.
Tạo nó
Các skill nằm trong thư mục .claude/skills bên trong thư mục home của bạn, mà cả Claude Code và ứng dụng desktop đều đọc từ đó. Thư mục này bị ẩn và có thể chưa tồn tại, vì vậy cách nhanh nhất để tạo nó, cùng với thư mục skill của bạn, là một lệnh duy nhất.
Trên Mac, mở Terminal và chạy:
1mkdir -p ~/.claude/skills/your-skill-name
Trên Windows, mở PowerShell và chạy:
1New-Item -ItemType Directory -Force -Path "$HOME\.claude\skills\your-skill-name"
Tên thư mục không chỉ là hình thức. Claude sử dụng nó làm định danh cho skill, và một quy tắc định dạng khiến nhiều người vấp ngã hơn bất kỳ quy tắc nào khác:
- Sử dụng kebab-case: notion-project-setup ✔
- Không có dấu cách: Notion Project Setup ✖
- Không có dấu gạch dưới: notion_project_setup ✖
- Không viết hoa: NotionProjectSetup ✖
Bên trong thư mục đó, tạo một tệp có tên chính xác là SKILL.md và mở nó trong bất kỳ trình soạn thảo văn bản nào. Mọi thứ từ đây là những gì sẽ đi vào tệp đó.
Thiết kế nó trước khi viết
Các skill hoạt động tốt bắt đầu với hai quyết định, được đưa ra trước khi bạn viết một dòng nào trong tệp. Cả hai đều có vẻ có thể bỏ qua nhưng thực tế thì không.
Đầu tiên, quyết định chính xác khi nào skill nên kích hoạt. Viết ra hai hoặc ba tình huống thực tế bằng những từ ngữ mà người dùng thực sự sẽ gõ:
- "commit những thay đổi này"
- "viết thông điệp commit cho sự khác biệt này"
- "stage và commit"
Đây không phải là việc làm thừa. Những cụm từ này trở thành nguyên liệu thô cho mô tả và các bài kiểm tra sau này của bạn, và một skill được thiết kế mà không có chúng thường mơ hồ theo cách khiến nó không bao giờ kích hoạt.
Thứ hai, quyết định cách bạn biết nó hoạt động. Tiêu chí quan trọng nhất là liệu skill có tự động tải mà không cần bạn gọi tên nó hay không. Nếu bạn phải gọi nó thủ công mỗi lần, skill về mặt kỹ thuật vẫn chạy nhưng đã thất bại trong công việc thực sự của nó. Cũng đáng để theo dõi song song: liệu nó có hoàn thành nhiệm vụ mà không cần bạn sửa giữa chừng hay không, và liệu nó có cho bạn kết quả giống nhau qua các phiên làm việc khác nhau hay không.
Mô tả là yếu tố quyết định thành công
Trong tất cả mọi thứ trong tệp, mô tả trong tiêu đề làm việc nhiều nhất, vì nó là phần duy nhất Claude đọc khi quyết định có tải skill hay không. Hướng dẫn của bạn có thể hoàn hảo, nhưng điều đó không quan trọng, vì Claude sẽ không bao giờ đọc đến chúng nếu mô tả không khớp. Đây là nơi hầu hết các skill "không hoạt động" thực sự thất bại.
Một mô tả mạnh mẽ trả lời hai câu hỏi trong một câu: skill làm gì và khi nào Claude nên sử dụng nó. Nửa thứ hai là thứ mà mọi người thường bỏ qua.
Đây là sự khác biệt:
1# yếu - nói nó là gì, không cho Claude gì để khớp với yêu cầu2description: Giúp với git commits.34# mạnh - nêu tên những thời điểm nó nên kích hoạt5description: Viết thông điệp commit git theo định dạng Conventional Commits. Sử dụng khi người dùng yêu cầu commit thay đổi, viết thông điệp commit, hoặc stage và commit tệp.
Phiên bản yếu cho Claude biết skill tồn tại nhưng không bao giờ kết nối nó với bất kỳ điều gì bạn sẽ nói. Phiên bản mạnh nêu tên các cụm từ thực tế, vì vậy khi bạn gõ "commit những thay đổi này", Claude có thứ để khớp. Hãy đặt tên những từ ngữ mà người dùng thực sự sẽ sử dụng, giữ toàn bộ dưới 1024 ký tự và không đặt < hoặc > bên trong nó.
Khi một skill không kích hoạt, hầu như luôn là lỗi ở đây. Thêm các cách diễn đạt bạn thực sự sử dụng. Nếu bạn nói "lưu công việc của tôi" nhưng mô tả chỉ đề cập đến "commit", Claude không có cách nào để liên kết hai điều này. Và nếu điều ngược lại xảy ra, skill kích hoạt khi không nên, hãy thu hẹp mô tả hoặc thêm một bộ kích hoạt phủ định:
1description: Viết thông điệp commit git theo định dạng Conventional Commits. Sử dụng khi commit thay đổi. Không sử dụng để viết comment code hoặc tài liệu.
Có một cách nhanh chóng để kiểm tra công việc của bạn trước khi dựa vào nó. Hãy hỏi trực tiếp Claude:
"Khi nào bạn sẽ sử dụng skill commit-messages?"
Claude sẽ đọc lại mô tả của bạn bằng chính lời của nó. Nếu điều đó không khớp với thời điểm bạn thực sự muốn skill kích hoạt, bạn đã tìm ra vấn đề, và nó nằm ở mô tả, không phải ở hướng dẫn bên dưới.
Viết hướng dẫn mà Claude thực sự làm theo
Bên dưới tiêu đề là phần thân, bằng Markdown thuần. Đây là nơi quy trình làm việc thực sự của bạn sống, và hai thói quen phân biệt hướng dẫn Claude làm theo với hướng dẫn nó lặng lẽ bỏ qua.
Đầu tiên là cụ thể. Claude hành động theo hướng dẫn cụ thể và bỏ qua những hướng dẫn mơ hồ, vì vậy bạn càng chính xác, nó càng hành xử đáng tin cậy:
1# Tệ2Xác thực commit trước khi hoàn tất.34# Tốt5Chạy `python scripts/validate.py "<message>"`.6Nếu thất bại, sửa những điều sau:7- Loại không hợp lệ: sử dụng feat, fix, docs, refactor, test, chore8- Tóm tắt quá 60 ký tự: rút ngắn lại
Thứ hai là thứ tự. Claude ưu tiên những gì nó đọc đầu tiên, vì vậy một quy tắc bị chôn vùi ở cuối một tệp dài là một quy tắc dễ bị bỏ lỡ. Hãy đặt bất cứ điều gì không được phá vỡ ở đầu, dưới một tiêu đề báo hiệu nó:
1## Quan trọng2- Dòng tóm tắt luôn dưới 60 ký tự3- Chỉ sử dụng thì hiện tại: "add", không phải "added"
Cũng có một giới hạn về những gì ngôn ngữ có thể đảm bảo. Hướng dẫn được diễn giải, có nghĩa là Claude làm theo chúng tốt nhưng không giống hệt nhau mỗi lần. Khi một kiểm tra thực sự cần phải vượt qua mọi lần chạy, đừng mô tả nó bằng văn xuôi, hãy chuyển nó vào một script và để hướng dẫn chạy nó. Mã làm điều tương tự mỗi lần; một câu thì không. (Đó là mục đích của thư mục scripts/, sẽ được đề cập tiếp theo.)
Một cấu trúc hoạt động tốt trên hầu hết các skill trông như thế này:
1# Tên Skill23## Quan trọng4Các quy tắc quan trọng không được bỏ lỡ.56## Hướng dẫn7Từng bước, cụ thể và có thể hành động.89## Ví dụ10Đầu vào và đầu ra cụ thể. Claude sao chép ví dụ đáng tin cậy hơn là làm theo quy tắc.
Giữ tệp gọn nhẹ. Khoảnh khắc nó bắt đầu phát triển vượt quá hướng dẫn cốt lõi, đó là lúc chuyển chi tiết thừa ra ngoài, và đó chính xác là những gì các thư mục tùy chọn dùng để làm.
Scripts, references, assets
Mọi thứ cho đến nay tạo ra một skill cung cấp cho Claude hướng dẫn. Ba thư mục tùy chọn biến nó thành một skill cung cấp cho Claude công cụ, và đây là nơi skill làm những điều mà một prompt đơn thuần không thể.
scripts/ chứa mã Claude chạy, cho bất cứ điều gì cần chính xác. Thay vì tin tưởng Claude ước lượng bằng mắt xem commit có được định dạng đúng hay không, bạn đưa cho nó một script kiểm tra:
1# scripts/validate.py2import sys3msg = sys.argv[1]4types = ("feat", "fix", "docs", "refactor", "test", "chore")56if msg.split(":")[0] not in types:7 print(f"Invalid type. Use: {', '.join(types)}")8elif len(msg.split("\n")[0]) > 60:9 print("Summary too long (over 60 chars)")10else:11 print("OK")
Sau đó bạn bảo Claude sử dụng nó trong SKILL.md:
1Trước khi hoàn tất, chạy `python scripts/validate.py "<message>"`2và sửa bất cứ điều gì nó báo lỗi.
Bây giờ quy tắc định dạng được thực thi bởi mã chạy giống nhau mỗi lần, thay vì phụ thuộc vào Claude nhớ để kiểm tra.
references/ chứa tài liệu chỉ tải khi cần. Giả sử quy ước commit của bạn dài đến hai trang về phạm vi, chân trang và các trường hợp ngoại lệ. Đặt tất cả vào SKILL.md và nó sẽ tải mỗi lần commit, ngay cả một dòng. Thay vào đó, hãy chuyển nó vào một tệp tham khảo:
1your-skill-name/2├── SKILL.md3└── references/4 └── conventions.md
Và trỏ đến nó từ tệp chính:
1Để xem danh sách quy ước đầy đủ, hãy xem references/conventions.md
Claude mở tệp đó chỉ khi nhiệm vụ yêu cầu. Đây là toàn bộ lý do tại sao các skill vẫn rẻ để chạy: chi tiết nặng nề nằm trên đĩa cho đến khi thực sự liên quan, thay vì đi cùng trong ngữ cảnh mỗi lần.
assets/ chứa các tệp skill sử dụng trong đầu ra của nó thay vì đọc để hướng dẫn, như một mẫu, tệp cấu hình hoặc logo. Một skill commit không cần bất kỳ, nhưng một skill tạo báo cáo có thể giữ một template.md ở đây và điền vào mỗi lần, để mọi báo cáo có cùng cấu trúc.
Tổng hợp lại, ba thư mục này là sự khác biệt giữa một skill nói với Claude cách bạn làm việc và một skill trao cho Claude các công cụ chính xác để thực hiện công việc theo cách của bạn.
Điều duy nhất cần nhớ
Một skill không phải là dạy Claude một khả năng mới. Nó đã biết cách viết một commit. Cái skill làm là khiến nó thực hiện công việc theo cách của bạn, mỗi lần, mà không cần bạn giải thích lại.
Và khi một skill không hoạt động, nguyên nhân hầu như không bao giờ là hướng dẫn bạn đã vất vả viết. Đó là mô tả. Claude quyết định có tải skill hay không từ một dòng duy nhất đó, trước khi nó đọc công việc bên dưới. Làm đúng mô tả và mọi thứ bên dưới cuối cùng sẽ được sử dụng.
Nếu điều này hữu ích, hãy truy cập hồ sơ của tôi và theo dõi. Tôi viết về công nghệ, AI và các hệ thống thực sự hoạt động.
