Kỹ năng Mã Claude: Các tệp SKILL.md mà Mô hình thực sự gọi

Last updated: Ngày 28 tháng 6 năm 2026

Claude Code Skill là một thư mục chứa file SKILL.md mà agent chỉ kéo vào context khi nhiệm vụ khớp với nó. Tôi đã tạo skill đầu tiên của mình để ngừng dán cùng một checklist di chuyển cơ sở dữ liệu dài 200 từ vào mọi phiên làm việc. File đó hiện tiết kiệm cho tôi khoảng một giờ mỗi tuần.

Đây là bản tóm tắt ngắn gọn, sau đó là giải phẫu chi tiết: skill là gì, cách viết phần frontmatter và body của SKILL.md, mô hình quyết định kích hoạt skill như thế nào, và khi nào việc sử dụng skill là quá mức so với một prompt thông thường. Nếu bạn đã sử dụng Claude Code, bạn có thể triển khai skill đầu tiên trong vòng chưa đầy năm phút.

Trả lời nhanh: Claude Code Skill là gì?

Skill là khả năng tái sử dụng được mô hình kích hoạt và lưu trữ dưới dạng SKILL.md (cộng với các script hỗ trợ tùy chọn). Không giống như system prompt luôn được tải, skill chỉ được tải theo yêu cầu khi mô hình xác định nó liên quan đến yêu cầu của bạn. Bạn viết một tên gọi, mô tả khi nào nên sử dụng nó, và phần hướng dẫn body. Mô tả là trường quan trọng nhất, bởi vì đó là thứ mà mô hình đọc để quyết định có nên kích hoạt skill hay không. Các skill được lưu trữ cục bộ trong .claude/skills/ hoặc được triển khai từ một registry, cho phép một nhóm người dùng chia sẻ một cách thức chuẩn hóa để thực hiện các tác vụ di chuyển (migrations), đánh giá code review, hoặc phát hành.

Nếu bạn muốn tìm hiểu ngữ cảnh rộng hơn về CLI, hãy xem Claude Code ultimate guide for 2026 của tôi. Để biết cách skill khác với sub-agent luôn hoạt động, hãy đọc how I automated my workflow with Claude Code sub-agents.

Skill thực chất là gì và nó được cấu tạo từ những gì?

Skill là một thư mục. Tối thiểu nó cần là file SKILL.md. Tùy chọn, nó có thể đóng gói các script, template hoặc tài liệu tham khảo đi kèm với skill. Tài liệu về agent-skills của Anthropic mô tả skill là một bộ hướng dẫn và tài nguyên được đóng gói mà mô hình có thể tải khi thích hợp (docs.anthropic.com/en/docs/agents-and-tools/agent-skills).

Tôi xem skill như một subroutine (hàm con) có tên và phiên bản cho mô hình. Ba điều khiến nó khác biệt so với một prompt dài là:

1. Nó tùy chọn bật. Mô hình chỉ tải nó khi nhiệm vụ dường như khớp với mô tả.
2. Nó có phạm vi giới hạn. Bạn có thể đính kèm các file và script mà chỉ có ý nghĩa đối với khả năng đó.
3. Nó có thể chia sẻ. Thư mục này có tính di động giữa các dự án và đồng đội.

Bản thân CLI là mã nguồn mở và quy ước về skill được tài liệu hóa cùng nó trên GitHub (github.com/anthropics/claude-code), nơi tôi kiểm tra khi nào hành vi thay đổi giữa các phiên bản.

Cách cấu trúc file SKILL.md?

File này có hai phần: frontmatter YAML và body Markdown. Frontmatter cho mô hình biết khi nào chạy; body cho nó biết cái gì cần làm. Đây là cấu trúc mà tôi sử dụng.

---
name: safe-migration
description: Use when the user asks to create, modify, or roll back a database migration. Covers schema changes, down migrations, and verifying against the staging dump.
---

