# Toàn bộ hướng dẫn Skills của Anthropic trong 22 phút

[Mark Kashef](https://homus.dev/speakers/mark-kashef) · [Mark Kashef](https://homus.dev/orgs/mark-kashef)

> Đi qua bản hướng dẫn 33 trang của Anthropic về skill: anatomy, ba tầng progressive disclosure, viết description, năm design pattern, test và phân phối.

Topics: Skills, Coding Agents, Context Engineering

Canonical: https://homus.dev/talks/anthropics-full-claude-skills-guide-in-22-minutes

## 1. Bản hướng dẫn 33 trang và sáu chương

Mark Kashef mở đầu bằng một thông tin: vài tuần trước, team Anthropic phát hành một bản hướng dẫn dài 33 trang về đúng một tính năng mà người dùng Claude Code hoặc dùng rất ít, hoặc bỏ qua hoàn toàn: **skill**. Anh nói mình đã đọc hết từ đầu tới cuối, chứ không chỉ ném file cho một LLM đọc hộ. Trong video, anh sẽ đi qua từng pattern, từng "nugget" (mẩu kiến thức đáng giá), từng framework, và quan trọng nhất là từng lỗi mà bạn có thể tránh, để bạn lấy được toàn bộ phần tinh tuý của sáu chương mà không phải tự bỏ thời gian đọc.

![Trang bìa PDF The Complete Guide to Building Skills for Claude, trang 1 trên 33](https://homus.dev/photos/TzJecWCbex0-0003.jpg)

Trang bìa bản PDF "The Complete Guide to Building Skills for Claude" của Anthropic, mở trong trình duyệt: 33 trang, logo Claude ở góc dưới.

Nhưng anh nhấn mạnh rằng mình không chỉ tóm tắt lại. Anh đã vẽ diagram cho từng khái niệm trong cả sáu chương, và hứa rằng tới cuối video, bạn sẽ không bao giờ còn "skill issue" nữa (chơi chữ: "skill issue" trong tiếng lóng nghĩa là "do bạn kém", và cũng là tên bảng vẽ của anh).

Sáu chương Anthropic viết trong bản hướng dẫn lần lượt là:

- **Fundamentals**: nền tảng, skill là gì.

- **Planning and design**: lên kế hoạch và thiết kế skill.

- **Testing and iteration**: test và lặp để cải thiện.

- **Distribution and sharing**: phân phối và chia sẻ.

- **Patterns and troubleshooting**: các pattern và cách xử lý sự cố.

- **Resources and references**: tài nguyên và tài liệu tham khảo, chương khép lại bản hướng dẫn.

Phần lớn các diagram của Mark đi theo đúng trình tự đó. Trên màn hình, anh lật nhanh qua các trang bìa chương có minh hoạ riêng: "Fundamentals" trên nền xanh lá, "Testing and iteration" với hình cầu thang, "Patterns and troubleshooting" với dấu chấm than nằm giữa hai dấu ngoặc nhọn.

## 2. Anatomy của một skill: Claude tự onboard vào workflow của bạn

Mark chuyển sang bảng vẽ Excalidraw của mình, đặt tên là "Skill Issues". Diagram đầu tiên là anatomy, tức cấu tạo của một skill. Ở trung tâm là file `SKILL.md`, và quanh nó là một loạt thư mục hỗ trợ: `scripts/`, `references/` và `assets/`. Nhưng thứ nền tảng nhất, thứ bắt buộc phải có, chính là file markdown này.

![Diagram Anatomy of a Skill: thư mục your-skill-name chứa SKILL.md, scripts, references, assets](https://homus.dev/photos/TzJecWCbex0-0103.jpg)

"What Even IS a Skill?": thư mục `your-skill-name/` chứa `SKILL.md` (bắt buộc, "bộ não" của skill), cùng ba thư mục tuỳ chọn: `scripts/` cho code chạy được (ví dụ `process_data.py`, `validate.sh`), `references/` cho tài liệu chỉ nạp khi cần, `assets/` cho template và font. Cả thư mục là bộ hướng dẫn dạy Claude những workflow cụ thể.

Bên trong file markdown đó có một loạt cấu trúc cho Claude Code biết có nên dùng skill này hay không, và khi nào dùng.

Nếu tới đây bạn vẫn chưa thật sự hình dung skill là gì, thì bản TL;DR của Mark là: hãy coi skill như cách Claude tự onboard vào workflow riêng của bạn. Tự thân Claude Code đã rất thông minh. Nó viết được, phân tích được. Nhưng có thể trong dữ liệu huấn luyện của nó không có cách bạn làm việc, cách bạn tiếp cận vấn đề. Skill lấp vào chính chỗ thiếu đó, cái "skill issue" của Claude khi đụng tới cách làm riêng của bạn.

Nói cách khác, một skill gần như là một bản onboarding guide cho Claude Code về bất kỳ thứ gì bạn muốn nó dùng: một dịch vụ, một quy trình, một chuỗi các bước. Có nó rồi, bạn làm được mọi thứ mình muốn.

## 3. Ba tầng progressive disclosure, xem tận mắt bằng /context

Tiếp theo, Mark nói về "ba tầng phép màu sau tấm rèm": cách một skill được Claude dùng, quan sát và thực thi. Theo anh, tới hôm nay phần lớn người dùng Claude Code vẫn không biết chuyện này.

![Diagram The 3-Level Magic: Progressive Disclosure với Level 1 YAML Frontmatter, Level 2 SKILL.md Body, Level 3 Linked Files](https://homus.dev/photos/TzJecWCbex0-0203.jpg)

"Progressive disclosure: minimize tokens while maintaining expertise". Level 1 là YAML frontmatter, luôn được nạp vào system prompt (Always On). Level 2 là phần thân SKILL.md, nạp khi Claude nghĩ skill có liên quan (On Demand). Level 3 là các file liên kết, chỉ khám phá khi cần (Deep Dive). Đi xuống thì tốn ít token hơn ở tầng trên và chi tiết hơn ở tầng dưới.

### Level 1: YAML frontmatter

Ở tầng trên cùng là **YAML frontmatter**. YAML là viết tắt của gì thì không quan trọng, Mark nói. Chỉ cần biết nó là đoạn mở đầu của một file skill. Đoạn này rất quan trọng vì nó **luôn được nạp vào system prompt** mỗi khi bạn mở một phiên Claude Code mới.

Để cho thấy cụ thể hơn, Mark mở một phiên đang chạy, nơi anh đang build một project, và gõ `/context`. Với các bản cập nhật gần đây, toàn bộ MCP tool đã bị "tắt tiếng" để tiết kiệm context (trên màn hình là một danh sách rất dài các tool của Claude in Chrome và Supabase, ghi chú "loaded on-demand"). Bạn thấy anh có rất nhiều tool, và chúng chỉ được gọi khi cần.

![Kết quả /context trong terminal: danh sách Skills theo Project và User kèm số token mỗi skill](https://homus.dev/photos/TzJecWCbex0-0243.jpg)

Phần Skills trong kết quả `/context`: mỗi skill chỉ chiếm vài chục tới hơn trăm token, ví dụ `xlsx` 113 token, `doc-coauthoring` 111, `skill-creator` 60, `webapp-testing` 55 ở nhóm Project; nhóm User có `organize-chaos` 129, `n8n-workflow-architect` 82, `linkedin-carousel` 79.

Còn với skill, bạn thấy ngay ở đây: tất cả đều nằm trong context. Nhưng đó không phải cả skill. Đó chỉ là một mẩu cực nhỏ của skill, vừa đủ để Claude Code tự hỏi: có nên tìm hiểu xem skill này nói về gì, và có nên gọi nó không? Level 1 về cơ bản chỉ dựa vào **name** và **description**.

### Level 2: phần thân SKILL.md

Khi Claude Code tự tin hơn rằng skill này có thể khớp với task hay project trước mặt, nó đi xuống level 2. Đây là nơi nó đọc toàn bộ thông tin thủ tục và các chỉ dẫn cốt lõi.

### Level 3: các file liên kết

Nếu ở level 2 nó thấy "đúng rồi, đây chính là việc cần làm", nó mới đi tiếp xuống cây thư mục tới các file liên kết: mọi Python script, mọi thứ gắn với skill đó, những thứ làm cho skill thật sự chạy.

Mark gọi cách làm này là **just in time**: các phần chỉ được dùng đầy đủ khi Claude thấy thật sự cần phải đi xuống hết bộ context đó.

## 4. MCP cộng skill: phép so sánh căn bếp

Nhờ dùng skill, trong nhiều trường hợp bạn thậm chí có thể bỏ hẳn MCP server. Nhưng cũng có những tình huống mà dùng cả MCP lẫn skill cùng nhau mới hợp lý, và đó là lúc bạn có được những workflow "siêu năng lực". Cách nghĩ của Mark: MCP cung cấp **tool** cho Claude Code, còn skill cung cấp **công thức và quy trình** để dùng các tool đó.

![Diagram The Kitchen Analogy: MCP là căn bếp, Skills là sách công thức, kết quả là món ăn](https://homus.dev/photos/TzJecWCbex0-0420.jpg)

"MCP + Skills = Superpowers". Bên trái, MCP là căn bếp: nối Claude tới các dịch vụ, truy cập dữ liệu real-time, gọi tool, tức là Claude làm được GÌ. Bên phải, skill là cuốn công thức: dạy Claude workflow, gói sẵn best practice, hướng dẫn từng bước, tức là Claude nên làm THẾ NÀO. Kết hợp lại cho ra output nhất quán, đáng tin, đạt mức chuyên gia.

Để cụ thể hơn, anh dùng phép so sánh căn bếp. Nếu ta đang ở trong bếp, thì MCP là đôi tay thật sự nấu nướng, còn skill là công thức cho đôi tay đó biết dùng nguyên liệu nào, theo thứ tự nào, với lượng bao nhiêu. MCP nối Claude tới các dịch vụ khác nhau và cho nó tool để truy cập dữ liệu real-time; skill thì có thể hiểu là dạy cho Claude Code những workflow cụ thể, sờ nắm được.

Theo nhiều nghĩa, các file Python mà skill gọi tới có thể chính là thứ trước đây ta dựng thành một workflow end-to-end trên Make. Đó là lý do bạn thấy rất nhiều video YouTube hỏi: "Make.com chết rồi à? Zapier chết rồi à? Mọi thứ chết hết rồi à?". Bởi rất nhiều skill có thể đóng vai gần giống những workflow tự động hoá ngày trước.

## 5. Ba nhóm skill

Kéo dài phép so sánh căn bếp, Mark nói có ba "hương vị" cốt lõi của skill.

![Diagram Three Categories of Skills: Document and Asset Creation, Workflow Automation, MCP Enhancement](https://homus.dev/photos/TzJecWCbex0-0514.jpg)

Ba nhóm skill. Category 1, Document & Asset Creation: output nhất quán, chất lượng cao (PDF, slide, code, style guide gắn sẵn, checklist), ví dụ skill frontend-design. Category 2, Workflow Automation: quy trình nhiều bước có kiểm tra, template, tinh chỉnh lặp, phối hợp nhiều tool, ví dụ skill-creator. Category 3, MCP Enhancement: hướng dẫn workflow cho MCP, phối hợp các lệnh gọi MCP, gắn tri thức chuyên môn, xử lý lỗi sẵn, ví dụ sentry-code-review.

**Nhóm 1: tạo tài liệu và asset.** Mark dùng nhóm này khá nhiều cho mọi thứ liên quan tới PDF, bài thuyết trình PowerPoint hay file Excel. Mục đích là tạo ra output nhất quán, dự đoán được, chất lượng cao.

**Nhóm 2: tự động hoá workflow** (trên màn hình là "Workflow Automation", cho quy trình nhiều bước). Ý chính của Mark ở đây: mục tiêu của một skill là nó tiến hoá cùng với workflow của bạn. Ví dụ hay nhất là skill **skill-creator**, một "meta skill": nó cho Claude Code biết cách tạo ra skill tiếp theo, khi bạn muốn "kết tinh" (crystallize) một quy trình hay một cách làm cụ thể.

**Nhóm 3: tăng sức cho MCP.** Theo Mark, nhóm này bị dùng quá ít. Nó giúp bạn lấy được phần tốt nhất của MCP server và bỏ hết phần thừa, bằng cách nói rõ cho Claude phải gọi MCP server thế nào và dùng tool nào theo thứ tự nào.

## 6. Nhóm thứ ba: bó hẹp MCP server và ví dụ Sentry

Thay vì cứ "YOLO" các lệnh gọi MCP server, ví dụ tới Supabase hay Vercel để tạo database, sửa một bảng, rồi để Claude tự mò dọc đường, thì một khi bạn đã tìm ra cách làm, hoặc Claude đã tự tìm ra một lần, bạn hãy kết tinh quy trình đó lại.

Cách làm Mark gợi ý về cơ bản là một **reverse metaprompt**: bạn nói với Claude đại ý "hãy đi lại toàn bộ quá trình mà chúng ta vừa trải qua, kết tinh chính xác cách bạn đi từ A tới B, bỏ qua mọi nhiễu, và chốt tất cả vào một skill". Từ đó về sau, bạn luôn gọi được skill đó và biết chính xác những thủ tục nào đã được làm theo để tới được kết quả cuối.

Quay lại ví dụ terminal với các MCP server: thay vì để Claude nạp toàn bộ MCP server rồi lần lượt thử từng tool một, bạn có thể nói thẳng: khi gọi Supabase MCP server, tôi chỉ cần bạn làm quen với việc dùng `create_project`, `list_extensions`, `get_logs` và vài tool tương tự. Như vậy bạn còn bó hẹp được phạm vi dùng MCP đó, và một lần nữa giữ context window gọn nhất có thể.

Ý tưởng của nhóm MCP Enhancement: thay vì để Claude nạp và thử cả bộ tool của một MCP server, skill ghi lại đúng những tool cần dùng, theo thứ tự, cùng lý do chọn chúng.

Một ví dụ hay cho nhóm này là skill **Sentry code review**. Nếu bạn chưa biết Sentry, thì đó về cơ bản là một nền tảng monitoring, đặc biệt cho các lỗi xảy ra trên production của ứng dụng. Bạn có thể tạo một skill Sentry code review luôn biết chính xác khi nào phải vào Sentry, đọc toàn bộ error log, và hiểu điều gì đã xảy ra, vì sao. Và bạn áp được cách này cho đủ loại tình huống khác.

Mục tiêu thật sự, Mark nói, không phải là gọi MCP server một cách mù quáng. Mục tiêu là gắn thêm chuyên môn của bạn: chính xác vì sao bạn dùng nó, và vì sao nó nên tập trung vào những tool này thay vì những tool khác.

## 7. YAML frontmatter: phần quyết định skill sống hay chết

Phần tiếp theo, theo Mark, có lẽ là phần quan trọng nhất: ta "double click", tức đào sâu, vào thứ đã nhắc ở trên là YAML frontmatter. Nhớ lại, đó là level 1 trong ba tầng của một skill, và là phần Claude Code luôn luôn nhìn vào.

Hai câu hỏi chính mà phần này phải trả lời thật hoàn hảo là:

- Skill này làm gì?

- Khi nào cần gọi nó?

![Diagram YAML Frontmatter Anatomy với ví dụ project-sprint-planner](https://homus.dev/photos/TzJecWCbex0-0714.jpg)

"The YAML That Makes or Breaks You". Bên trái: `name` chỉ dùng kebab-case, không khoảng trắng, không chữ hoa, phải trùng tên thư mục. Bên phải: `description` là trường quan trọng nhất, phải nói skill làm gì và KHI NÀO dùng (trigger phrase), dưới 1024 ký tự, không có thẻ XML. `license` và `metadata` (author, version, mcp-server) là tuỳ chọn. Góc dưới ghi lưu ý bảo mật: không dấu ngoặc nhọn, không dùng chữ "claude" hay "anthropic" trong tên. Dòng cuối: phần này xuất hiện trong system prompt của Claude, hãy viết cho đúng.

Ví dụ trên diagram, chép nguyên văn:

```
---
name: project-sprint-planner
description: Manages Linear project workflows
including sprint planning, task creation, and
status tracking. Use when user mentions "sprint",
"Linear tasks", "project planning", or asks to
"create tickets".
license: MIT
metadata:
author: TeamHub
version: 1.0.0
mcp-server: linear
---
```

Phóng to vào chi tiết, bạn thấy `name` được viết theo kiểu gọi là **kebab case**: chữ thường, các từ nối bằng dấu gạch ngang. Tên này nên là một mô tả rất rõ nghĩa, dài từ một tới bốn từ.

Còn **description** mới là nơi phép màu nằm. Đây là chỗ bạn giải thích skill là gì. Trong ví dụ, nó viết: quản lý workflow của project trên Linear, bao gồm sprint planning, tạo task và theo dõi trạng thái. Rồi tới "nugget" vàng thêm vào: bạn nên đưa ra các **keyword** hay **trigger word** để skill được gọi.

Đó là một tấm "cheat sheet", một gợi ý thêm cho Claude Code bám vào. Trong ví dụ này, bạn có thể viết: dùng khi người dùng nhắc tới sprint, Linear task, project planning, hoặc yêu cầu tạo ticket. Và vì Claude Code rất thông minh, nó còn tìm được những thứ **tương tự về ngữ nghĩa** với "create tickets". Nếu bạn nói "tạo các task rồi ghi lại", nhiều khả năng câu đó sẽ gần nghĩa nhất với trigger word này. Nhưng hiển nhiên, nếu bạn dùng đúng trigger word, thì gần như chắc chắn 100% skill sẽ được gọi.

Ngoài những điều đó, đây là phần bạn thật sự phải làm cho thật chuẩn. Một khi đã làm xong, và miễn là description dưới một nghìn ký tự (diagram ghi chính xác là dưới 1024 ký tự), thì mọi thứ còn lại chỉ là chuyện bạn thiết kế phần script và các phần khác của skill ra sao.

## 8. Description tồi và description tốt

Mark đưa ra ba ví dụ description tồi:

- **"Helps with projects."** (Giúp với các project.) Gần như skill nào cũng có thể "giúp với các project". Quá mơ hồ, Claude sẽ không biết khi nào phải gọi.

- **"Creates sophisticated multi-page documentation systems."** (Tạo các hệ thống tài liệu nhiều trang tinh vi.) Ở đây không có trigger thật sự nào cho biết chính xác khi nào skill nên được gọi. Không có câu nào người dùng thật sẽ nói.

- **"Implements the Project entity model with hierarchical relationships."** (Hiện thực hoá mô hình thực thể Project với các quan hệ phân cấp.) Thứ nhất, rất kỹ thuật, rất nhiều buzzword. Nó giống một tư vấn viên từ một hãng tư vấn lớn nói một tràng "word salad", nghe nhiều chữ mà chẳng nói được gì. Người dùng không nói chuyện kiểu đó.

![Diagram Description Field: Make or Break, ba description tồi bên trái, ba description tốt bên phải, công thức ở dưới](https://homus.dev/photos/TzJecWCbex0-0930.jpg)

"Description field: make or break". Cột trái là ba description tồi với lý do: quá mơ hồ, thiếu trigger, quá kỹ thuật. Cột phải là ba bản tốt, lần lượt nhấn vào "Specific + trigger phrases", "Actions + user language" và "Clear outcome + triggers". Ô cuối là công thức: WHAT it does + WHEN to use it + KEY trigger phrases = Perfect Description.

Bạn muốn skill của mình thật gọn và đi thẳng vào việc. Cách sửa từng câu:

- Thay "helps with projects" bằng một câu như: phân tích file thiết kế Figma và tạo tài liệu bàn giao cho developer; dùng khi người dùng upload file `.fig`, hỏi design spec hoặc cần bàn giao từ design sang code.

- Thay "create sophisticated systems" bằng: quản lý workflow project trên Linear, gồm sprint planning; dùng khi người dùng nhắc tới "sprint", "Linear tasks" hoặc "create tickets".

- Và cái cuối, "implements the project entity model", thì ta không muốn. Thay vào đó: onboarding khách hàng end-to-end cho PayFlow; dùng khi người dùng nói "onboard new customer" hoặc "set up subscription".

Càng có nhiều trigger word, kể cả cho những phần khác nhau của quy trình trong skill, thì càng tốt. Bản "TL;DR của TL;DR" mà Mark chốt lại: **skill làm gì + khi nào dùng + các trigger phrase chính = một description hoàn hảo**.

Và hiển nhiên, bạn không phải tự tay viết những thứ này. Bạn chỉ cần mô tả bằng tiếng Anh thông thường, bằng tiếng lóng, bằng bất kỳ ngôn ngữ nào bạn nói, rồi bảo Claude tự tạo skill, vì theo Mark, prompt engineering giờ đã là một bài toán được giải xong hoàn toàn.

## 9. Mở file ví dụ: trigger theo sự kiện, over-triggering và MCP

Như đã hứa, Mark mở vài file ví dụ. File `comparison_descriptions.md` đặt từng cặp description tồi và tốt cạnh nhau, mỗi cặp kèm lý do vì sao nó thất bại hay thành công. Mở đầu file ghi rằng description là trường quan trọng nhất trong skill, quyết định Claude nạp hay bỏ qua skill của bạn, cùng công thức WHAT + WHEN + KEY trigger phrases. Cặp 1 (Project Management) chính là cặp anh vừa cho xem trên diagram.

### Cặp 2: xử lý dữ liệu

Bản tồi viết như sau. Nó thất bại vì quá kỹ thuật và không có trigger word nào. Trong file còn ghi: chưa người dùng nào từng nói "tôi cần một multi-paradigm data transformation pipeline", nghe như tóm tắt một luận án tiến sĩ.

```
description: Implements a sophisticated multi-paradigm data
transformation pipeline with configurable ETL stages.
```

Bản tốt: làm sạch, kiểm tra và biến đổi file CSV để phân tích, dùng khi người dùng nói "clean this CSV", "fix my data" hoặc "prepare this spreadsheet for analysis".

```
description: Cleans, validates, and transforms CSV files for
analysis. Use when user says "clean this CSV", "fix my data",
"prepare this spreadsheet for analysis", or uploads a .csv
file that needs processing.
```

Mark chỉ vào phần được tô đỏ trên màn hình: "or uploads a .csv file". Trigger còn có thể là một **sự kiện**: nếu người dùng upload một file CSV, đó cũng là một trigger. Đây là một "nugget" thêm: trigger không nhất thiết lúc nào cũng phải là chữ, nó có thể là một event. Anh có cả loạt ví dụ như vậy và sẽ chia sẻ chúng (anh nói để ở link thứ hai trong phần mô tả video).

### Cặp 5: over-triggering

Có nhiều ví dụ khác, nhưng Mark muốn dừng lại ở cặp over-triggering vì một lý do riêng: bạn cũng có thể trigger quá đà, kể cả theo sự kiện. Nếu bạn viết "processes documents and analyzes data for business use", skill có thể bị gọi cho đủ mọi loại tình huống. File ghi: mọi prompt có dính tới bất kỳ tài liệu hay dữ liệu nào cũng sẽ kích hoạt nó; quá rộng, Claude sẽ nạp nó liên tục.

Bạn muốn càng chính xác càng tốt. Sửa lại thành phân tích thống kê nâng cao cho bộ dữ liệu CSV, chạy regression, clustering, hypothesis testing. Câu này cụ thể hơn nhiều về chuyện "xử lý tài liệu" thực ra nghĩa là gì. Bản tốt trên màn hình, chép nguyên văn:

```
description: Advanced statistical analysis for CSV datasets.
Performs regression, clustering, and hypothesis testing. Use
for statistical modeling and quantitative analysis. Do NOT use
for simple data exploration (use data-viz skill instead) or
general spreadsheet tasks.
```

Phần giải thích bên dưới trong file nhấn vào **negative trigger** ("Do NOT use..."): description vừa khoanh rõ phạm vi, vừa tự phân biệt mình với các skill liên quan. Vì tới một lúc nào đó, Mark nói, một skill quá rộng trở nên vô dụng: bạn chỉ đang dựa vào việc Claude Code tự diễn giải đâu là điều tốt nhất nên làm trong tình huống đó, vì bạn không đưa cho nó bất kỳ cheat sheet, hướng dẫn hay onboarding nào về cách tự làm việc đó.

### Cặp 6: một skill dựa trên MCP

Bản tồi: "Works with Sentry to look at errors" (làm việc với Sentry để xem lỗi). Theo file: hành động mơ hồ ("look at"), không có context workflow, không có trigger phrase. Bạn muốn cụ thể hơn nhiều. Bản tốt:

```
description: Automatically analyzes and fixes detected bugs in
GitHub Pull Requests using Sentry's error monitoring data via
MCP. Use when user says "review this PR for Sentry errors",
"check what Sentry says about this code", or "fix the bugs
Sentry found". Requires Sentry MCP server connected.
```

Giờ thì bạn có một thứ hữu ích hơn hẳn: workflow rõ ràng (phân tích PR, lấy dữ liệu Sentry, đề xuất cách sửa), trigger cụ thể, và ghi rõ phụ thuộc vào MCP. Hơn nữa, bạn còn có thể xếp thêm một lớp nữa: chỉ định skill nên gọi những tool và sub-tool nào của MCP đó, để giữ nó tập trung nhất có thể.

Ba công cụ để đưa description về đúng "sweet spot": trigger bằng câu người dùng thật sự gõ, trigger bằng sự kiện (như upload một file CSV), và negative trigger để skill không bị gọi tràn lan.

## 10. Năm design pattern: tuần tự và phối hợp nhiều MCP

Phần tiếp theo, theo Mark, là phần phức tạp và tinh tế nhất: Anthropic đi qua năm design pattern khác nhau, năm cách thiết kế để một skill thực thi theo một kiểu nhất định. Trên bảng vẽ, anh gọi chúng là "The 5 Power Patterns".

### Pattern 1: sequential workflow

Đây là pattern tuyến tính nhất: bạn đi từ bước 1 tới bước 4 theo một cách rất dễ đoán. Lấy một use case giả định quanh việc đăng ký tài khoản: đầu tiên tạo account, rồi thiết lập thanh toán, rồi tạo subscription, rồi gửi một email chào mừng. Phần phụ thuộc nằm ở chỗ bước sau cần lấy được customer ID và thông tin từ bước 1. Pattern này khá thẳng. Nếu bất kỳ bước nào thất bại, bạn rollback lại các bước trước.

![Diagram Pattern 1 Sequential Workflow: Create Account, Setup Payment, Create Subscription, Send Welcome](https://homus.dev/photos/TzJecWCbex0-1303.jpg)

Pattern 1, dùng khi có quy trình nhiều bước theo thứ tự cố định. Mỗi bước gọi một MCP tool: `create_customer` (name, email, company), `setup_payment_method` (chờ xác minh), `create_subscription` (dùng customer_id từ bước 1, được khoanh đỏ), `send_email` (template welcome_email). Mũi tên nét đứt "dependency" nối bước 3 về bước 1; ô cảnh báo ghi: bước nào lỗi thì rollback các bước trước.

### Pattern 2: multi-MCP coordination

Pattern thứ hai phức tạp hơn: phối hợp nhiều MCP. Bạn dùng nó khi workflow trải dài qua nhiều dịch vụ. Ví dụ ở phase 1 bạn dùng Figma MCP để làm phần thiết kế; rồi upload lên Drive MCP, tạo một thư mục project; rồi dùng Linear MCP để tạo task cho developer hoặc cho chính bạn; rồi chuyển sang Slack MCP để gửi một bản tóm tắt đầy đủ kèm loạt link.

Trên diagram, bốn phase lần lượt là Design Export (export design asset, tạo spec, tạo manifest), Asset Storage (tạo thư mục, upload asset, tạo link chia sẻ), Task Creation (tạo dev task, gắn link asset, giao cho team) và Notification (đăng tóm tắt bàn giao, kèm mọi link). Giữa các phase có các mũi tên ghi thứ được chuyển tiếp: "Assets + Specs", "Links + References", "Task IDs + Summary".

Đây là một chuỗi MCP khác nhau được điều phối theo một thứ tự cụ thể. Và trong trường hợp này, bạn không thể đi từ phase 1 sang phase 2 khi chưa có đủ điều kiện tiên quyết: diagram ghi rõ "Validation gate between each phase, verify before proceeding", tức mỗi phase có một cổng kiểm tra trước khi đi tiếp.

## 11. Pattern 3 và 4: vòng lặp tinh chỉnh và rẽ nhánh theo context

### Pattern 3: iterative refinement

Pattern thứ ba là tinh chỉnh lặp, và đây có lẽ là pattern Mark dùng nhiều nhất trong hệ sinh thái cá nhân của mình. Anh dùng nó cả cho việc tạo thumbnail:

- Đầu tiên, anh tạo một bản phác thumbnail ban đầu bằng Excalidraw, xác định chính xác thứ gì nằm ở phần nào của thumbnail.

- Rồi anh tạo năm, mười phiên bản khác nhau bằng Nano Banana.

- Rồi anh dựng vài agent để xem xét, audit và "roast" (chê thẳng tay) từng thumbnail.

- Rồi tinh chỉnh, và quay về với năm bản tốt nhất trong số 10 tới 15 bản đã tạo qua cả quá trình.

Pattern này hợp lý khi bạn cần đi qua vài lần tiến hoá cho tới bản cuối của bất kỳ thứ gì bạn đang muốn tạo ra. Trên diagram, vòng lặp gồm Initial Draft (lấy dữ liệu qua MCP, tạo bản nháp đầu, lưu), Quality Check (chạy script kiểm tra: thiếu phần nào, định dạng, lỗi dữ liệu), Refinement (xử lý từng vấn đề, tạo lại phần bị ảnh hưởng, kiểm tra lại), và khi "Quality OK?" thì sang Finalization (áp định dạng, tạo tóm tắt, lưu bản cuối). Một ghi chú màu cam nhắc: biết lúc nào dừng, sau 3 tới 4 vòng thì lợi ích giảm dần.

### Pattern 4: context-aware tool selection

Pattern thứ tư trông rất giống một workflow n8n, nơi cùng một đầu vào là một file gửi tới. Hãy tưởng tượng trong thế giới n8n, bạn có một form submission và người dùng upload một file. Nếu là PDF, nó được xử lý một kiểu. Nếu là file Excel, nó được xử lý kiểu khác.

![Diagram Pattern 4 Context-Aware Tool Selection: một file đến, kiểm tra loại và dung lượng, rẽ sang bốn nơi lưu](https://homus.dev/photos/TzJecWCbex0-1443.jpg)

Pattern 4, dùng khi cùng một kết quả nhưng tool khác nhau tuỳ context. File đến được "Check file type & size": lớn hơn 10MB thì sang Cloud Storage MCP, tài liệu cộng tác sang Notion/Docs MCP, file code (.py, .js, .ts) sang GitHub MCP, file tạm sang Local Storage. Nhánh nào cũng gắn metadata, tạo link truy cập và giải thích lựa chọn cho người dùng. Ô dưới cùng: "Transparency", luôn nói cho người dùng VÌ SAO chọn nơi lưu đó.

Bạn có thể thiết kế một skill theo đúng khuôn đó: khi có file được upload, skill kiểm tra loại file và dung lượng; nếu nhận ra đó là file code, có thể nó gọi GitHub MCP; còn nếu là một tài liệu cộng tác như file docx hay thứ tương tự, nó dùng Notion hoặc Docs MCP. Lúc này bạn đang điều phối cùng lúc vài tầng: bạn điều phối các MCP, và bạn điều phối việc cùng một skill đi theo nhánh nào tuỳ vào đầu vào.

## 12. Pattern 5: tri thức chuyên ngành gắn vào skill

Pattern cuối thật sự dành cho doanh nghiệp: **domain-specific intelligence**, tức trí tuệ chuyên ngành được gắn thẳng vào một skill. Hãy tưởng tượng toàn bộ hiểu biết về các codebase, thiết kế hạ tầng, mọi thứ khiến công ty vận hành trơn tru ở phía IT.

Đây là nơi bạn có các quy tắc gắn sẵn: một danh sách trừng phạt (sanctions list) để đối chiếu, bước xác minh khu vực pháp lý (jurisdiction verification), bước đánh giá mức rủi ro dựa trên chính xác điều gì đang diễn ra. Rồi bạn có một loạt logic ra quyết định. Tất cả những thứ này đều là của riêng bạn.

Cấu trúc pattern 5 như trên bảng vẽ: tầng trên là tri thức chuyên ngành mà bình thường con người phải cung cấp; tầng giữa là logic ra quyết định (qua compliance check thì chạy giao dịch với fraud check, không qua thì tạo compliance case và báo team); tầng dưới là audit trail, mọi quyết định đều được ghi lại.

Ví dụ của Mark: nếu bạn là chủ một doanh nghiệp chạy trên, giả sử, AWS, với một loạt microservice và database, thì skill này sẽ chỉ rõ cho Claude bạn dùng các microservice đó thế nào, service nào được phép sửa, và sửa chúng theo cách nào để khớp đúng với quy trình bình thường của bạn. Nói cách khác, SOP (quy trình chuẩn) bạn đưa cho một nhân viên mới thế nào, thì đó cũng chính là SOP cho pattern này.

## 13. Instruction mơ hồ và instruction chia bước

Sang phần instruction tốt và tồi, Mark có vài ví dụ trong file `comparison_instructions.md`. Cái đầu tiên anh cho xem là bản tồi, rất "hand-wavy" (khua tay cho có), chép nguyên văn:

```
## Instructions

Help the user with their data. Validate it and make sure everything
looks good. Process the data appropriately and handle any issues that
come up. Make sure to check for errors and fix them if possible.

When you're done, let the user know the results.
```

Mark gọi nó là tệ hại: rõ ràng là mơ hồ không tưởng. Phần "What's wrong" trong file chỉ ra từng chỗ: "Validate it" là kiểm tra thế nào, kiểm tra cái gì? "Process the data appropriately" thì "appropriately" nghĩa là gì? "Handle any issues" là những vấn đề nào, mỗi cái sửa ra sao? "Check for errors" là lỗi nào, thế nào thì tính là lỗi? Không có thứ tự bước, không có lệnh gọi tool cụ thể, không có ví dụ. Claude sẽ tự lấp chỗ trống bằng hành vi chung chung, mỗi lần chạy mỗi khác: có lần ổn, có lần bỏ sót những bước kiểm tra quan trọng.

Cách làm cho nó dễ hành động hơn nhiều là chia hẳn thành các bước. Rất nhiều skill Mark từng thấy, và những skill anh thiết kế cho chính mình, cho agency của anh và cho khách hàng, đều theo định dạng markdown này. **Step 1** là "Inspect the data" (xem xét dữ liệu), rồi bạn chia nhỏ chính xác việc xem xét dữ liệu trông như thế nào:

```
## Instructions

### Step 1: Inspect the Data

When the user provides a CSV file:

1. Read the first 10 rows to understand structure
2. Count total rows and columns
3. Identify column types (text, number, date, boolean)
4. Report findings:

"Your file has {rows} rows and {cols} columns.
Here's what I found:
- {col_name}: {type} ({null_count} missing values)
{issues_count} potential issues detected."
```

**Step 2** là "Identify Issues", xác định vấn đề. Ở đây, Mark gợi ý bạn có thể nhờ AI tạo một bảng theo cột, đi qua một decision framework hay một rubric. Trong file, bảng đó liệt kê từng vấn đề, cách phát hiện, và có tự sửa không: giá trị thiếu (ô rỗng, hỏi người dùng), dòng trùng (khớp nguyên dòng, tự sửa), ngày không nhất quán (nhiều định dạng trong một cột, tự sửa), khoảng trắng đầu và cuối (strip rồi so sánh, tự sửa), chữ hoa thường lẫn lộn trong category ("Active" và "active", tự sửa), và outlier (giá trị lệch quá 3 độ lệch chuẩn so với trung bình, chỉ đánh dấu).

**Step 3** có thể là "Apply Fixes", áp các bản sửa:

```
### Step 3: Apply Fixes

Run validation:
python scripts/validate_csv.py --input {filename} --checks all

For ambiguous fixes, ask the user:
"Column 'revenue' has 12 missing values. Should I:
(a) drop those rows, (b) fill with median, (c) fill with 0,
or (d) leave as-is?"
```

Và **Step 4** có thể là "Export Clean Data", nơi bạn nói rõ kỳ vọng của mình: file xuất ra mang tên theo dạng `{original_name}_cleaned.csv`, tức một cái tên được tạo động, và báo cho người dùng chính xác điều gì đã thay đổi (trên màn hình là ví dụ: đã xoá 23 dòng trùng, chuẩn hoá 4 định dạng ngày về YYYY-MM-DD, cắt khoảng trắng ở hai cột tên và email).

Khung bốn bước thay cho đoạn instruction mơ hồ: mỗi bước nói rõ phải làm gì, dùng script nào, hỏi người dùng khi nào và output trông ra sao.

Đây là chỗ bạn giữ thăng bằng: rõ ràng, tường minh, nhưng vẫn chừa một chút chỗ cho tính "động" của task đang làm.

## 14. Bộ ba bài test: triggering, functional, performance

Giờ bạn đã build xong skill. Test nó thế nào? Phần này, mà Mark đặt tên "Test Like a Pro", nói về ba cách test.

![Diagram The Testing Trifecta: Triggering Tests, Functional Tests, Performance Comparison](https://homus.dev/photos/TzJecWCbex0-1721.jpg)

"The Testing Trifecta". Section 1, Triggering Tests: có nạp đúng lúc không? Nên trigger với "Help me set up a new workspace", "Create sprint tasks", "Initialize project for Q4"; không nên trigger với "What's the weather?" hay "Help me write Python"; thanh trượt từ under-triggering qua sweet spot tới over-triggering. Section 2, Functional Tests: Given tên project và 5 task, When skill chạy, Then project được tạo, 5 task đúng thuộc tính, tất cả được liên kết, 0 lỗi API. Section 3, Performance Comparison: không có skill là 15 tin nhắn, 3 lệnh gọi lỗi, 12.000 token; có skill là 2 câu hỏi, 0 lỗi, 6.000 token (cải thiện 87%, 100%, 50%). Dòng dưới: lặp từ một task trước, rút ra pattern, rồi mở rộng phạm vi.

### Test 1: triggering test

Bài thứ nhất là triggering test: bạn mở một phiên terminal hoàn toàn mới. Từ khoá là "mới". Bạn không muốn dùng một phiên đang có, vì nó có thể bị context làm đục, và vô tình gọi skill chỉ vì nó biết là nó "nên" gọi.

Mark so sánh với chuyện cô bé Goldilocks nếm một bát súp quá nóng, một bát súp quá nguội, rồi tìm ra bát súp nhiệt độ vừa vặn. Ở đây cũng y như vậy: skill có thể under-trigger (gọi quá ít) hoặc over-trigger (gọi quá nhiều), và lý tưởng là bạn tìm được sweet spot, nơi tỷ lệ trúng rất cao, skill được gọi đúng khi hợp lý.

### Test 2: functional test

Bài thứ hai là functional test. Giả sử skill đã được gọi. Sau khi nó chạy hết mọi bước, bạn có thật sự nhận được output như mong đợi, theo đúng định dạng mong đợi, một cách deterministic, lần nào cũng như lần nào không? Một cách làm hay là "battle test" nó bốn, năm lần. Rồi thử nó với một agent team hay sub-agent, xem hành vi có đổi khi chạy trong những dạng khác nhau không. Nếu không đổi, tốt. Nếu có đổi, bạn bảo Claude Code lặp lại và sửa skill khi cần, cho tới khi được đúng hành vi bạn mong muốn.

### Test 3: performance comparison

Bài cuối có lẽ là bài nhiều người sẽ bỏ qua. Đôi khi bạn quá cam kết với việc dùng một skill tới mức không nhìn ra rằng, dựa trên test 1 và test 2, rốt cuộc có khi không có skill còn dễ hơn. Có khi skill gây thêm lỗi nhiều hơn là giúp. Vì vậy cần có một dạng benchmark nào đó để biết: skill này có giá trị không? Nếu có, nó nên tồn tại. Nếu không, có thể ta nên tạo một workflow tự động, một cron job, hay một file Python chạy toàn bộ quy trình theo cách rất tuyến tính.

## 15. Cấu trúc thư mục, battle test và lúc nào lên global

Giả sử skill có ích, thì bạn muốn chắc chắn nó được tổ chức đúng định dạng. Mark mở một thư mục ví dụ trong Finder: ví dụ tồi chỉ có tên skill (`data_processor`) và ngay bên trong là `SKILL.md`. Không có references, không có scripts, không có gì cả.

Một phiên bản tốt trông như thế này: một thư mục CSV data pipeline, trong đó có thư mục `references` chứa một file markdown mô tả các kiểu cột khác nhau trong CSV; thư mục `scripts` chứa các file Python mà skill gọi để thực thi việc cần làm; và ở thư mục chính là file `SKILL.md`. Các thư mục kia trở thành phần phụ thuộc, còn `SKILL.md` nằm ngay ở chính giữa, ở vị trí trung tâm.

Bản tồi chỉ có một file `SKILL.md` trơ trọi; bản tốt để `SKILL.md` ở trung tâm, tài liệu tham khảo trong `references/` và code chạy được trong `scripts/`.

Một khi đã có skill vững, lời khuyên của Mark là **đừng đưa một skill lên global cho tới khi bạn battle test nó xong hoàn toàn**. Mà battle test không có nghĩa là vài phút. Nó có nghĩa là chạy, có thể, cả tháng. Khi nó đủ tốt, tuỳ vào nơi bạn deploy, cho cá nhân hay cho cả tổ chức, đó là lúc hợp lý để nó "tốt nghiệp" thành một skill global: một thứ bạn có thể commit vào một repo để nơi khác nạp vào và dùng, một thứ dùng được không chỉ trong Claude Code mà cả trên Claude.ai, Claude Cowork ở phía giao diện, hay qua Claude API với Claude Agent SDK.

Diagram "Ship It!" của Mark tóm phần phân phối: thư mục skill (SKILL.md, scripts, references, assets) được đóng gói qua một GitHub repo public kèm README và ví dụ, hoặc nén thành file zip. Từ đó nó đi tới Claude.ai (vào Settings, Capabilities, Skills rồi Upload, mỗi người tự tải lên), Claude Code (đặt vào thư mục skills, dùng trong workflow CLI), hoặc API (endpoint `/v1/skills`, deploy bằng code, tương thích Agent SDK). Với tổ chức, admin có thể deploy cho cả workspace, cập nhật tự động và quản lý tập trung. Dòng cuối diagram nhấn mạnh skill là một open standard, chạy được trên nhiều nền tảng chứ không chỉ riêng Claude.

## 16. Toàn bộ vòng đời một skill

Để gom mọi thứ lại từ hành trình tạo một skill, Mark đưa ra diagram "The Complete Skill Lifecycle", với sáu "station" tương ứng những gì video đã đi qua.

![Diagram The Full Journey: The Complete Skill Lifecycle với sáu station](https://homus.dev/photos/TzJecWCbex0-2125.jpg)

"The Full Journey": sáu station nối bằng một con đường. Station 1 Identify Use Cases, Station 2 Plan & Design, Station 3 Build (tô xanh đậm), Station 4 Test & Iterate, Station 5 Distribute, Station 6 Monitor & Evolve. Mũi tên "Fix & improve" quay từ test về build, và vòng "Continuous improvement" quay từ cuối về đầu. Dòng dưới: 15 tới 30 phút cho skill đầu tiên, lặp lại dựa trên cách dùng thật, thành một tài liệu sống.

- **Xác định use case.** Có hai tới ba workflow cụ thể mà bạn tạo ra, tổng hợp và kết tinh thành một skill. Trên diagram có thêm câu hỏi: người dùng muốn đạt được điều gì?

- **Lên kế hoạch và thiết kế.** Đặt tiêu chí thành công, viết PRD, chọn nhóm skill nào phù hợp (tài liệu, workflow hay MCP), chọn những MCP nào nếu cần, và lên kế hoạch cấu trúc thư mục.

- **Build**, phần quan trọng nhất. Ở đây bạn muốn làm cho YAML frontmatter thật hoàn hảo, và viết được một description thật chuẩn với đúng trigger word. Diagram ghi thêm: viết instruction rõ ràng, thêm xử lý lỗi và ví dụ.

- **Test và lặp**, rồi

- **Phân phối**: để chắc chắn skill thật sự chạy tốt trên production (qua GitHub kèm README, upload lên Claude, hoặc deploy qua API).

- **Theo dõi và tiến hoá** theo thời gian: để ý skill bị gọi quá ít hay quá nhiều, thu thập feedback người dùng, lặp lại trên description và instruction.

Thường thì một skill sẽ phải tiến hoá theo thời gian, khi workflow, doanh nghiệp, hay bất cứ thứ gì của bạn thay đổi. Vì vậy, hãy coi skill như một tài liệu luôn sống. Bạn không muốn thổi phồng ra quá nhiều skill. Bạn muốn thật chọn lọc: skill nào thật sự quan trọng, và bạn có thể tinh chỉnh một skill duy nhất tốt tới mức nào trước khi đi build thêm những cái khác.

Theo Mark, như vậy là gần như đã tổng hợp toàn bộ tài liệu 33 trang thành một loạt diagram. Anh hy vọng các bài học nhỏ gọn này giúp bạn thực thi được mọi thứ và nâng việc tạo skill của mình lên một tầm mới. Anh sẽ chia sẻ toàn bộ ví dụ tốt và tồi về instruction, description, lỗi và mọi thứ khác qua link trong phần mô tả video, và cũng nhắc tới khoá học Claude Code của mình. Anh kết bằng lời cảm ơn và lời mời để lại like, comment nếu thấy video có ích.

## Nguồn và liên kết

- Tên gốc: Anthropic's Full Claude Skills Guide In 22 Minutes
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=TzJecWCbex0](https://www.youtube.com/watch?v=TzJecWCbex0)

- Kênh YouTube Mark Kashef (Mark Kashef): [youtube.com/channel/UCHkzp52CldSPZqU5T49mOnA](https://www.youtube.com/channel/UCHkzp52CldSPZqU5T49mOnA)

- Bản hướng dẫn 33 trang của Anthropic, "The Complete Guide to Building Skills for Claude" (PDF): [resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf](https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf)

- Tài liệu Agent Skills trên Claude Platform (cấu trúc SKILL.md, progressive disclosure, dùng skill qua API): [platform.claude.com/docs/en/agents-and-tools/agent-skills/overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)

- Tài liệu skill trong Claude Code ("Extend Claude with skills"): [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

- Repo skill chính thức của Anthropic, gồm skill-creator, xlsx, docx, pdf, pptx, frontend-design, mcp-builder và nhiều skill khác: [github.com/anthropics/skills](https://github.com/anthropics/skills)

Nguồn: https://homus.dev/talks/anthropics-full-claude-skills-guide-in-22-minutes · cập nhật 2026-10-09