Nhân viên Anthropic thật sự dùng Claude skills thế nào

1. Playbook nội bộ của Anthropic, rút thành năm bài học

Austin mở đầu bằng một tin: Anthropic, công ty tạo ra Claude, vừa công bố playbook nội bộ về cách chính họ dùng skill của Claude. Không chỉ engineer, mà cả team marketing lẫn team pháp lý (legal) của họ đều đã tinh gọn các workflow kỹ thuật và phi kỹ thuật của mình bằng skill.

Sau khi phân tích mọi thứ team Anthropic đã đăng, từ các buổi phỏng vấn, các bài blog cho tới tài liệu chính thức, Austin chia cách họ dùng skill thành năm bài học đơn giản mà theo anh ai cũng làm theo và áp dụng được ngay hôm nay. Năm bài học đó là: hiểu các category, dùng các power component, tập trung vào verifier, viết gotchas, và tune trigger.

Nguồn chính anh dựa vào là bài blog "Lessons from building Claude Code: How we use skills" của Anthropic, kể lại những gì họ học được khi xây và mở rộng hàng trăm skill trong nội bộ công ty.

2. Bài 1: chín category của team Claude Code

Bài học số một là hiểu các category. Team Anthropic chia skill thành chín category, Austin cho hiện cả chín trên màn hình. Mỗi category đều mang tính kỹ thuật, vì chúng do chính những người tạo ra Claude Code đặt ra.

Đọc kỹ bảng trên màn hình, mỗi ô có một dòng mô tả và vài tên skill ví dụ:

• Library & API Reference: thư viện nội bộ, CLI, SDK, gotchas (billing-lib, platform-cli, events).
• Product Verification: điều khiển sản phẩm đang chạy để kiểm tra (signup-driver, checkout, admin).
• Data & Analysis: ID, tên trường, mẫu query (funnel-query, grafana, datadog).
• Business Automation: workflow nhiều công cụ gom lại thành một lệnh (standup, tickets, weekly-recap).
• Scaffolding & Templates: boilerplate đúng chuẩn framework (new-app, migration, workflow).
• Code Quality & Review: phương pháp giúp ship code tốt hơn (adversarial, hypothesis, bughunt).
• CI/CD & Deployment: commit, push, deploy an toàn (babysit-pr, deploy, cherry-pick).
• Incident Runbooks: triệu chứng, điều tra, rồi báo cáo (oncall, correlator, queue-debug).
• Infrastructure Ops: dọn dẹp và bảo trì có cổng an toàn (orphans, deps, cost-investigation).

Nhưng thực tế, theo Austin, cả chín category kỹ thuật này đều có thể gom vào bốn skill type. Và bốn type này áp dụng được cho cả người làm kỹ thuật lẫn người không làm kỹ thuật.

3. Bốn skill type: utility, verification, data enrichment

Skill type số một là utility skill. Đây là những thứ nhỏ, dùng lại được, làm đúng một việc cụ thể, và thường được xếp lớp bên trong các skill lớn hơn. Một utility skill kỹ thuật có thể là cách bạn làm việc với một thư viện hay một API cụ thể. Ví dụ phi kỹ thuật là "soạn câu trả lời theo giọng của tôi" (draft response in my voice) hay "viết lại cho đơn giản" (simplify writing).

Skill type số hai là verification skill. Những skill này kiểm tra output cuối cùng của sản phẩm. Trích thẳng từ bài blog của Anthropic: verification skill là loại có tác động đo được lớn nhất lên chất lượng output của Claude trong nội bộ. Austin nói loại này cực kỳ quan trọng nên anh sẽ đi sâu ở một bài học sau. Với use case kỹ thuật, đây có thể là product verification hoặc review chất lượng code. Ví dụ phi kỹ thuật là kiểm tra brand voice hoặc soát theo style guide.

Skill type số ba là data enrichment skill. Loại này kéo dữ liệu bên ngoài vào hệ thống của bạn để làm sản phẩm cuối tốt hơn. Use case kỹ thuật có thể là kéo dữ liệu hiệu năng website, hoặc traffic chuyển đổi (conversion traffic) từ một website. Bản thân Austin làm điều rất giống vậy: anh có một skill tên là Funnel Digest, nhìn qua tất cả các website của anh và phân tích traffic. Use case phi kỹ thuật có thể là phân tích đối thủ, kéo các báo cáo người tiêu dùng gần đây, và tương tự.