Phần body là Markdown thuần túy. Tôi giữ ba phần: một mục tiêu bằng một dòng, một quy trình đánh số, và một cổng "dừng lại và xác nhận" rõ ràng. Trường name phải khớp với tên thư mục. Trường description nên được viết cho mô hình, chứ không phải cho con người, vì vậy nó giống như một điều kiện kích hoạt (trigger condition).

Tôi đã thử nghiệm trực tiếp việc này. Với một mô tả mơ hồ như "giúp ích với cơ sở dữ liệu," skill đã kích hoạt đối với các câu hỏi SQL không liên quan. Sau khi tôi viết lại thành "Use when the user asks to create, modify, or roll back a database migration," độ chính xác khi gọi (invocation precision) tăng từ khoảng 60 phần trăm lên mức đáng tin cậy. Mô tả đang thực hiện việc định tuyến (routing), vì vậy hãy dành thời gian chỉnh sửa ở đó.

Khi nào nên biến thứ gì đó thành một skill?

Đây là câu hỏi tôi nhận được nhiều nhất. Quy tắc của tôi: nếu tôi đã dán cùng một khối hướng dẫn ba lần trong vòng hai tuần, và nó dài hơn một đoạn văn, thì nó trở thành một skill. Dưới đây là ma trận quyết định mà tôi thực sự sử dụng.

Trục thứ hai là chi phí. Mỗi skill được tải sẽ thêm tokens vào context, vì vậy một khối hướng dẫn lớn, luôn liên quan tốt hơn nên là bộ nhớ cấp dự án hoặc lệnh tùy chỉnh hơn là một skill. Skills tỏa sáng cho các chuyên môn có tính liên quan theo điều kiện.

Một trường hợp cụ thể mà tôi đã viết một skill: quy trình phát hành của chúng tôi yêu cầu cập nhật changelog, tăng ba file phiên bản (version files), gắn tag, và đăng tóm tắt lên Slack. Tôi đã viết nó một lần dưới dạng skill, và bây giờ khi tôi nói "cut a release" thì mô hình chạy toàn bộ checklist theo thứ tự. Một trường hợp cụ thể mà tôi không làm: việc refactor config file một lần duy nhất. Cái đó vẫn là prompt.

Mô hình kích hoạt skill hoạt động như thế nào?

Mô hình khiến các skill trở nên kỳ diệu là bạn không gọi chúng. Bạn mô tả công việc, và mô hình đọc mô tả của các skill có sẵn rồi kéo cái phù hợp vào. Điều này được tài liệu hóa trong docs chính thức của Claude Code (docs.anthropic.com/en/docs/claude-code).

Luồng hoạt động trông như sau:

1. Bạn nhập một yêu cầu bằng ngôn ngữ tự nhiên.
2. Mô hình thấy name và description của mỗi skill đã cài đặt.
3. Nó chấm điểm mức độ liên quan so với yêu cầu của bạn.
4. Body của skill chiến thắng (và các file đính kèm) được đưa vào context.
5. Mô hình thực thi các hướng dẫn.

Hệ quả thực tế: bạn phải viết description như thể bạn đang viết một mục nhập công cụ tìm kiếm cho mô hình. Bắt đầu bằng động từ và phạm vi kích hoạt. So sánh hai mô tả này:

• Yếu: "A skill for handling git things." (Một skill để xử lý các thứ liên quan đến git.)
• Mạnh: "Use when the user asks to squash, rebase, or split commits on the current branch. Produces an interactive plan before running any rewrite." (Sử dụng khi người dùng yêu cầu squash, rebase hoặc chia nhỏ commit trên nhánh hiện tại. Tạo ra một kế hoạch tương tác trước khi chạy bất kỳ thay đổi nào.)

Mô tả mạnh hơn đã nêu tên các động từ kích hoạt và rào chắn bảo vệ. Đó là điều làm cho việc gọi (invocation) đáng tin cậy. Nếu bạn đang kết nối các skill với nhau bằng tools, Claude Code MCP integration guide đề cập đến cách các external tool servers phù hợp cùng với các gói skill. Đối với giao thức cơ bản kết nối chúng, xem MCP and the model context.

