Skill kiểm chứng

Khi project của bạn lớn dần, bạn bắt đầu nhận ra cùng một việc lặp đi lặp lại. Bạn đã biết skill là cách tốt để tự động hoá việc lặp lại. Trong bài này, ta sẽ xem một công việc cụ thể mà skill rất hợp: kiểm chứng chính công việc của bạn. Nếu chỉ xây một skill đầu tiên, hãy để đó là skill này.

Vì sao skill kiểm chứng nên được xây trước tiên

Hãy nghĩ về cách bạn thường kiểm tra kết quả của Claude. Bạn yêu cầu nó refactor gì đó, nó xong việc, rồi bạn phải nhớ để kiểm tra lại lần nữa. Có thể bạn yêu cầu nó chạy test. Có thể bạn tự đọc diff. Vấn đề là việc kiểm tra phụ thuộc vào việc bạn nhớ để yêu cầu nó. Chỉ cần bỏ qua bước đó một lần, code lỗi sẽ lọt qua.

Một skill kiểm chứng loại bỏ sự phụ thuộc đó. Đây là hình dạng của nó: bạn yêu cầu Claude refactor gì đó. Khi xong, thay đổi khớp với mô tả của skill, nên skill tự động kích hoạt. Từ đó nó:

• Chạy bộ test.
• Đọc diff.
• Kiểm tra xem có test nào bị làm yếu đi chỉ để pass hay không.
• Báo cáo pass hoặc fail, kèm bằng chứng đính kèm.

Toàn bộ quy trình chạy mà không cần bạn yêu cầu. Mô tả (description) trên skill chính là thứ kích hoạt nó, và một khi được kích hoạt, nó luôn đi qua đúng các bước như nhau mỗi lần.

Hãy để ý bước kiểm tra cuối cùng trong chuỗi đó. Chỉ chạy test và thấy màu xanh là chưa đủ. Một test có thể bị nới lỏng một cách âm thầm để nó pass bất kể thế nào. Vậy nên skill đọc diff và xác nhận không có test nào bị làm yếu đi. “Xong” không phải là “code trông có vẻ ổn” qua việc chỉ đọc diff. “Xong” là các cổng kiểm tra (gate) đã thực sự được chạy và quan sát, với kết quả được nêu rõ ràng.

Hình dạng này áp dụng cho bất kỳ quy trình nào team bạn lặp lại: một checklist release, một công thức migration, một bước kiểm tra trước-PR. Quy tắc chung: nếu bạn đã gõ cùng một chỉ dẫn nhiều bước hai lần, đó chính là một skill.

Một thư mục skill chứa được nhiều hơn chỉ chỉ dẫn

Một skill không chỉ là một file skill.md đơn lẻ. Thư mục xung quanh nó có thể chứa nhiều thứ khác, và đây chính là điều làm skill trở nên mạnh mẽ cho việc kiểm chứng.

• Đặt một file reference.md bên cạnh skill để chứa tài liệu chi tiết, rồi liên kết tới nó từ skill.md. Claude chỉ đọc file này khi thực sự cần độ sâu đó. File chính của bạn vẫn ngắn gọn.
• Đặt cả script vào thư mục này. Claude sẽ thực thi chúng thay vì nạp nội dung vào ngữ cảnh. Nghĩa là một skill có thể mang theo cả công cụ riêng, như một check.sh chạy toàn bộ các cổng kiểm tra.

Điểm mấu chốt: giữ chính skill.md thật gọn. Đẩy phần nội dung nặng - các giải thích dài và các script thực thi - sang các file phụ. File gọn mô tả phải làm gì; các file phụ chứa độ sâu và công cụ.

Bề mặt chỉ dẫn nào sở hữu quy tắc nào

Đến giờ bạn đã có ba nơi để đặt chỉ dẫn, và rất dễ nhầm lẫn giữa chúng. Đây là cách phân biệt nhanh.

Các quy ước áp dụng mọi lúc - như quy tắc đặt tên hay file nằm ở đâu - thuộc về file CLAUDE.md. Các quy trình và tài liệu tham chiếu gắn với một loại tác vụ cụ thể thuộc về một skill.

Có một trường hợp thứ ba. Một quy tắc mà Claude không được phép bỏ qua thuộc về một hook, không phải hai loại trên. Vì CLAUDE.md và skill đều là chỉ dẫn mà Claude tuân theo, còn hook là code thực sự chạy. Nếu việc bỏ qua quy tắc là không thể chấp nhận, đừng để nó phụ thuộc vào việc tuân theo chỉ dẫn.

Tóm tắt

Một skill là một thư mục chứa skill.md bên trong: một cái tên, một mô tả (description) kích hoạt nó, và bản thân quy trình. Chỉ có phần mô tả được nạp vào ngữ cảnh cho tới khi skill thực sự cần dùng, nên không tốn chi phí gì khi đóng gói mọi quy trình bạn lặp lại.

Hãy bắt đầu với việc kiểm chứng. Xây skill đó, check nó vào .claude/skills của project, và giờ cả team thừa hưởng cùng một cách làm. Công việc của mọi người đều được kiểm tra theo cùng một cách, tự động, mà không ai phải nhớ để yêu cầu.

Xem thêm: Skills

Nguồn

Dịch từ bài giảng “Verification skills”, khóa Claude Code in Action trên Claude Academy.