4. Orchestration skill và cái bẫy "đứng giữa nhiều nhóm"

Ba type đầu là vậy, còn type thứ tư là orchestration skill: những skill được thiết kế riêng để nối các bước và các skill khác lại với nhau. Austin lấy ví dụ một orchestration skill tên là /generate-report. Nó kéo số liệu analytics của website, việc này có thể là một data enrichment skill. Sau đó nó soạn bản viết (draft a write-up), có thể là một utility skill. Rồi nó kiểm tra branding và các con số, có thể là một verification skill. Tất cả được điều phối cùng nhau để ra một bản báo cáo cuối. Tức là một lệnh duy nhất xếp chồng mọi nhóm khác lên nhau. Austin hẹn sẽ nói kỹ hơn ở bài năm, vì làm loại này phải rất cẩn thận.

Bốn nhóm này giúp bạn nghĩ xem mình thật sự có thể tạo những loại skill nào. Nhưng khi tạo, bạn phải tránh một cái bẫy cụ thể: skill tốt nhất nằm gọn trong đúng một category. Những skill cố làm quá nhiều thứ sẽ đứng giữa (straddle) nhiều category và làm agent bối rối. Vì vậy bạn muốn những skill cụ thể, mỗi cái thuộc một skill type cụ thể.

Với bốn nhóm này trong đầu, Austin đưa một prompt để chạy: nó xem các skill bạn đang có cùng với lịch sử chat trước đây để tìm ra những skill tiềm năng và xếp chúng vào nhóm nào, đồng thời chỉ ra skill nào nên điều chỉnh để nằm gọn trong một nhóm.

Look at my EXISTING skills and my past chat history to find potential skills I should have. For each, tell me which of the 4 buckets it falls into - and flag any existing skill that straddles buckets and could be adjusted to fit one cleanly.

Buckets:
1. Utility - one small reusable thing, every time
2. Verification - checks final output quality
3. Data Enrichment - pulls EXTERNAL data in
4. Orchestration - chains other skills into a multi-step playbook

Rule: the best skills fit cleanly in ONE bucket; ones that straddle several confuse the agent. Orchestration coordinating other skills is NOT straddling.

Do this:
1. Scan my chat history for repeated tasks I do by hand that should be skills. For each: proposed name, bucket, the one job it does.
2. Review my existing skills. Flag any that straddle 2+ buckets, and say how to adjust it to fit one cleanly (split or trim scope).

Be blunt. Focus on real candidates and real straddlers - skip skills that are already clean.

Lưu ý trong prompt có một dòng quan trọng: một orchestration skill điều phối các skill khác thì không bị tính là "straddle". Đó là cách Anthropic nghĩ về các category. Còn khi bạn đã quyết định sẽ tạo skill nào, có vài thành phần then chốt bạn phải đưa vào.

5. Bài 2: skill là một folder, không chỉ là file markdown

Bài học số hai là dùng các power component. Trước khi build bất kỳ skill nào, bạn phải hiểu về mặt khái niệm skill là gì. Austin trích Anthropic: một hiểu lầm phổ biến họ hay nghe là skill chỉ là những file markdown. Nhưng phần thú vị nhất của skill là chúng không chỉ là file text. Chúng là các folder có thể chứa scripts, assets, dữ liệu và nhiều thứ khác mà agent có thể khám phá, tìm hiểu và thao tác.

Tóm lại, một skill là một folder với nhiều thành phần bên trong. Bạn cần hiểu các thành phần này là gì để tối ưu skill. Theo Austin, có ba thành phần quan trọng nhất cần làm đúng.

Thành phần đầu tiên là scripts. Script là code máy tính chạy để hoàn thành một việc. Anthropic viết: một trong những công cụ mạnh nhất bạn có thể đưa cho Claude là code. Đưa cho Claude scripts và thư viện giúp Claude dùng các lượt của nó vào việc kết hợp, quyết định làm gì tiếp theo, thay vì dựng lại boilerplate. Khi tạo một script, bạn cho phép Claude tập trung vào những thứ mới thay vì những thứ nó đã tìm ra rồi.

