# Nắm 95% Claude Code skills trong 28 phút

[Nate Herk](https://homus.dev/speakers/nate-herk) · [Nate Herk | AI Automation](https://homus.dev/orgs/nate-herk-ai-automation)

> Skill là gì, SKILL.md và supporting files, progressive context loading, framework sáu bước, live build một skill infographic, bảng debug và skill global.

Topics: Skills, Coding Agents, Context Engineering

Canonical: https://homus.dev/talks/master-95-of-claude-code-skills-in-28-minutes

## 1. Leverage, và bốn agent chạy song song trong 30 giây

Nate mở đầu bằng một lời thú nhận: anh chưa bao giờ làm việc năng suất như bây giờ, và lý do là Claude skills. Anh chiếu một tấm ảnh mà theo anh "tóm gọn tất cả": cảm giác như mình đang ngồi trước nhiều máy tính cùng lúc, làm nhiều việc khác nhau cùng lúc, mà không phải đánh đổi chất lượng. Tất cả quy về một chữ duy nhất: **leverage**, tức đòn bẩy. Với Claude skills, hay nói rộng ra là agent skills nói chung, bạn có nhiều đòn bẩy hơn hẳn so với việc tự mình làm mọi thứ.

![Slide Me with Claude Skills, Nate ngồi trước nhiều màn hình](https://homus.dev/photos/zKBPwDpBfhs-0003.jpg)

"Me with Claude Skills": hình ảnh Nate dùng để mở video, một người ngồi trước một dàn màn hình, như đang làm nhiều việc trên nhiều máy cùng lúc. Đó là cảm giác anh muốn mô tả khi nói về leverage.

Anh hứa video sẽ đi qua ba thứ: skill là gì, skill hoạt động ra sao, và làm sao để build được những skill thật sự tốt, kể cả khi bạn chưa từng nghe tới khái niệm này hay chưa từng build một skill nào. Thay vì giảng lý thuyết trước, anh nhảy thẳng vào một live demo.

Màn hình là Claude Code, mở trong project tên **Herk-2**, mà Nate mô tả là "kiểu như trợ lý cá nhân của tôi". Cột bên trái có rất nhiều thư mục và file. Anh dặn người xem: nếu chỗ đó trông rối mắt thì đừng bận tâm lúc này, chỉ cần để ý anh đang yêu cầu agent làm gì.

Việc đầu tiên: anh có một skill tên là **Morning Coffee**, giúp anh lên kế hoạch cho ngày mới mỗi sáng. Lúc quay thì không phải buổi sáng, nhưng anh vẫn chạy nó để mọi người thấy nó hoạt động thế nào. Trong khi Claude Code đang xử lý yêu cầu đó, anh mở thêm một agent nữa và nhờ nó chạy một **pulse check** trên mọi project và cam kết của anh, để xem mọi thứ đang tiến triển ra sao.

Rồi anh mở agent thứ ba, nhờ nó vẽ một diagram bằng Excalidraw so sánh local AI model với closed-source model. Và "làm thêm một cái nữa": agent thứ tư sẽ scrape comment từ các video YouTube gần đây của anh, rồi phân tích xem anh cần cải thiện điều gì.

Vậy là trên màn hình có bốn agent khác nhau đang chạy song song và làm việc cho anh. Nate ước tính anh chỉ mất chừng 30 giây để giao bốn việc đó. Và vì anh đã build tất cả những skill này, cả bốn agent đều có đủ context về business của anh, về tình hình các project, về kênh YouTube. Theo lời anh, chúng có "đúng nghĩa đen mọi thứ chúng cần".

## 2. Bốn agent trả kết quả: Morning Coffee, pulse check, diagram và phân tích comment

Chẳng bao lâu sau, cả bốn agent đều xong. Kết quả đầu tiên là bản Morning Coffee của ngày 26 tháng 2. Hôm đó lịch của anh có ba việc. Skill sẽ đọc lịch, rồi vào ClickUp xem tuần này anh còn những gì, xem danh sách task, và giúp anh lên kế hoạch cho phần còn lại của ngày. Kế hoạch nó đề xuất hiện ngay trên màn hình. Tất cả những gì Nate phải làm là nói "yep", và agent sẽ tự block toàn bộ khung giờ trên lịch cho anh.

Với Nate, điều đó rất lớn, vì anh không còn bị **decision fatigue**, sự mệt mỏi vì phải quyết định, quanh câu hỏi "giờ mình nên làm việc gì".

Agent thứ hai trả về bản pulse check: còn hai ngày nữa là hết tháng, và đây là tình trạng của mọi thứ. Nate làm mờ toàn bộ nội dung, nhưng giải thích rằng về cơ bản agent đang cập nhật cho anh mọi sáng kiến chính mà team đang chạy trong tháng này và quý này, và kiểm tra xem mọi thứ có đúng tiến độ không. Ở một đoạn, bản báo cáo chỉ ra vài việc anh cần tự tay follow up. Anh thừa nhận những việc này có thể đã lọt qua kẽ tay vì anh quá bận làm video YouTube, nếu không có "trợ lý cá nhân" dùng skill này để kiểm tra giúp anh.

Agent thứ ba đã vẽ xong diagram Excalidraw. Nate dán nó vào và kết quả trông như hình dưới. Nếu anh cần làm một video về chủ đề này, anh sẽ không phải bỏ thời gian của mình ra để tự dựng hình minh hoạ đó.

![Diagram Excalidraw Local AI Models vs Closed-Source Models](https://homus.dev/photos/zKBPwDpBfhs-0208.jpg)

Bên trái là local AI model (Ollama, LM Studio, llama.cpp), app, model weights và GPU/CPU đều nằm trên máy của bạn; bên phải là closed-source model (OpenAI, Anthropic, Google), prompt đi qua internet tới server của nhà cung cấp, bạn trả tiền theo token và không bao giờ thấy weights.

Agent thứ tư làm bản phân tích comment. Nó liệt kê toàn bộ comment, lượt xem, và những điều Nate cần xử lý, hoặc trong video tương lai, hoặc ngay trong phần comment. Có những chỗ người xem đang bối rối. Có những câu hỏi về chi phí mà anh cần nói tới. Có một ý kiến kiểu "đừng demo mấy ví dụ đồ chơi cho video về tool nữa". Và có vẻ người xem rất muốn thấy nội dung về Antigravity; Nate hứa nội dung đó sẽ sớm có. Cuối bản phân tích là danh sách ba ưu tiên hàng đầu.

Anh chỉ ra rằng tới lúc này anh mới quay được khoảng sáu phút. Hãy thử nghĩ nếu anh tự làm cả bốn việc đó: anh sẽ phải chuyển ngữ cảnh (context switching) bao nhiêu lần, và mất bao lâu mới xong.

## 3. Skill là gì: reusable instructions, và chuyện ảnh AI viết sai chữ

Sau phần demo, Nate hy vọng người xem đã thấy hào hứng hơn với Claude skills. Giờ tới câu hỏi cho những ai chưa từng dùng: skill thật ra là gì?

Định nghĩa của anh rất ngắn: **skill là những chỉ dẫn dùng lại được (reusable instructions)**. Bạn viết chúng một lần, lưu lại thành một skill, rồi gọi ra bất cứ lúc nào. Kết quả nhất quán hơn hẳn, vì mỗi lần agent đều đi qua đúng cùng một quy trình.

Ý chính của định nghĩa: viết chỉ dẫn một lần, lưu thành skill trong thư mục skills, gọi ra bằng slash command hay bằng câu nói thường, và nhận về cùng một chất lượng mỗi lần.

Anh lấy luôn hình minh hoạ đang chiếu làm ví dụ. Đó là một ảnh do AI tạo ra, bằng một skill của anh trong Claude Code tên **excalidraw-visuals**. Nhưng ảnh AI đôi khi viết chữ không đúng chính tả. Anh chỉ vào vài chỗ trên ảnh: "như bạn thấy ở đây, chỗ này sai hết, chỗ này cũng sai".

Vì thế anh còn có một skill khác, chính là skill đã thấy trong demo, để tạo **Excalidraw diagram**. Skill này tạo ra một file Excalidraw thật, mà anh có thể kéo thả và chỉnh sửa. Chữ trên đó luôn chuẩn, vì về bản chất agent chỉ đang gõ chữ chứ không vẽ chữ. Riêng hai skill này thôi đã giúp anh tiết kiệm rất nhiều thời gian.

Anh cũng nói rằng anh đã thêm một mục mới tên "agent skills" trong cộng đồng miễn phí của mình, nơi anh sẽ đăng rất nhiều skill để người xem lấy về dùng miễn phí.

## 4. Vì sao nên quan tâm: năng suất cá nhân, leverage cho đội, kiếm tiền

Trước khi đi sâu, Nate dừng lại một chút để trả lời câu hỏi: tại sao bạn nên quan tâm? Anh đưa ra ba lý do lớn.

Ba lý do Nate đưa ra để quan tâm tới skill, đi từ cá nhân tới cả đội rồi tới chuyện kiếm tiền, và tất cả quy về cùng một chữ: leverage.

**Thứ nhất, năng suất cá nhân.** Bạn có thể tự động hoá những việc như anh vừa làm trong demo, và thật sự có thể dựng cho mình một hệ thống cá nhân làm được gần như mọi thứ.

**Thứ hai, leverage cho cả đội.** Bạn có thể biến các SOP (standard operating procedure, quy trình chuẩn) đang có thành automation một cách rất, rất dễ. Và khi bạn build một thứ mới, không chỉ bạn dùng được, mà cả tổ chức đều dùng được. Cả nhóm cùng năng suất hơn, và theo Nate, điều đó gần như chắc chắn dẫn tới tăng trưởng cho business.

**Thứ ba, kiếm tiền (monetization).** Chúng ta đang bước vào một thế giới mới nơi skill đang có "khoảnh khắc lớn" của nó, và bạn có thể tận dụng được nhiều thứ ở đây. Nate nói rõ anh không khẳng định đây sẽ là một business model sống được lâu dài, nên đừng đặt cược vào nó, nhưng đó là điều nên biết. Anh so sánh với thời người ta bán template workflow n8n và những thứ tương tự.

Nhưng một lần nữa, mọi thứ quy về một chữ: leverage. Nate nhấn mạnh đây không phải lý thuyết. Đó là điều team anh đang thấy ở khách hàng, và thấy ngay trong business của chính anh. Tốc độ làm việc mà họ đạt được bây giờ cảm giác "điên rồ", nhưng nó sẽ trở thành bình thường. Và nếu bạn không làm được như vậy, bạn sẽ ngay lập tức trở nên quá chậm và quá đắt đối với doanh nghiệp, và họ có thể sẽ không giữ bạn lại.

Vì vậy công ty anh đang ưu tiên đảm bảo mọi nhân viên đều dùng Claude Code. Bây giờ anh có đủ loại skill mà chỉ cần một slash command đơn giản hoặc một prompt bằng ngôn ngữ tự nhiên là chạy, và lấy được trong một ngày khối lượng output của cả một tuần. Lý do vẫn là: một người tìm ra cách tốt nhất để làm một việc, biến nó thành một skill, và cả team đều dùng được.

Và skill không chỉ sinh ra text. Về bản chất chúng là automation. Chúng có thể chạy script, gọi API, tạo ra file và sản phẩm, có thể có sub-agent riêng, và cũng có thể được các agent khác gọi tới. Theo Nate, đây mới thật sự là AI automation.

Để "đóng đinh" ý này, anh nói: skill về cơ bản là **SOP cho AI agent**. Giống như khi bạn đào tạo một nhân viên con người: bạn cho họ đọc SOP để hiểu quy trình, rồi họ làm được. Với agent cũng vậy: bạn đưa cho nó một skill, nó đọc, rồi nó làm. Và phần hay nhất là bạn càng dùng skill, nó càng tốt lên.

## 5. Skill chỉ là một folder: giải phẫu một SKILL.md

Đã nói nhiều về lợi ích, giờ tới câu hỏi: một skill thật ra là gì về mặt kỹ thuật? Câu trả lời: **nó chỉ là một folder**, nằm đâu đó trong project của bạn. Ví dụ phổ biến nhất là đường dẫn `.claude/skills/skill-name/`, và bên trong có một file `SKILL.md`, tức một file markdown.

Nate mở project Herk-2 cho mọi người xem. Ở trên cùng có thư mục `.claude`. Mở ra thì thấy `agents`, `rules` và `skills`. Hôm nay chỉ nói về skills. Mở `skills` ra là thấy toàn bộ các skill anh đã tạo: carousel, competitor-analysis, excalidraw-diagram, idea-mining, linkedin-post, morning-coffee, pulse-check, skill-builder và nhiều skill khác.

Anh chọn skill **excalidraw-diagram** làm ví dụ. Bấm vào thì có một file `SKILL.md`. Mở file ra: có tên của skill, phần mô tả, rồi tới workflow thật sự. Step 1, hiểu concept. Step 2, lên bố cục. Step 3, sinh các element. Toàn bộ skill này về cơ bản dạy agent của anh cách dựng các diagram Excalidraw.

![Slide Anatomy of a SKILL.md bên cạnh file SKILL.md của skill excalidraw-diagram](https://homus.dev/photos/zKBPwDpBfhs-0609.jpg)

"Anatomy of a SKILL.md": bên trái là sơ đồ một SKILL.md gồm phần front matter YAML (name, description: cho Claude biết skill dùng để làm gì) và phần instructions bằng markdown (các bước Claude làm khi skill được gọi); bên phải là file thật của skill excalidraw-diagram với đúng hai phần đó.

Đó là giải phẫu của một skill. Đầu tiên là **front matter**, phần nằm giữa hai dòng gạch ngang. Nó được viết bằng thứ gọi là YAML; Nate bảo bạn không cần bận tâm YAML nghĩa là gì, đây chỉ là một cách ghi dữ liệu, giống như markdown, JSON hay Python là những định dạng khác. Ở trên cùng có `name` và `description`, cho Claude Code biết skill tên là gì và làm gì. Skill này tên là `excalidraw-diagram`, kèm một đoạn mô tả ngắn về việc nó làm hay khi nào nên dùng nó.

Nội dung front matter của skill trên màn hình:

```
---
name: excalidraw-diagram
description: Use when someone asks to draw a diagram, make an Excalidraw diagram, or build an editable diagram. Default for all diagram requests.
---
```

Rồi tới phần **step-by-step rules**, về cơ bản là các chỉ dẫn. Đây là thứ Claude thật sự làm một khi nó đã quyết định rằng đây đúng là skill cho việc này.

Trên slide, ví dụ minh hoạ là một skill tên `skool-post` với description "Write Skool community posts", và phần instructions gồm bốn bước: lấy chủ đề, viết nháp với giọng thân mật, giữ dưới 200 chữ, kết thúc bằng một câu hỏi.

## 6. Supporting files đặt ở đâu: hai lựa chọn và skill idea mining

Điều thú vị ở skill là đôi khi bạn cần nhiều dữ liệu hơn hẳn. Ví dụ, bạn đang viết một bài LinkedIn. Bạn có một skill cho việc đó. Nhưng thứ cần đưa vào skill đôi khi là những thông tin khác: tone of voice của công ty, hay tone of voice của riêng bạn trên LinkedIn, chân dung khách hàng mục tiêu (target avatar), các ưu tiên hiện tại, một cái logo. Có thể có nhiều thứ khác ngoài các bước chỉ dẫn mà khi đưa vào sẽ làm skill tốt hơn. Câu hỏi là: những thứ đó để ở đâu?

Theo Nate, thường có hai lựa chọn, nhưng về bản chất chỉ cần bạn trỏ đúng đường dẫn trong `SKILL.md` là ổn. Anh giải thích trước rồi mới cho xem.

![Slide Where Do Supporting Files Go, Option A và Option B](https://homus.dev/photos/zKBPwDpBfhs-0723.jpg)

"Where Do Supporting Files Go?": Option A (self-contained) để `scripts/` và `references/` ngay trong folder của skill, hợp khi file chỉ một skill dùng; Option B (stored elsewhere) để chúng ở chỗ khác trong project và SKILL.md trỏ tới, hợp khi nhiều skill dùng chung. Dòng cuối: SKILL.md trỏ đúng đường dẫn là cả hai cách đều chạy.

**Lựa chọn A là tự chứa (self-contained).** Trong `.claude/skills/skill-name/`, bạn có `SKILL.md`, có các script ngay đó, có các file reference ngay đó.

**Lựa chọn B là chúng không nằm lồng ngay dưới skill.** Ví dụ có `.claude/skills/infographic/SKILL.md`, và vẫn có script và reference trong cùng project, nhưng không nằm trực tiếp dưới skill đó. Nate thừa nhận nói vậy có thể chưa dễ hiểu, nên anh cho xem ví dụ thật.

Anh mở một skill tên **idea-mining**. Description của nó về cơ bản là: dùng khi ai đó hỏi ý tưởng content, ý tưởng video, nên làm gì tiếp theo, hoặc khi được bảo chạy idea mining. Trong skill, anh đưa cho nó một ít context: kênh của anh có bao nhiêu subscriber, kênh nói về AI automation, các content pillar là n8n, RAG, agent, Claude Code, voice AI.

Rồi anh đưa cho nó một loạt reference: dữ liệu kênh trong file `youtube-channel.md`, dữ liệu thô dạng file JSON, một danh sách đối thủ, và một script thật để chạy phân tích kênh YouTube. Trong trường hợp này anh đi theo lựa chọn B: các file reference và script không nằm lồng ngay trong skill.

Nếu đi theo lựa chọn A, thì ngay trong folder của skill có thể có một folder `references` và một folder `scripts`. Trong `references` có thể là file dữ liệu kênh; trong `scripts` có thể là `youtube-analysis.js` hay `.py`, gì cũng được.

## 7. Trỏ đúng đường dẫn là đủ, Skill Builder, và liên hệ với WAT framework

Ý chính, theo Nate: không quan trọng file reference hay script thật sự nằm ở đâu, miễn là bạn trỏ tới đúng chỗ trong file markdown. Trong trường hợp của anh, chúng nằm ở một folder khác. Với dữ liệu kênh, anh chỉ cần đi xuống thư mục `references` ở cấp project, và ở đó có `youtube-channel.md`. Claude Code đọc skill, và khi cần thì nó tìm được file này. Script cũng vậy: đi xuống `scripts`, tìm thấy `analyze_youtube.py`, và kéo nó vào nếu cần.

Phần context trong SKILL.md của idea-mining, như trên màn hình, trỏ thẳng tới các file đó:

```
## Context

- Nate's channel: @nateherk, 537K subs, AI automation education for non-technical audiences
- Core content pillars: n8n AI agents, selling AI, RAG agents, Claude Code, voice AI, MCP
- Channel data: `references/youtube-channel.md` (analysis), `references/youtube-raw-data.json` (raw)
- Competitor list: `references/competitors.md`
- Analysis script: `scripts/analyze_youtube.py` (modes: comments, competitors, trends)
```

"Hy vọng các bạn vẫn theo kịp," anh nói. Bạn muốn sắp xếp kiểu nào cũng được. Và theo anh, đó chính là điều dễ gây choáng nhất về Claude Code hiện nay: mỗi người dùng một kiểu kiến trúc folder khác nhau.

Nhưng anh trấn an: anh đã lo phần này. Anh đã build một skill tên **Skill Builder**, và cũng sẽ tặng miễn phí trong cộng đồng free của mình. Bạn chỉ cần nạp Skill Builder vào, nó sẽ giúp bạn dựng mọi thứ cần thiết, và vài phút nữa anh sẽ live demo chính skill này.

Tóm lại: `SKILL.md` là bộ não, còn các supporting file là những công cụ mà bộ não có thể dùng. Điều đó không có nghĩa là mỗi lần skill được gọi thì mọi file reference đều được đọc.

Nate cũng nối lại với các video cũ. Nếu bạn đã xem những video Claude Code trước đây của anh, nơi anh dùng **WAT framework** để build automation, thì skill rất, rất giống. Trong framework đó, W là workflows: các SOP viết bằng file markdown, và đó về cơ bản chính là skill. T là tools: các script Python thật. Trong thế giới skill, đó là những script bạn viết hoặc những file reference bạn thêm vào. Vì vậy nếu bạn đã build theo kiểu WAT, bạn sẽ nắm skill cực nhanh.

Liên hệ Nate đưa ra: phần workflows (SOP viết bằng markdown) trong WAT framework tương ứng với SKILL.md, phần tools (script Python) tương ứng với các script và file reference đi kèm skill.

## 8. Bạn không phải tự viết hết: thư viện chính thức, cộng đồng, marketplace

Một điều hay của skill là bạn không phải tự build tất cả. Dĩ nhiên, khi làm việc với Claude Code mà thấy mình đang lặp đi lặp lại một việc, bạn có thể build một skill cho việc đó. Nhưng ngoài ra còn có một thư viện skill chính thức của Anthropic, có cả một cộng đồng đang open source skill của họ và chia sẻ miễn phí, và có marketplace nơi bạn chia sẻ, bán, hoặc tải skill của người khác về.

![Slide You Don't Have to Build Them All: Official Library, Community, Marketplaces](https://homus.dev/photos/zKBPwDpBfhs-1023.jpg)

"You Don't Have to Build Them All": ba nguồn skill dựng sẵn, gồm thư viện chính thức (trên slide: 50+ skill, 77k sao), cộng đồng (380+ skill open source) và marketplace như SkillsMP.com để chia sẻ và bán. Tất cả đổ về `.claude/skills/`: không cần script cài đặt, không có bước build, chỉ là một folder chứa markdown, và chạy được trong hơn 30 tool như Claude Code, Cursor, Gemini CLI, Copilot.

Cách dùng: bạn lấy skill đó, về bản chất là một prompt, rồi thêm "gia vị" của riêng mình vào. Nate lưu ý một điều: hãy cẩn thận và kiểm tra rằng không ai đang cố đưa cho bạn một skill có ý đồ xấu bên trong.

Và tất cả những skill này chạy được trên nhiều sản phẩm khác nhau: Cursor, Antigravity, Codex. Vì skill dựa hoàn toàn trên markdown và về cơ bản chỉ là một prompt, rất nhiều AI model khác nhau đều dùng được.

## 9. Claude biết khi nào dùng skill: hai cách trigger

Câu hỏi tiếp theo: làm sao Claude biết khi nào dùng một skill? Có hai cách để trigger, tức kích hoạt, một skill.

**Cách thứ nhất là gọi tường minh (explicit).** Bạn gõ một slash command kèm tên skill, và skill chạy ngay lập tức. **Cách thứ hai là ngôn ngữ tự nhiên.** Ví dụ nếu anh có một skill viết bài cho Skool, anh có thể gõ `/skool-post`. Hoặc anh chỉ cần nói thường: "này, giúp tôi viết một bài Skool về chủ đề X". Claude sẽ tìm thấy skill đó và gọi nó.

![Slide How Does Claude Know When to Use a Skill, hai cách trigger](https://homus.dev/photos/zKBPwDpBfhs-1103.jpg)

"Two Ways to Trigger a Skill": cách 1 (explicit) gõ `/skool-post` là skill chạy thẳng; cách 2 (natural language) nói "write a Skool post about AI automation", Claude so câu đó với description của các skill rồi mới gọi skill khớp.

Quy trình phía sau như sau. Khi bạn nhờ Claude làm gì đó, đầu tiên nó đọc file `CLAUDE.md`. Nó phân tích yêu cầu của bạn, rồi lục qua các skill để xem: mình có skill nào giúp được cho câu hỏi này không? Nếu tìm thấy, nó gọi skill đó. Nếu không tìm thấy gì, nó dùng kiến thức chung của mình. Vì vậy không phải yêu cầu nào bạn đưa cho Claude Code cũng kích hoạt một skill.

## 10. Progressive context loading: ba cấp để skill luôn nhẹ

Một phần rất quan trọng của chuyện trên là hiểu vì sao skill vẫn giữ được sự nhẹ nhàng. Nếu bạn đã dùng Claude Code, bạn biết quản lý context là chuyện cực lớn. Giả sử bạn có hàng loạt skill, mỗi skill dài hàng trăm dòng, và mỗi lần Claude Code lại lục qua toàn bộ chúng, thì chắc chắn sẽ ngốn một lượng token khổng lồ.

Cách Claude Code giải quyết là một cơ chế gọi là **progressive context loading**, nạp context theo từng bước, gồm ba cấp.

![Slide Progressive Context Loading với ba cấp](https://homus.dev/photos/zKBPwDpBfhs-1243.jpg)

"Progressive Context Loading": Level 1 (startup) chỉ đọc name và description, khoảng 100 token mỗi skill; Level 2 (triggered) nạp toàn bộ SKILL.md vào context, khoảng 1.000 tới 3.000 token; Level 3 (on demand) chỉ nạp scripts, references, templates khi được trỏ tới. Bên phải là ví dụ các folder brand-assets và context của Nate, loại file chỉ được đọc ở cấp 3.

**Cấp 1 là bước tìm ban đầu.** Claude Code chỉ nhìn vào name và description. Ví dụ bạn nhờ vẽ một diagram Excalidraw: nó sẽ lục qua mọi skill, nhưng chỉ đọc phần front matter YAML, tức name và description. Phần front matter thường chỉ khoảng 100 token, nên rất nhẹ.

**Cấp 2:** giả sử nó xác định "okay, đây đúng là skill cho việc này". Lúc đó nó mới đọc toàn bộ `SKILL.md`, đọc hết từ đầu tới cuối, và bắt đầu thật sự hiểu skill làm gì. Phần này có thể tốn từ một nghìn tới vài nghìn token.

**Cấp 3** lại là một quyết định: chỉ nạp các file phụ khi cần. Nếu cần xem script, reference hay template nào, hay cần kéo brand asset hoặc thêm context, nó chỉ làm vậy khi chính yêu cầu cụ thể đó đòi hỏi.

Nate hy vọng tới đây người xem bắt đầu hiểu hơn những gì đang diễn ra "dưới nắp capô" khi bạn nhờ Claude Code làm một việc. Và bạn luôn có thể vào tài liệu Claude Code, mở mục skills, và đọc cách mọi thứ hoạt động; theo anh nó thật sự rất đơn giản.

## 11. Không có skill hoàn hảo ngay lần đầu: feedback cycle

Ngay trong tài liệu chính thức có một lời khuyên Nate trích ra: giữ `SKILL.md` dưới 500 dòng, và chuyển tài liệu tham chiếu chi tiết sang các file riêng (xem [trang Skills trong tài liệu Claude Code](https://code.claude.com/docs/en/skills)).

Anh biết tới đây có vẻ là rất nhiều thông tin dồn vào người xem. Nên anh chậm lại, đặt mọi thứ vào bối cảnh, và trấn an: bạn sẽ không bao giờ, không bao giờ, không bao giờ viết được một skill hoàn hảo ngay lần đầu.

Cách anh build skill là thế này. Anh để Claude Code làm một việc cùng mình. Anh dẫn nó qua từng bước, mỗi lần một ít. Khi xong, nếu đã đi được từ điểm A tới điểm B, anh nói: "Tốt. Đây là việc tôi làm mỗi ngày một lần. Hãy biến nó thành một skill. Hỏi tôi thêm câu hỏi để chắc chắn bạn có đủ mọi thông tin cần thiết." Anh hứa sẽ mở một project hoàn toàn mới và dựng một skill từ đầu để mọi người thấy toàn bộ quy trình; anh chỉ cần cho mọi người chút context trước.

Rồi tới thứ anh gọi là **feedback cycle**, vòng phản hồi. Bạn gọi skill, bạn thật sự ngồi xem agent làm, bạn góp ý, agent sửa lại skill, và bạn chạy lại.

Vòng phản hồi Nate mô tả: gọi skill, ngồi xem agent làm để thấy chỗ sai và chỗ tốn token, góp ý, để agent sửa skill, rồi quay lại chạy tiếp. Mỗi vòng skill tốt lên một chút.

Vài lần đầu chạy một skill, bạn có thể thấy kiểu "ờ, cái này nghe rất AI". Nhưng khi đã chạy skill đó 10, 20, 30 lần, thì lần nào nó cũng tốt hơn. Đó là lý do việc ngồi xem agent làm trong vài lần đầu thật sự quan trọng: chính lúc đó bạn nhìn ra cơ hội để làm nó nhanh hơn và tiết kiệm token, bằng những cách như ví dụ tiếp theo.

## 12. Ví dụ pulse check: hardcode list ID và giao việc tìm kiếm cho sub-agent

Ví dụ là skill **pulse-check**, chính là skill đã chạy trong demo đầu video. Skill này được gọi khi anh hỏi một pulse check hoặc muốn kiểm tra các cam kết. Việc đầu tiên nó làm là đọc một ít context về cách các OTA vận hành; trên màn hình ghi OTA là các sáng kiến theo quý (quarterly initiatives). Agent cần hiểu điều này mỗi lần đọc skill, nên anh đặt nó ngay trong `SKILL.md` chứ không để ra một file reference.

Sau đó agent phải tra cứu trực tiếp trên ClickUp để biết chuyện gì đang diễn ra. Và đây là chỗ anh tối ưu: anh **hardcode luôn các list ID** vào skill. Lý do là khi ngồi xem agent làm, anh nhận ra lần nào nó cũng gọi ClickUp MCP, gom tất cả các list về, tìm kiếm, parse kết quả, rồi mới trích ra được ID. Việc đó vừa mất rất lâu vừa tốn rất nhiều token. Anh nhận ra các ID đó lúc nào cũng vậy, không đổi. Vậy sao không ghi thẳng chúng vào tài liệu skill? Giờ thì lần nào agent cũng biết ngay lập tức, và không phí số token đó nữa.

![Slide The Slow Way và The Fast Way để lấy ClickUp list ID](https://homus.dev/photos/zKBPwDpBfhs-1446.jpg)

"The Slow Way" và "The Fast Way": cách chậm là cần list ID, gọi ClickUp API qua MCP tool, tìm và parse kết quả, rồi trích ID, khoảng 500 token và có thể hỏng; cách nhanh là đọc thẳng file `references/clickup-ids.md`, xong ngay, khoảng 50 token và lúc nào cũng chạy.

Chưa hết. Anh biết việc lục tìm trong ClickUp có thể tốn nhiều thời gian và token. Nên anh build một **sub-agent chuyên biệt**, và trong skill anh viết đại ý: "hãy giao cho agent clickup-searcher truy vấn này để nó lo toàn bộ việc tìm kiếm, như vậy bạn không làm nổ context window của chính mình". Mọi việc tìm kiếm được xử lý ở phía sub-agent, và agent chính chỉ nhận về đúng thông tin cần.

Nate nói còn rất nhiều kỹ thuật nâng cao để quản lý context, nhưng anh không đi sâu lúc này vì video chỉ tập trung vào skill. Anh chỉ muốn cho người xem "nếm thử" những gì có thể làm được bên trong các file `SKILL.md`.

## 13. Tài liệu tham chiếu thay cho web search, và khi nào nên build skill

Một ví dụ tốt khác về việc cần một file reference là chính skill **skill-builder**. Nate dùng nó khi tạo skill mới, tối ưu skill, kiểm định chất lượng skill, và những việc tương tự. Phần lớn cảm hứng để viết skill này, tất nhiên, đến thẳng từ tài liệu Claude Code về cách dùng, build và tối ưu skill.

Khi build skill này, anh ngồi xem agent chạy và nhận ra lần nào nó cũng đi tìm kiếm: nó làm một web search và crawl toàn bộ trang tài liệu, kể cả khi anh chỉ cần một mẩu thông tin nhỏ. Nên anh quyết định bảo nó scrape toàn bộ tài liệu đó một lần, rồi đưa cho skill một file `reference.md`, về cơ bản chính là bộ tài liệu. Giờ anh có `SKILL.md`, và skill chỉ đọc tới file đầy đủ kia khi cần.

Trên màn hình, phần mô tả của skill-builder ghi rằng nó hướng dẫn việc tạo và tối ưu Claude Code skill theo best practice chính thức, dùng khi build skill mới từ đầu, tối ưu hay kiểm định một skill có sẵn, quyết định các pattern nâng cao (subagent execution, hooks, dynamic context), và xử lý một skill không chạy đúng; còn toàn bộ tham chiếu kỹ thuật về front matter, pattern nâng cao và troubleshooting thì xem trong `reference.md`.

Nhưng ý chính anh muốn nhấn mạnh là: cho agent xử lý file markdown nhanh hơn và rẻ hơn rất nhiều so với việc gọi API, gửi HTTP request, chạy function và đọc hàng đống token. Mục tiêu là skill của bạn sẽ tới được mức mà bạn chỉ cần gọi nó, quay sang làm việc khác trong 10, 15 phút hay bao lâu cũng được, rồi quay lại và có một kết quả hoàn chỉnh, thật sự tốt. Nhưng trong vài lần đầu thử một skill, anh cho rằng rất nên ngồi xem nó chạy và xem nó đang làm gì.

Rất nhiều người hỏi Nate: làm sao biết lúc nào nên build một skill? Câu trả lời của anh: cứ làm việc bình thường. Nếu bạn nhận ra mình đã làm một việc rồi, hoặc đã dặn một điều nhiều lần rồi, ví dụ anh hay dặn Claude đừng dùng dấu gạch dài (em dash), thì có lẽ nên đưa điều đó vào prompt. Nói chung, nếu bạn thấy mình lặp lại một quy trình hay lặp lại prompt, thì đó có lẽ là một use case tốt để build một skill quanh nó.

Tinh thần câu trả lời "khi nào nên build skill": cứ làm việc bình thường, khi thấy mình lặp lại một quy trình hay lặp lại cùng một lời dặn và muốn kết quả lần nào cũng như nhau, đó là lúc biến nó thành skill.

Vì skill không cần phải phức tạp. Một skill hoàn toàn có thể chỉ là một file markdown 50 dòng.

## 14. Framework sáu bước để build một skill

Ngay trước khi live build một skill từ đầu, Nate đi nhanh qua **framework sáu bước** anh dùng để build skill.

![Slide The 6-Step Skill Building Framework](https://homus.dev/photos/zKBPwDpBfhs-1723.jpg)

"The 6-Step Skill Building Framework": 1 name + trigger, 2 goal (một câu), 3 step-by-step process (workflow chính xác, có các điểm quyết định có người trong vòng lặp), 4 reference files (style guide, ví dụ, tài liệu context, tách khỏi SKILL.md), 5 rules (guardrail và ràng buộc), 6 self-improvement (lưu các output đã được duyệt, tự cập nhật rule).

**Bước 1 là tên và trigger.** Skill tên là gì, và câu nói tự nhiên nào sẽ kích hoạt nó.

**Bước 2 là mục tiêu.** Trong một câu: tới cuối, skill này sẽ hoàn thành được điều gì? Output sẽ là gì?

**Bước 3 là phần "thịt" thật sự: quy trình từng bước.** Nếu bạn phải làm việc này bằng tay, chính xác bạn làm gì và theo thứ tự nào, bạn nhìn vào đâu, và bạn đưa ra những quyết định nào?

**Bước 4 là các file reference.** Bạn cần context gì? Có cần ảnh không? Có cần hiểu các project hiện tại, các ưu tiên hiện tại không? Có cần style guide không? Bạn cần những gì để làm tốt việc này?

**Bước 5 là các rule.** Hãy nghĩ xem điều gì có thể sai, rồi agent có thể giúp bạn dựng các guardrail và ràng buộc quanh những điểm đó.

**Bước 6** là phần sau khi build xong: **vòng tự cải thiện (self-improvement loop)**. Sau phần live build, anh sẽ nói về việc test, lặp lại, và những gì cần làm để skill thật sự tốt. Nhưng tạm thời, đó là framework sáu bước. Và giờ thì vào live build.

## 15. Live build phần 1: VS Code, dựng workspace và để Skill Builder phỏng vấn

Màn hình chuyển sang Visual Studio Code, nơi Nate thích dùng Claude Code. Nếu bạn chưa có Visual Studio Code, chỉ cần mở trình duyệt, gõ "VS Code" và tải về. Nếu là lần đầu dùng Claude Code trong đó, giao diện sẽ trông như trên màn hình: bạn vào mục Extensions ở cột bên trái, gõ "Claude Code", cài extension, rồi đăng nhập bằng gói trả phí của Anthropic.

Sau đó bấm nút ở góc trên bên trái, một khung nhỏ hiện ra báo rằng bạn chưa mở folder nào. Việc cần làm là mở một project để làm việc: hoặc mở một project bạn đang làm dở, hoặc tạo một folder mới rồi mở nó. Cho buổi demo, anh mở một folder trống mới tên "A Bunch of Skills" và chỉ cho mọi người chính xác cần làm gì.

Bước đầu là tải folder skill-builder từ mục "agent skills" trong cộng đồng free của anh. Khi đã có file, việc đầu tiên là dựng nhanh workspace. Anh gõ cho Claude Code:

```
Initialize this project with a simple .claude/skills structure.
```

Xong, workspace đã được dựng: có `.claude`, có folder `skills`. Trong folder skills, anh tạo một folder mới tên `skill-builder`, rồi kéo hai file lấy từ cộng đồng, file reference và file markdown của skill, vào đó. Giờ skill-builder đã sẵn sàng với file reference và file SKILL.md.

Anh hỏi Claude xem nó có thấy skill mới vừa thêm không. Nó trả lời là có. Anh nói đại ý: "Tốt, chạy skill đó để cùng build một skill mới nào." Trên màn hình, agent bắt đầu đọc skill, chính là những chỉ dẫn vừa xem; đúng như cách skill hoạt động đã nói ở trên, nó đọc file này trước.

Nate đã build skill này để nó đặt câu hỏi cho bạn, như vậy bạn dễ diễn đạt điều mình muốn hơn nhiều. Câu đầu tiên: bạn đang muốn giải quyết vấn đề gì? Anh chọn content creation, vì skill anh muốn làm là tạo infographic theo thương hiệu. Câu tiếp: skill tạo ra loại content nào, use case hay workflow cụ thể là gì? Anh chọn "Other" và gõ "educational infographics".

Rồi nó hỏi nên trigger skill thế nào: bằng ngôn ngữ tự nhiên hay chỉ bằng slash command? Anh trả lời cả hai đều được.

Luồng mà Nate mô tả cho skill infographic qua các câu trả lời phỏng vấn: nhận chủ đề, tạo concept, theo brand guidelines, gọi API tạo ảnh bằng Nano Banana, đặt logo ở góc trên bên trái, xuất PNG vào folder projects, chạy một mạch không hỏi lại.

Tiếp theo là phần quy trình từng bước, rất quan trọng, vì tới lúc này anh chưa hề nói với nó dùng tech stack gì hay bất cứ điều gì về business của mình. Câu hỏi là: "Hãy dẫn tôi đi qua những gì nên xảy ra từ lúc trigger tới lúc có output." Agent đưa ra vài phỏng đoán khá ổn, nhưng anh chọn "Other" và tự giải thích theo cách anh muốn: "Tôi sẽ nói cho bạn biết tôi muốn infographic về chủ đề gì. Bạn sẽ tạo một concept. Bạn sẽ gửi một request tới một dịch vụ API trung gian cho model để dùng Nano Banana tạo ra..." Anh lỡ lời nói "tạo ra outline", rồi sửa ngay: "à không, tạo ra hình ảnh". "Và bạn cũng sẽ xem brand guidelines tôi đưa cho bạn, để mọi thứ được tạo ra đều theo màu thương hiệu, typography và những thứ tương tự."

## 16. Live build phần 2: brand assets, chạy thử, góp ý, chạy lại

Định dạng output anh muốn là PNG, không phải những lựa chọn khác trong danh sách. Skill nên mang tính hội thoại hay "fire and forget", giao xong là chạy một mạch? Anh chọn fire and forget. Câu hỏi tiếp: phần tích hợp Nano Banana hoạt động thế nào, là một API call phải không? Đúng, anh chọn API call. Nate lưu ý rằng ở những lựa chọn này bạn hoàn toàn có thể trả lời "tôi không biết, thử vài cách xem, giúp tôi tìm ra cách tốt nhất".

Nó hỏi brand asset nằm ở đâu. Anh sẽ để chúng trong một folder. Còn file PNG infographic tạo ra thì lưu ở đâu? Anh bảo: được, tạo một folder mới tên `projects` và để tất cả vào đó, như vậy project cũng gọn gàng.

Rồi tới câu hỏi về brand guidelines. Anh đã tạo một folder và bỏ vào đó bảng màu cùng logo AIS (AI Automation Society, cộng đồng của anh). Anh trả lời rằng anh đã để cả brand guidelines của AIS lẫn logo AIS vào, và muốn chắc chắn rằng ở góc trên bên trái của mọi infographic được tạo ra, logo AIS phải xuất hiện đúng y như file anh đưa. Anh trả lời thêm vài câu hỏi nữa và hẹn sẽ cho xem khi có kết quả.

Sau khi trả lời xong, agent bắt đầu tạo skill. Nó tạo phần chồng logo (logo overlay). Nó tạo một file reference markdown chứa toàn bộ chi tiết API cần dùng. Nó đăng ký skill vào `CLAUDE.md`, và ghi lại các quyết định đã đưa ra. Rồi skill được build xong, cùng tất cả các file.

Trên màn hình, bản tóm tắt agent đưa ra mô tả luồng của skill `/infographic-builder`: bạn nói "create an infographic about X" hoặc gọi slash command; Claude soạn một prompt theo luật thương hiệu AIS (font Montserrat, bảng màu xanh dương và xanh mòng két, nền tối, ít chữ); gọi API Nano Banana Pro để tạo ảnh; chờ tới khi ảnh sẵn sàng rồi tải PNG về; chạy script Python để chồng logo AIS nguyên trạng vào góc trên bên trái; lưu kết quả cuối vào `projects/infographic-builder/`. Trước lần dùng đầu, cần đặt API key vào file `.env` và cài Python 3 cùng thư viện Pillow.

Vậy là chỉ cần đưa cho nó API key để chạy được. Nate thêm key, rồi gõ đúng một câu: test thử với một infographic về Claude skills. Không thêm context nào khác. Agent gọi skill ngay đó.

Anh thấy một điều thú vị: agent tạo ảnh trước, rồi mới chồng logo lên. Như vậy sẽ nhất quán hơn nhiều so với việc đưa logo cho bộ tạo ảnh Nano Banana tự vẽ. Anh không hề dặn nó làm vậy.

Kết quả lần đầu: "Okay, tôi không thích lắm." Anh quay lại và nhờ sửa vài thứ. Logo ở góc trên bên trái trông không ổn. Anh viết: "Tôi đã đưa cho bạn một logo nền trong suốt, nên nó phải được đặt chồng lên trên và ta phải nhìn thấy nền phía sau nó. Bản thân infographic thì tạm được, nhưng tôi muốn chúng luôn có tỉ lệ khung hình 1:1." Agent nhận góp ý, chạy lại, và cập nhật luôn skill của nó.

![Infographic Claude Code Skills: Custom AI Workflow với logo AIS](https://homus.dev/photos/zKBPwDpBfhs-2303.jpg)

Kết quả lần chạy thứ hai: một infographic vuông 2048x2048 tên "Claude Code Skills: Custom AI Workflow", logo AIS ở góc trên bên trái, các khối command prompt trigger, SKILL.md, frontmatter config, triggers / slash commands, AI agent delegation và document output. Cột trái cho thấy cấu trúc project mới: skills, brand-assets, decisions, projects.

## 17. Từ 90% lên gần 100%: bảng debug skill và front matter nâng cao

Lần chạy thứ hai, logo đã nằm đúng ở trên cùng. Infographic có các khối Claude Code Skills custom AI workflow, command prompt trigger, front matter config, triggers, AI agent delegation, document output. Nate nhắc lại: tất cả những gì họ nói chỉ là "build một infographic về Claude skills", và đây mới là lần chạy thứ hai. Mỗi lần đi qua vòng này, như đã nói ở phần feedback, bạn lại xem agent làm, góp ý thêm, và tiếp tục. Chạy thêm chừng năm, sáu lần nữa thì skill sẽ thật sự rất tốt, và từ đó trở đi lần nào anh nhờ làm infographic, kết quả cũng nhất quán.

Anh mở skill **infographic-builder** vừa được build để mọi người xem. Có front matter ở trên với name và description. Có phần mô tả skill làm gì. Có phần context, nơi skill trỏ tới brand guidelines và logo. Có workflow từng bước. Và có một dòng nói rằng muốn xem toàn bộ tham chiếu API và tham số thì đọc file markdown kia, để agent khỏi phải đi search web và đốt một đống token; nó chỉ cần đọc file markdown đó.

Vậy là họ đã nói rất nhiều về skill và vừa build một skill live. Giờ Nate muốn nói về cách bắc cầu từ một skill "tốt 90%" lên gần như 100%: test, lặp lại, và debug. Có những triệu chứng khác nhau và cách sửa khác nhau, và anh đi lần lượt từng dòng.

![Slide Skill Debugging Guide, bảng triệu chứng và cách sửa](https://homus.dev/photos/zKBPwDpBfhs-2355.jpg)

"Skill Debugging Guide": bảng triệu chứng (symptom) và cách sửa (fix). Câu trích cuối slide: mỗi lần bạn sửa skill, nó thông minh hơn vĩnh viễn, lỗi đó không lặp lại nữa, đó là hiệu ứng cộng dồn.

- **Làm sai bước hoặc sai thứ tự:** chỉ cần bảo agent sửa phần chỉ dẫn trong `SKILL.md`.

- **Thiếu tone, style hay context:** thêm file reference. Và dĩ nhiên phải trỏ tới chúng cho đúng trong `SKILL.md`.

- **Cùng một lỗi cứ lặp lại:** thêm một rule.

- **Vật lộn với một tool hay một MCP, hoặc cứ đi tìm mãi cùng một thứ:** tạo một tài liệu reference cho nó.

- **Chạy được nhưng có thể tốt hơn:** theo lời Nate, nghĩa là bạn phải "brute force": chạy đi chạy lại, chạy nữa, và cứ bắt bẻ những chỗ nó làm sai, hoặc không hẳn là sai mà là chỗ nó có thể làm tốt hơn. Trên slide, cách sửa cho dòng này ghi là thêm chỉ dẫn tự cải thiện (self-improvement instructions).

- **Skill không được kích hoạt:** kiểm tra phần YAML và đảm bảo nó đủ cụ thể.

- **Skill kích hoạt quá thường xuyên:** thử tắt model invocation, tức đặt `disable-model-invocation: true`.

Thiết lập cuối cùng đó có trong tài liệu Claude, và về cơ bản cho bạn quyền kiểm soát việc skill chỉ được gọi bằng ngôn ngữ tự nhiên, chỉ được gọi trực tiếp bằng slash command, hay cả hai. Nếu muốn xem thêm phần nâng cao, Nate khuyên vào thẳng trang tài liệu. Tới đây, theo anh, video đã đi qua gần như mọi thứ về skill.

Một chỗ anh muốn mọi người để ý là bảng tham chiếu front matter. Họ đã thấy name và description, mà theo lời Nate là những trường bắt buộc mỗi lần; trên bảng trong tài liệu thì `name` ghi là không bắt buộc (bỏ trống sẽ lấy tên thư mục) và `description` ghi là nên có. Ngoài hai trường đó còn rất nhiều thứ khác bạn có thể thêm vào.

![Bảng các trường front matter trong tài liệu Extend Claude with skills](https://homus.dev/photos/zKBPwDpBfhs-2523.jpg)

Bảng front matter trong trang "Extend Claude with skills" của tài liệu Claude Code: `name`, `description`, `argument-hint`, `disable-model-invocation` (đặt true để Claude không tự nạp skill, chỉ gọi tay bằng `/name`), `user-invocable` (đặt false để ẩn khỏi menu `/`), `allowed-tools`, `model`, `context` (đặt `fork` để chạy trong một subagent tách riêng).

Có `disable-model-invocation` như vừa nói. Bạn cũng có thể cho skill `allowed-tools`, các tool được phép dùng. Có thể cho nó một `argument-hint`. Có thể chỉ định một model cụ thể, một context cụ thể, gắn hooks, hoặc chỉ định một agent cụ thể. Tất cả những thứ này cho phép bạn tinh chỉnh rất chi tiết từng skill và cách bạn muốn nó được dùng. Nhưng Nate dặn đừng choáng: bạn chỉ thật sự cần tới mức đó khi đã chạy skill rất nhiều lần.

## 18. Skill sống ở đâu: project hay global, và lời chào

Điều cuối cùng Nate muốn nói nhanh: skill thật ra nằm ở đâu? Tới giờ mọi người chỉ thấy skill được build ngay trong folder `.claude/skills` của project. Khi làm vậy, skill chỉ tồn tại trong đúng project đó, dù là Herk-2 hay project vừa dựng. Nếu chuyển sang một folder khác, Claude Code sẽ không truy cập được skill đó nữa.

Nhưng bạn cũng có thể tạo skill **global**. Cách làm là đặt nó ở một thư mục khác: thư mục home tổng của bạn, được ký hiệu bằng dấu ngã nhỏ, tức `~/.claude/skills/`. Khi đó, bất kể bạn mở Claude Code ở đâu, skill đó đều có mặt. Ví dụ anh có một skill front-end design cài global, nên ở bất cứ đâu, khi cần làm front-end design, agent đều dùng được nó.

Hai nơi một skill có thể sống: `.claude/skills/` trong project (chỉ dùng được trong project đó) và `~/.claude/skills/` trong thư mục home (dùng được ở mọi project).

Nhìn theo cách khác: hiện tại bạn có các project, ví dụ Herk-2. Trong đó có `.claude`, trong `.claude` có `skills`, rồi tới skill của bạn, rồi tới file MD, references, đủ thứ. Rồi có thể thêm một skill khác. Nhưng nếu skill là global, có thể bạn sẽ không thấy nó trong project; nó chỉ nằm trong thư mục home tổng của bạn.

Lý do nên làm vậy: nếu có điều gì rất riêng về bạn, về business, về workflow của bạn mà bạn muốn áp dụng cho mọi project bất kể thế nào, chẳng hạn context công ty, các project của công ty, tone of voice của bạn, thì hãy cài nó global.

Nate nhắc tới cộng đồng trả phí của anh cho những ai thích "nerd out" về chủ đề này, nơi có hơn 3.000 thành viên đang build với AI và build business bằng AI mỗi ngày. Video khép lại bằng lời cảm ơn: nếu học được điều gì mới thì hãy bấm like, điều đó giúp anh rất nhiều, và như mọi lần, anh cảm ơn mọi người đã xem tới cuối video và hẹn gặp lại ở video sau.

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

- Tên gốc: Master 95% of Claude Code Skills in 28 Minutes
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=zKBPwDpBfhs](https://www.youtube.com/watch?v=zKBPwDpBfhs)

- Kênh YouTube của Nate Herk: [youtube.com/@nateherk](https://www.youtube.com/@nateherk)

- Tài liệu Claude Code về skill (front matter, `disable-model-invocation`, skill global trong `~/.claude/skills`, lời khuyên giữ SKILL.md dưới 500 dòng): [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

- Thư viện skill chính thức của Anthropic: [github.com/anthropics/skills](https://github.com/anthropics/skills)

- SkillsMP, marketplace skill được nhắc trên slide: [skillsmp.com](https://skillsmp.com)

- Agent Skills, chuẩn mở giúp skill chạy được trên nhiều tool: [agentskills.io](https://agentskills.io)

Nguồn: https://homus.dev/talks/master-95-of-claude-code-skills-in-28-minutes · cập nhật 2026-10-09