Cách kích hoạt và debug một skill?

Kích hoạt chủ yếu là tự động, nhưng tôi có ba kỹ thuật cố ý để kiểm soát và gỡ lỗi.

• Cụ thể hóa. Nói "use the safe-migration skill" (sử dụng skill safe-migration) sẽ buộc nó phải chạy. Hữu ích khi mô tả mơ hồ.
• Liệt kê các skill đã cài đặt. Yêu cầu mô hình liệt kê các skill có sẵn và mô tả của chúng. Đây là cách tôi xác nhận một skill mới đã được đăng ký.
• Kiểm tra trace. Khi một skill kích hoạt sai, tôi đọc xem mô tả nào khớp và siết chặt từ ngữ kích hoạt.

Khi một skill không kích hoạt, nguyên nhân gần như luôn là do phần mô tả, chứ không phải vị trí file. Tôi viết lại câu đầu tiên để bắt đầu bằng "Use when..." (Sử dụng khi...) và thêm các động từ cụ thể. Điều đó khắc phục được vấn đề chín lần trên mười.

Đây là checklist gỡ lỗi tôi thực hiện theo thứ tự:

Skill so với sub-agent so với slash command

Ba thứ này thường bị nhầm lẫn, và mọi người liên tục gây nhầm lẫn chúng. Tôi giữ chúng thẳng bằng một sự phân tách đơn giản.

• Skill: Hướng dẫn được mô hình kích hoạt cộng với các file tùy chọn. Tốt nhất cho chuyên môn có điều kiện (conditional expertise).
• Sub-agent: Một instance Claude Code riêng biệt thực hiện công việc cô lập. Tốt nhất cho các tác vụ chạy dài song song. Bài viết sub-agent automation write-up của tôi đi sâu vào vấn đề này.
• Slash command: Một phím tắt bạn cố ý gõ. Tốt nhất cho những thứ bạn luôn muốn theo yêu cầu.

Skill là loại duy nhất trong ba loại mà mô hình tự chọn cho bạn. Đó là siêu năng lực và cũng là rủi ro của nó: một skill được mô tả sai sẽ lãng phí context một cách thầm lặng.

Cách chia sẻ skills và sử dụng registry?

Một skill chỉ là một thư mục, vì vậy về nguyên tắc việc chia sẻ rất đơn giản. Tôi thả thư mục đó vào .claude/skills/ trong repo và commit nó. Các đồng đội sẽ có nó khi clone. Đối với việc chia sẻ giữa các nhóm, cộng đồng duy trì các registry và công cụ chính thức trỏ đến các vị trí chung.

Thiết lập thực tế của tôi:

1. Giữ các skill dành riêng cho dự án trong repo, được version-control.
2. Giữ các skill cá nhân trong một dotfiles repo được symlink vào .claude/skills/.
3. Gắn phiên bản skill khi chia sẻ bên ngoài, vì việc thay đổi mô tả có thể làm thay đổi hành vi một cách thầm lặng.

Lời cảnh báo trung thực về việc chia sẻ: một skill mã hóa các giả định về stack của bạn. Một migration skill được viết cho Drizzle sẽ tự tin tạo ra output sai trong dự án Prisma nếu mô tả không bảo vệ phạm vi (guard the scope). Luôn nêu rõ framework và các rào chắn bảo vệ trong phần mô tả, và thêm bước "dừng lại và xác nhận" trước các hành động phá hủy. Tôi đã học được điều này một cách khó khăn khi một skill được chia sẻ chạy một rewrite phá hủy trên nhánh sai, vì vậy hãy coi mọi skill được chia sẻ là chưa đáng tin cậy cho đến khi phần mô tả của nó chứng minh điều ngược lại.

Image credits

• Black screen with code text overlay on a developer workstation — photo by Pixabay on Pexels
• Close-up of programming code on a monitor during development — photo by Christina Morillo on Pexels
• Laptop showing a code editor during software development — photo by luis gomes on Pexels