6. Scripts: tách phần deterministic khỏi phần non-deterministic

Bằng cách tạo script, bạn còn tách được workflow deterministic khỏi workflow non-deterministic. Workflow deterministic là khi cùng một input luôn cho cùng một output: hai cộng hai luôn bằng bốn. Đó là thứ lặp lại được, và một script xử lý việc này hoàn hảo. Workflow non-deterministic thì có thể cùng input nhưng có nhiều output khả dĩ khác nhau, và đó chính là thứ bạn thấy mỗi khi dùng AI.

Bạn càng đẩy nhiều phần vào script, output càng lặp lại được và bạn càng đốt ít token. Vì vậy, hãy cố cho skill dùng code để chạy phần deterministic và dùng AI cho phần non-deterministic. Austin hứa sẽ đưa một prompt giúp làm việc này ở cuối ba điểm.

7. Assets và templates: để skill thôi ứng biến

Power feature thứ hai là assets / templates. Bên trong một Claude skill, bạn có thể đưa lên những file cụ thể làm template cho output bạn muốn tạo. Ví dụ, nếu output mục tiêu là một bài thuyết trình PowerPoint, bạn có thể đưa lên template của một báo cáo cũ, file này sẽ nằm trong folder assets. Claude sau đó dùng nó làm điểm xuất phát để điền vào cho mọi báo cáo về sau. Và như vậy, nếu bạn đổi template, skill sẽ tự động đổi theo ở output cuối.

Giống như scripts, mục đích ở đây là làm cho skill thôi ứng biến (stops improvising) và bắt đầu làm cùng một việc theo cùng một cách mọi lần.

8. Setup prompts: config.json, AskUserQuestion và arguments

Thành phần thứ ba là setup prompts. Khi build skill, không may là bạn sẽ quên rất nhanh skill hoạt động thế nào. Vì vậy cực kỳ quan trọng là làm cho chúng rõ ràng và dễ dùng. Austin nhắc một câu nổi tiếng: kẻ ngốc nào cũng viết được code mà máy tính hiểu; lập trình viên giỏi viết code mà con người hiểu được. Dịch sang thế giới AI: ai cũng viết được một skill mà Claude hiểu; người giỏi nhất viết skill mà con người cũng hiểu.

Vậy làm thế nào? Có ba việc khi setup skill:

1. Tạo một file config.json. Ở lần chạy đầu, nếu thiếu một giá trị, skill sẽ hỏi bạn đúng thông tin đó. Khi bạn đưa vào, giá trị được lưu lại để các lần chạy sau bạn không phải đưa nữa. Đây là cách setup skill để nó nhớ các việc về sau.
2. Dùng AskUserQuestion tool. Với các phần setup dạng trắc nghiệm, bạn có thể bảo Claude dùng AskUserQuestion tool ngay trong file SKILL.md. Claude sẽ đưa ra lựa chọn có cấu trúc thay vì text tự do. Nó giống luồng phỏng vấn (interview flow) bạn có thể đã thấy trên Claude, nhưng đây là cách bạn ép nó xảy ra bên trong skill của mình. Austin cho xem một skill của anh đang hỏi thẳng anh từng câu, và anh thấy đó là một trải nghiệm rất thân thiện với người dùng.
3. Khai báo arguments. Ở đầu file SKILL.md, bạn có thể khai báo một trường arguments. Khi ai đó gọi skill, trường này nhắc người dùng skill rằng cần input gì để nó chạy đúng.

Với cả ba việc này, Austin nhắn: đừng nghĩ về bản thân bạn hôm nay, hãy nghĩ về bạn của một, hai, ba năm nữa. Dành thời gian và build cho tương lai, đó là người mà ta cần nghĩ tới. Ai theo kênh anh đều biết anh tin vào việc xây những hệ thống bền vững, cộng dồn giá trị theo thời gian (compound over time), và anh không thể nhấn mạnh đủ điều này quan trọng thế nào.

Đây là prompt để audit mọi skill trong project và chỉ ra skill nào nên dùng ba thành phần trên:

Audit every skill in my project. For each one:

Flag what's missing or weak and suggest improvements:
  - Is there a deterministic part that should be a script?
  - Is there a templated output that should live in assets/?
  - Is there a config value being re-entered that should
    live in config.json?
  - Would AskUserQuestion clean up multiple-choice setup?
  - Should it accept an `arguments` frontmatter field for
    invocation-time inputs (slug, file path, target)?

For each, suggest how we can improve them and what changes would be needed.

9. Bài 3: verifier, hai kiểu kiểm tra

Giờ bạn đã biết những gì có thể đặt bên trong folder. Có một nhóm Austin đã chạm tới trước đó mà cần đào sâu hơn, và đó là nhóm Anthropic xếp là quan trọng nhất trong mọi category skill. Bài học số ba là tập trung vào verifier.

Trích Anthropic: verification skill là loại có tác động đo được lớn nhất lên chất lượng output của Claude trong nội bộ; thậm chí đáng để một engineer dành nguyên một tuần chỉ để làm cho các verification skill thật xuất sắc. Ngay cả người tạo ra Claude Code cũng từng nói: nếu bạn cho Claude một cách để tự kiểm tra, chất lượng output sẽ tăng gấp 2 tới 3 lần.

Điều phần lớn mọi người bỏ lỡ là có hai kiểu verification bạn cần hiểu:

• Verify cho đúng (correctness). Claude có lấy đúng sự thật không? Các con số có đúng không? App có chạy không? Nó có làm đúng việc phải làm không? Đây là những output đo đếm được hơn.
• Verify cho chất lượng (quality). Output có thật sự đạt tới mức chuẩn (the bar) bạn muốn không?

Theo Austin, 99% mọi người nghĩ về AI như một multiplier: số lượng nhiều hơn, chất lượng như cũ. Nhưng cá nhân anh thấy AI có giá trị nhất khi là một amplifier: số lượng như cũ, chất lượng cao hơn. Bằng cách coi Claude skill là một lớp kiểm tra chất lượng, bạn nâng chuẩn cho mọi output mình làm ra. Cả hai kiểu verification đều quan trọng. Vậy setup chúng thế nào?

10. /verify, /run và skill-driven verification

Ngay khi vừa cài, Anthropic đã có sẵn hai skill trong Claude Code: /verify chạy app của bạn và xác nhận một thay đổi code thật sự làm đúng điều nó phải làm, còn /run khởi chạy app để Claude nhìn thấy kết quả công việc của chính nó. Cả hai là ví dụ kỹ thuật và bạn có chúng mặc định, khá tiện.

Nhưng nếu bạn muốn tự làm verification skill thì sao? Điều then chốt mà mọi verifier tốt cần là một output khách quan (objective output): thứ mà bạn hoặc Claude đều nhìn vào là biết test đã pass hay chưa. Ví dụ, nếu bạn có skill /code-reviewer, bạn muốn nó nói pass hay fail. Nếu bạn có một skill review báo cáo, bạn muốn nó chấm điểm trên thang 10.

Bạn có thể build các verifier này từ đầu, nhưng Austin thích làm khác. Anh thích sửa các skill sẵn có để chúng có một thành phần verification rõ ràng, và gọi cách này là skill-driven verification. Ví dụ, bạn có một skill brand voice. Bạn có thể thêm vào nó một thành phần verification để khi chạy /brand-voice, nó cho bạn biết output pass hay fail. Về bản chất, bạn chỉnh các skill đang có để chúng ra output dễ kiểm hơn.

Để làm việc này, Austin đưa hai prompt. Prompt đầu audit các skill đang có xem cái nào có thể chỉnh thành verifier. Prompt thứ hai giúp bạn build một verifier từ đầu và chỉ ra những công cụ bên ngoài bạn cần để kéo dữ liệu vào kiểm output.

Turn Your Skills Into Verifiers

Look at my existing skills and find the ones that could be tweaked into verifiers - or have a verification component added to them.

A good verifier has an OBJECTIVE output: a clear Pass/Fail, or a grade out of 10. It checks one of two things:
- Correctness - are the facts, numbers, and quoted sources real and right?
- Quality - does the output actually meet the bar I want?

Do this:
1. Scan my skills. Flag any that PRODUCE output but never CHECK it (writers, generators, drafters). For each: what would a Pass/Fail or grade check on its output look like?
2. Flag any skill that already verifies something but gives a vague, subjective verdict. Say how to make its output objective (Pass/Fail or /10).
3. Recommend which existing skill to BORROW from instead of building new - e.g. a brand-voice skill a /report-reviewer could call to pass/fail tone.

Rank by impact: which 2-3 tweaks would raise output quality the most. Be blunt, skip skills that don't apply.

Build a Verifier from Scratch

Help me build a verification skill from scratch for: [WHAT I WANT TO VERIFY].

A good verifier has an OBJECTIVE output - Pass/Fail, or a grade out of 10 - that either I or Claude can read at a glance. It checks correctness (facts/numbers/sources real) and/or quality (meets the bar).

Do this:
1. Define the objective verdict: is this Pass/Fail or a graded score? List the exact criteria it checks, each one testable.
2. Identify what EXTERNAL data the verifier needs to do its job, and which tool pulls it in (YouTube API, web search, analytics, a file, etc.). Flag anything I don't already have wired up.
3. Tell me if an EXISTING skill already covers part of this - reuse before building.
4. Draft the skill: name, bucket (it's Verification), inputs, the check steps, and the exact format of the Pass/Fail or grade output.

Keep it to ONE job. If it's trying to verify more than one thing, split it.

11. Một reviewer mô phỏng chính manager của mình

Khi nghiên cứu cách Anthropic dùng skill, có một ví dụ về verify output nổi bật nhất với Austin. Amol Avasare, head of growth của Anthropic, đã build một verification skill mô phỏng feedback từ chính manager thật của anh. Anh đưa cho Claude dữ liệu từ các bài viết công khai của bà và các cuộc trao đổi trên Slack. Mỗi tuần skill chạy và nói cho anh biết bà sẽ góp ý gì. Về bản chất, đó là phán đoán của bà được mã hoá thành một reviewer.

Austin chèn đoạn Amol tự kể trong một buổi phỏng vấn. Amol nói anh cũng làm vậy cho chính mình: manager của anh là Ami Vora (trên màn hình ghi Head of Product at Anthropic), người từng là khách mời của podcast đó. Anh hỏi Claude đại ý: dựa trên những gì bạn biết về Ami, cả công khai (bà đã viết rất nhiều về product) lẫn nội bộ, và các cuộc trao đổi của chúng tôi, thì dựa trên mọi thứ tôi đã làm hoặc chưa làm trong tuần này, bạn, trong vai Ami, có feedback gì cho tôi? Và tuần nào anh cũng nhận được bản feedback đó.

Nên tới lúc Amol cho manager xem bất cứ thứ gì, nó đã vượt qua chuẩn chất lượng của bản AI clone của bà một lần rồi.

12. Internal focus group và một lời nhắn từ kênh

Austin làm điều rất giống vậy. Anh có một skill tên là /internal-focus-group, chạy qua một nhóm cố vấn, mỗi người cho anh feedback cụ thể về thứ anh đang làm. Trên màn hình, skill hỏi "What would you like feedback on?" với các lựa chọn: ý tưởng video, các phương án tiêu đề, thumbnail, kịch bản, mỗi lựa chọn gọi một nhóm cố vấn khác nhau cộng một bài test với khán giả (click test cho tiêu đề, scroll test cho thumbnail, watch test cho kịch bản). Đây cũng chính là ví dụ AskUserQuestion anh nhắc ở bài hai.

Là founder, anh không thật sự có manager, nhưng nhóm này đóng vai hội đồng cố vấn (board of advisors) của anh. Nó giúp anh nhiều tới mức anh đã build BuildPartner.ai, hiện có hơn một nghìn người dùng, để giúp mọi người làm đúng việc này: bạn chỉ cần gọi /expert-advice và nó sẽ cho bạn feedback từ các chuyên gia về thứ bạn đang làm.

Tới đây bạn đã nắm được vài bài học quan trọng nhất khi dùng skill. Nhưng có một thành phần anh mới học được gần đây và đã bắt đầu đưa vào mọi skill anh làm. Trước khi tới bài bốn, anh chào người mới tới kênh, và với người đã xem từ hai video trở lên, anh nhắc lại "anti-slop agreement" của kênh: hình ảnh, việc test và hàng giờ nghiên cứu trong video là làm cho con người chứ không cho các con robot scraper AI, nên anh chỉ xin mọi người subscribe. Video cũng có một đoạn tặng một gói Claude Max cho người bình luận về thứ họ đang build; người thắng kỳ này đang làm một công cụ tạo báo cáo sáng thứ Hai. Anh cảm ơn khán giả vì kênh vừa đạt 50 nghìn subscriber, sau hơn sáu năm làm video và chỉ gần đây mới bắt đầu có lực kéo (traction).

13. Bài 4: viết gotchas

Bài học số bốn là viết gotchas. Đây là một danh sách chạy dần (running list) các vấn đề Claude gặp phải khi dùng một skill cụ thể. Hãy coi nó như danh sách những điều không được làm bên trong file SKILL.md. Theo một bài blog gần đây, nội dung có tín hiệu cao nhất (highest signal) trong bất kỳ skill nào là phần gotchas. Phần này nên được xây dần từ những điểm hỏng phổ biến mà Claude gặp khi dùng skill của bạn.

Trên màn hình là ba ví dụ gotcha mà team Claude Code có trong skill của họ. Đây chỉ là ví dụ cho thấy khi dùng skill, bạn sẽ dần nhận ra các vấn đề. Gotcha là gì thì đã rõ: một danh sách những điều không được làm. Nhưng có một điểm ở tầng meta làm nó giá trị đến vậy.

Rốt cuộc, đây là skill của bạn, và skill là những tài liệu sống (living, breathing documents). Thực tế là bạn sẽ không làm đúng ngay lần đầu. Những edge case kia, đơn giản là bạn chưa trải qua thôi. Càng dùng skill nhiều, bạn càng thêm nhiều gotcha. Và chính việc thêm gotcha trở thành một forcing function buộc bạn thật sự dùng skill và test nó.

Austin cho xem đoạn Anthropic nói đúng điều này: phần lớn những skill tốt nhất của họ bắt đầu chỉ với vài dòng và một gotcha duy nhất, rồi tốt dần lên vì mọi người cứ thêm vào khi Claude gặp các edge case mới.

Hình minh hoạ cho thấy một skill có thể trông thế nào ở tháng một, tháng hai, tháng ba. Nên nếu skill của bạn chưa hoàn hảo ngay ngày đầu thì đừng lo, vì skill nên tốt lên theo thời gian, và gotchas là một trong những cách hiệu quả nhất để làm điều đó.

14. Gotchas là moat, và đừng viết trước

Austin tóm bằng một hình ảnh: hãy coi skill là cấu trúc (structure), verifier là đòn bẩy (leverage), còn gotchas là con hào riêng của bạn (personal moat).

Có thể bạn đang nghĩ: thôi cứ thêm luôn một danh sách mọi gotcha ngay từ đầu. Austin nói cực kỳ quan trọng là đừng cố đốt cháy giai đoạn. Bạn chỉ nên ghi những thứ bạn thật sự đã thấy hỏng. Nếu Claude chưa từng làm sai điều đó, bạn chưa cần gotcha cho nó. Hãy chờ, quan sát, rồi mới thêm.

Để đưa gotchas vào skill, anh đưa prompt sau:

Analyze my skills and my conversation history and suggest any Gotchas that I should Add to them.

Make a file that is formatted so I can click a box in Obsidian to approve or deny any gotchas that are being added.

Một sở thích cá nhân của Austin: anh thích định dạng file output của những lần rà soát kiểu này để có thể duyệt hoặc từ chối các thay đổi trong một file duy nhất. Nên anh cho nó tạo một file markdown định dạng cho Obsidian.

Anh thích chỉ việc bấm qua từng mục và ký duyệt những gotcha mà anh thật sự muốn đưa vào. Lý do: anh không muốn bất kỳ gotcha nào không phải gotcha thật nằm trong phần đó của file.

15. Bài 5: tune trigger qua trường description

Tới đây ta đã học Anthropic dùng skill thế nào, cách tối ưu chúng, rồi cấu hình chúng bằng gotchas. Nhưng làm sao thật sự gọi chúng, và làm sao đảm bảo chúng được dùng trong công việc hằng ngày? Bài học số năm là tune trigger.

Trigger là thứ kích hoạt skill, là cách nó thật sự được chạy. Giả sử chính bạn là trigger: khi bạn gõ /draft-email vào Claude rồi bấm gửi, bạn đang trigger skill đó. Nhưng đó là thao tác tay, và ta muốn Claude tự quyết định khi nào chạy nó.

Về mặt kỹ thuật, đây là cách Claude quyết định khi nào dùng một skill. Khi Claude bắt đầu một session, nó dựng một danh sách mọi skill có sẵn kèm description của từng skill. Danh sách này là thứ Claude quét qua để quyết định: có skill nào cho yêu cầu này không? Nghĩa là trường description không phải một bản tóm tắt, mà là mô tả khi nào nên trigger skill. Austin kể lần đầu đọc điều này anh cực kỳ bất ngờ, vì nó không phải điều người ta thường nghĩ. Description nên mô tả cái gì kích hoạt nó.

Một điều kiện trigger tốt làm hai việc: nêu nó phục vụ ai, và khi nào nó nên chạy. Austin lấy ví dụ từ một trong những skill nổi tiếng nhất của Anthropic, frontend-design. Description của nó: "Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics."

Anh không đọc hết, nhưng điểm cần để ý là cụm "use this skill when the user asks to build", rồi liệt kê những cách nói thông thường mà một người hay dùng. Điều đó giúp Claude rất dễ biết khi nào dùng skill. Giờ nếu anh gõ "create me a webpage for this dashboard", Claude sẽ tự biết phải trigger skill frontend-design.

Vậy khi tạo skill, hãy nói rõ nó làm gì, và nghĩ về chính những chữ bạn gõ khi gọi nó. Đó là những chữ Claude cần thấy trong description.

16. Skill gọi skill, và tổng kết năm bài học

Đó là cách khiến Claude gọi một skill. Nhưng skill có gọi được skill khác không? Câu hỏi này dẫn về skill type đã nhắc ở đầu: orchestration skill, nối nhiều skill lại với nhau. Làm loại này rất đơn giản. Theo Anthropic, bạn chỉ cần nhắc tên các skill khác và model sẽ gọi chúng nếu chúng đã được cài.

Nhưng chìa khoá của mọi orchestration skill tốt là chúng nên được dựng từ các skill khác. Nếu bạn đang build một workflow phức tạp từ đầu, hãy tự hỏi: mình có thể tách nó thành các utility skill con không? Vì utility skill dùng lại được cho nhiều orchestration skill, nên bạn không bị chồng chéo hay phát minh lại bánh xe. Một lợi ích nữa: nếu bạn cập nhật utility skill, orchestration skill gọi nó cũng tự động được cập nhật theo. Điều đó làm cả hệ thống dễ bảo trì hơn nhiều.

Austin đưa prompt cuối để audit skill và đề xuất cải tiến cho mọi thứ trong bài này:

Audit every skill I have and for each:

1. Read the description in the frontmatter. Tell me if it reads as a SUMMARY (describes what the skill is) or a TRIGGER CONDITION (tells Claude WHEN to fire and WHO it serves).

2. If it's a summary, rewrite it as a trigger condition. Include the exact phrases I'd say to invoke the skill, OR the domain framing that should fire it.

3. For any skill that could use another skill to help complete the task, call those skills explicitly in the skill itself.

Summarize any changes before making them.

Tổng kết lại, giờ bạn đã hiểu các category của skill và cách xếp nhóm, các thành phần then chốt cần tối ưu, cách build verifier, cách cấu hình gotchas để tạo moat, và cách build trigger đúng. Theo Austin, cả năm bài học đã được thử lửa (battle tested) bởi chính anh và bởi team Anthropic, nên hãy làm theo thật sát, và nếu cần thì xem lại các bài học. Anh kết video bằng lời mời xem tiếp một video khác của kênh về cách các founder của Claude quyết định thứ gì đáng build, với lời khuyên cụ thể về những việc nên và không nên dùng Claude.