8 nguyên tắc build Claude skill tốt từ guide của Anthropic

1. Tám nguyên tắc rút ra từ guide của Anthropic

Ben mở đầu bằng việc kể rằng gần đây anh đã đọc kỹ các guide và tài liệu best practices của Anthropic về Claude skills, và từ đó anh tìm ra tám mẹo, tám kỹ thuật giúp build skill hiệu quả hơn hẳn cho việc tự động hoá công việc. Video này đi qua tám cách đó, từ mức cơ bản tới nâng cao, để bạn build được những skill thật sự tự động hoá công việc một cách đáng tin cậy, chứ không phải chạy lúc được lúc không.

Với những ai chưa biết anh, Ben tự giới thiệu: anh tên là Ben, đã ba lần làm founder, hiện điều hành một AI agency và một trong những cộng đồng AI lớn nhất dành cho người đi làm chuyên nghiệp và chủ doanh nghiệp. Ở đó anh dạy cách dùng AI để tự động hoá công việc hoặc để xây một doanh nghiệp AI. Sau phần giới thiệu ngắn đó, anh đi thẳng vào nguyên tắc đầu tiên, và theo anh có lẽ cũng là nguyên tắc quan trọng nhất trong cả tám.

2. Nguyên tắc 1: làm task một lần cùng Claude, rồi mới biến thành skill

Nguyên tắc đầu tiên là: đừng prompt hay plan cho skill của bạn "thành hình" từ trong đầu nữa. Thay vào đó, hãy làm task đó một lần cùng với Claude, rồi sau đó mới biến nó thành skill.

Ben thừa nhận rằng rất nhiều người, kể cả chính anh trước đây, thường build skill theo cách ngược lại: ngồi nghĩ qua, lên plan cho cả quy trình, rồi đưa cho Claude một prompt rất dài để Claude dựng skill từ cái task mà bạn đang muốn tự động hoá. Nhưng guide của Anthropic nói rõ là nên hoàn thành task trước, khi chưa có skill.

Lý do theo guide là: trong lúc làm việc, bạn sẽ tự nhiên cung cấp context, giải thích các sở thích của mình, và chia sẻ kiến thức về quy trình (procedural knowledge) để đi tới một kết quả tốt. Rồi sau khi đã thật sự hoàn thành task thành công cùng Claude, bạn mới bảo Claude tạo một skill từ chính quy trình đó. Việc này rất dễ: trong mỗi chat có sẵn nút "turn into a skill", hoặc đơn giản là sau khi làm xong task bạn nói với Claude: "please just turn this into a skill".

Lý do đằng sau rất đơn giản. Giống như với con người, nguyên tắc "show, don't tell" (cho xem thay vì kể) hiệu quả hơn nhiều, vì người ta thường rất dở trong việc mô tả một quy trình đang nằm trong đầu mình. Nhưng khi họ thật sự bắt tay làm task đó, việc mô tả lại trở nên dễ dàng.

3. Record a skill: để Claude nhìn bạn làm

Ben nói phương pháp trên còn hiệu quả hơn và dễ làm hơn nữa với một số loại task nhờ tính năng mới "record a skill". Theo anh, đây thật lòng là một trong những tính năng bị đánh giá thấp và ít được dùng nhất trong Claude hiện nay.

Cách hoạt động: bạn tự làm một lần cái task mà bạn đang muốn tự động hoá, vừa làm vừa giải thích bạn đang làm gì và tại sao. Claude ghi lại màn hình và mọi cú click của bạn, đọc phần chuyển giọng nói thành chữ để hiểu tại sao bạn làm như vậy, và khi bạn bấm dừng, nó tự động biến toàn bộ quy trình đó thành một skill.

Ví dụ của Ben: anh đã build skill email triage (phân loại hộp thư) của mình bằng chính phương pháp này. Lý do là anh thấy cách này làm lộ ra rất nhiều thứ khó diễn đạt quanh một task, những thứ bạn sẽ bỏ sót khi chỉ cố giải thích task đó bằng lời, so với khi bạn thật sự làm nó.

Vì vậy Ben khuyên mạnh mẽ: hãy lấy tính năng record a skill, hoặc cách làm task một lần cùng Claude rồi biến nó thành skill, làm cách build skill mặc định của bạn. Bạn sẽ thấy rằng nhìn chung những skill build theo cách này chạy hiệu quả hơn hẳn so với skill được prompt cho thành hình.

4. Nguyên tắc 2: skill tập trung, mỗi skill một việc

Nguyên tắc then chốt thứ hai khi build skill là build những skill tập trung, chuyên cho một task cụ thể. Ben nói đây cũng là điều anh tự học được qua thực tế, và anh thấy đây là một trong những lỗi phổ biến nhất mọi người mắc phải khi build skill: làm skill quá rộng, hoặc nhồi quá nhiều task vào cùng một skill.

Guide chuyên sâu của Anthropic về việc build skill nói cụ thể rằng những người tạo skill hiệu quả nhất sẽ lặp đi lặp lại (iterate) trên một task duy nhất trước khi mở rộng skill. Còn trong guide best practices, Anthropic nói rõ là nên giữ skill nhỏ về phạm vi, tập trung, và tạo các skill riêng cho các workflow khác nhau, bởi vì nhiều skill tập trung kết hợp với nhau tốt hơn một skill lớn.

5. Bắt đầu từ phần nhỏ nhất vẫn còn giá trị

Vậy làm sao biết mình đã nhét quá nhiều thứ vào một skill? Ben chia sẻ cách anh nghĩ về chuyện này, cũng là cách AI agency của anh làm scoping cho dự án: khi nhìn vào toàn bộ quy trình bạn muốn tự động hoá hay muốn biến thành skill (anh chỉ vào ví dụ quy trình làm content ở trên), hãy chỉ bắt đầu với phần nhỏ nhất của quy trình mà vẫn mang lại giá trị cho bạn, và build skill quanh phần đầu tiên đó trước.

Trong ví dụ này, chỉ riêng phần research đã mang lại giá trị cho anh rồi. Khi phần đó chạy ổn, từ đó bạn có thể mở rộng ra, hoặc, thường còn tốt hơn, build các skill riêng cho phần còn lại của workflow. Ben không nhồi tất cả vào một skill. Anh tách chúng ra, rồi nếu muốn thì chạy từng skill riêng trong cùng một cửa sổ chat.

Một lợi ích nữa đi kèm: skill file nhỏ hơn cũng giữ cho context window sạch hơn, nghĩa là AI của bạn sẽ thật sự làm việc tốt hơn.

6. Nguyên tắc 3: skill là business process, không phải file đã xong

Nguyên tắc tiếp theo là đối xử với một skill như một business process (quy trình kinh doanh), chứ không như một file đã hoàn thiện. Như các guide của Anthropic viết, skill là tài liệu sống (living documents). Nên cũng như mọi quy trình kinh doanh khác, chúng cần được cập nhật khi mọi thứ thay đổi hoặc khi xuất hiện edge case mới.

Trong một bài blog, Anthropic kể rằng những skill tốt nhất của họ bắt đầu chỉ với vài dòng, và chúng tốt lên vì mọi người cứ tiếp tục bổ sung vào mỗi khi Claude gặp phải edge case mới. Ben nói chính anh cũng thấy điều này: hiếm khi skill hoàn hảo ngay lần đầu.

Những skill tốt nhất của Ben, có lẽ anh đã lặp lại và cập nhật chúng ít nhất năm tới mười lần. Và có những skill chỉ thật sự trở nên hữu ích sau ngần ấy lần lặp.

7. Claude A để xây, Claude B để test

Anthropic còn khuyến nghị dùng một chat chỉ để build và tinh chỉnh skill, và một chat riêng để test skill, nhằm đảm bảo việc test không bị thiên lệch. Cụ thể: khi đã có phiên bản đầu tiên với Claude A, bạn test skill trên một workflow thật với Claude B. Nếu Claude B mắc lỗi, bạn kể lại lỗi đó cho Claude A và nhờ Claude A tinh chỉnh skill.

Một lần nữa, mục đích là để việc test không bị thiên lệch, và để mỗi agent có một trọng tâm cụ thể: một bên chỉ lo xây và sửa, một bên chỉ lo dùng như trong công việc thật.

Và vòng lặp đó, tất nhiên, bạn có thể lặp lại nhiều lần.

8. Self-improvement rule: mỗi lần sửa là skill tự cập nhật

Nếu bạn hay gặp edge case, bạn thậm chí có thể thêm một self-improvement rule (quy tắc tự cải thiện) vào skill. Về cơ bản đó là một dòng chỉ dẫn cho Claude rằng mỗi lần bạn sửa nó trong chat, chỗ sửa đó sẽ tự động được cập nhật vào skill file. Ben mở skill email triage của mình để cho xem: trong skill có một mục quy định rằng sửa xong thì lưu luôn vào skill, không để dồn lại, và một mục "learned rules" để trống, sẽ dần được lấp đầy mỗi khi anh sửa các mặc định ở trên.

Thêm self-improvement rule rất đơn giản, chỉ cần nói với Claude một câu kiểu như:

Add in a self-improvement rule that instructs the skill that whenever I give a new update, point out a correction or mistake, it automatically updates the skill with a new rule.

Ben nhắc rằng nếu bạn muốn có tất cả các prompt trong video này, cùng với một skill creator skill do chính anh phát triển (skill này tự động áp dụng mọi best practice trong video khi bạn build skill mới hoặc tối ưu skill có sẵn), bạn có thể tải miễn phí từ link trong phần mô tả video.

9. Nguyên tắc 4: thêm ví dụ input và output

Nguyên tắc tiếp theo nghe có vẻ hiển nhiên, nhưng Ben nói nhiều người vẫn chưa làm: thêm ví dụ input và output. Đây là một trong những best practice được nhắc tới nhiều nhất trong các guide về skill: với những skill mà chất lượng output phụ thuộc vào việc được thấy ví dụ, hãy cung cấp các cặp input và output, giống hệt như khi prompt bình thường.

Lý do tất nhiên là ví dụ truyền đạt phong cách và mức độ chi tiết mong muốn cho Claude rõ ràng hơn nhiều so với chỉ mô tả bằng lời. Và ví dụ là một trong những cách đáng tin cậy nhất để điều khiển định dạng, giọng văn (tone) và cấu trúc output của Claude.

Theo kinh nghiệm của Ben, có output example tốt là điều cực kỳ then chốt cho các use case về design, copy hoặc sáng tạo. Anh khuyên nên có ít nhất ba tới năm ví dụ tốt. Nhưng anh đã thấy, đặc biệt với copywriting, có khi tới 20 ví dụ còn cho output tốt hơn hẳn trong skill. Lại là nguyên tắc "show, don't tell". Nên khi build skill, hãy thật sự dành thời gian đưa cho nó vài ví dụ tốt, nếu bạn có.

Còn nếu chưa có ví dụ tốt, bạn có thể lấy từ người khác. Hoặc một cách dễ để dần dần xây kho ví dụ là, một lần nữa, thêm self-improvement rule để mỗi lần chạy skill, output tốt sẽ tự động được lưu lại. Bạn chỉ cần thêm một rule vào skill bằng một prompt kiểu như sau (đây là bản Ben để trong bộ tài liệu của mình):

Add a self-improvement rule to this skill. Any time I correct your output during the process, or I get an output I explicitly like, ask me whether that should become a permanent update to the skill. If I say yes use the skill-creator to update the relevant SKILL.md step or reference file with the correction, new rule, or saved example. Always ask the confirmation question first, never update the skill silently.

Nói cách khác: mỗi khi bạn sửa output trong lúc chạy quy trình, hoặc nhận được một output mà bạn nói rõ là thích, Claude sẽ hỏi bạn có muốn biến nó thành thay đổi vĩnh viễn trong skill không. Nếu bạn đồng ý, nó cập nhật skill với ví dụ đã lưu. Ben nhắc lại là prompt đầy đủ nằm trong bộ tài liệu miễn phí.

10. Nguyên tắc 5: progressive disclosure cho reference file

Nguyên tắc tiếp theo là đưa progressive disclosure (tiết lộ dần dần) vào skill. Nhưng trước khi tiếp tục, video có một đoạn quảng cáo ngắn cho chương trình AI Accelerator của chính Ben (khoá học về Claude, khoá học xây doanh nghiệp AI, tư vấn trực tiếp và thư viện skill, template).

Quay lại nội dung: engineering blog của Anthropic viết rằng progressive disclosure là nguyên tắc thiết kế cốt lõi khiến agent skill linh hoạt và mở rộng được. Và nhờ progressive disclosure, lượng context có thể đóng gói vào một skill về cơ bản là không giới hạn. Nhưng nếu bạn không áp dụng đúng, nó sẽ làm giảm hiệu năng.

Theo kinh nghiệm của Ben, chính skill creator skill của Anthropic không phải lúc nào cũng áp dụng tốt nguyên tắc này. Vậy progressive disclosure thực ra nghĩa là gì? Một skill có thể gồm một file SKILL.md mô tả quy trình cần làm theo, và một thư mục reference chứa các file bổ sung và context thêm. Ai cũng biết skill và agent làm việc tốt hơn khi được cho nhiều context hơn, và ta có thể đưa context đó vào các reference file bên trong skill. Ví dụ skill viết newsletter của Ben có thêm context về background của anh, về những gì công ty anh làm, về ICP (chân dung khách hàng lý tưởng), về giọng văn và tính cách, và các ví dụ.

Nhưng progressive disclosure về cơ bản có nghĩa là ta chỉ muốn agent dùng reference file khi thật sự cần, chứ không bắt nó đọc tất cả ngay từ đầu khi bắt đầu dùng skill. Vì nếu nạp hết các file context này cùng lúc, chúng sẽ làm ô nhiễm context window và khiến hiệu năng kém đi. Nên ta muốn đảm bảo skill chỉ đọc đúng những reference file liên quan ở từng bước trong quy trình.

Trong skill newsletter của mình, ở mỗi bước Ben ghi rõ những reference file mà agent phải đọc trước khi thực hiện bước đó. Anh làm vậy cho từng bước trong quy trình: bước tiếp theo nó đọc một file khác, và cứ thế. Cách này chạy tốt hơn hẳn so với việc Claude đọc mọi thứ ngay từ đầu, vì khi đó tới bước cuối nó bắt đầu quên hết.

Một lần nữa, theo kinh nghiệm của Ben, skill creator skill của Anthropic không thường tự động áp dụng nguyên tắc này. Nên bạn có thể dùng một prompt anh chuẩn bị sẵn (copy được từ link trong phần mô tả), hoặc dùng skill creator skill của anh, vốn tự động áp dụng nguyên tắc này khi build hoặc cập nhật một skill có sẵn.

11. Nguyên tắc 6: bắt buộc dùng sub-agent cho bước research

Mẹo quan trọng tiếp theo là bắt buộc dùng sub-agent cho các bước research hoặc điều tra. Anthropic nói cụ thể rằng context window là ràng buộc nền tảng của bạn, nên ta cần dùng sub-agent để giữ phần research ở ngoài context window chính.

Lý do: rất nhiều skill thật ra đi theo một pattern quy trình rất giống nhau. Đầu tiên là lấy dữ liệu từ đâu đó, từ internet hoặc từ các phần mềm của bạn. Sau đó diễn giải dữ liệu đó. Rồi tạo ra một thứ hữu ích từ nó.

Ví dụ, một skill phân tích dữ liệu trước hết phải đi qua các phần mềm của bạn, kéo dữ liệu ra và diễn giải nó, rồi tạo một bản báo cáo hay một dashboard đẹp. Một skill lên ý tưởng (ideation) sẽ research trên internet, rồi lọc các ý tưởng và tạo ra những gợi ý tốt cho bạn. Rất nhiều skill đi theo pattern tương tự.

Vấn đề là MCP hay connector dùng để lấy dữ liệu ban đầu đốt rất nhiều token. Và vì tốn nhiều token, nó làm ô nhiễm và lấp đầy context window ngay từ đầu, khiến Claude làm việc kém đi đáng kể ở đúng bước quan trọng nhất của skill: diễn giải dữ liệu và tạo ra thứ hữu ích từ nó. Lý do đơn giản là context window càng đầy token, Claude càng "ngu" đi.

Vì vậy nếu skill có một bước research hoặc bước gọi connector ở đầu, bạn muốn đảm bảo bước đó được làm bằng sub-agent: sub-agent làm phần việc đó, rồi chỉ gửi lại một bản tóm tắt cho main agent. Bản tóm tắt đó không làm ô nhiễm context window nhiều, nên agent của bạn vẫn giữ được hiệu năng cao khi làm những bước quan trọng nhất.

Đôi khi Claude tự động làm điều này, nhưng rất thường là không. Nên thêm một rule đơn giản để bước điều tra ban đầu chạy qua sub-agent có thể lập tức cải thiện đáng kể chất lượng output của skill.

Ví dụ của Ben là skill lên ý tưởng tiêu đề video (Title Ideation), skill này trước tiên research những tiêu đề hiệu quả nhất cho một chủ đề cụ thể trên YouTube. Trong đó anh có một chỉ dẫn cụ thể: mọi lệnh gọi connector đều chạy bên trong một sub-agent, để nó không làm ô nhiễm context window khi agent thật sự diễn giải dữ liệu và đưa ra gợi ý tiêu đề tốt.

Ben cũng để sẵn một prompt để bạn build skill mới hoặc cập nhật skill có sẵn sao cho nó có rule này. Bản trong bộ tài liệu của anh:

Use the skill creator skill to update this skill so it keeps connectors and research out of the main context. Store any data that doesn't need to be current as a reference file instead of fetching it live. For data that has to be current, have the skill route the connector call or research through a sub-agent that returns only the clean result, so the main context stays clean and the skill's instructions aren't pushed out. Split heavy connector or research steps into their own separate skill if needed.

Hoặc, một lần nữa, bạn có thể dùng skill creator skill của anh, vốn tự động thêm rule này vào.

12. Nguyên tắc 7: nhiều output ở mỗi checkpoint

Nguyên tắc tiếp theo là để skill đưa cho bạn nhiều output ở mọi checkpoint. Nhiều skill, đặc biệt là skill kiểu copywriting và design, có thể chạy đúng y như thiết kế, nhưng bạn lại không thích angle, cách dùng từ hay hướng đi cụ thể mà nó chọn ở output. Kết quả là bạn vẫn phải lặp đi lặp lại không dứt để sửa và cải thiện output.

Một cách rất dễ để tiết kiệm thời gian trong vòng lặp này là cho skill đưa ra nhiều biến thể (variations). Vì nếu có nhiều biến thể để chọn, khả năng một trong số đó đi đúng hướng cao hơn nhiều. Và kể cả khi vẫn phải lặp lại, bạn cũng sẽ có ít thứ phải sửa hơn.

Ben nói anh đã thêm cách này vào mọi bước human-in-the-loop trong mọi skill của mình, và nó tiết kiệm cho anh rất nhiều thời gian lặp lại. Ví dụ trong skill newsletter, ở bước human-in-the-loop đầu tiên, skill đưa cho anh nhiều biến thể về các angle có thể chọn cho số newsletter này. Thường sẽ có một cái anh thích, hoặc anh chỉ cần sửa một chi tiết nhỏ. Ở bước tiếp theo, dựa trên angle anh đã chọn, nó tạo ra ba biến thể dàn ý (outline) cho newsletter. Một lần nữa, anh chọn một cái, chỉnh vài chỗ nhỏ, và lái nó ngày càng đúng hướng để đi tới bản newsletter cuối cùng. Anh làm vậy cho từng bước: tới subject line, tới phần copy của newsletter.

Cách này thật sự làm workflow nhanh hơn, và bạn kiểu như đang dẫn dắt model đi tới một output tốt. Ben nói rõ mẹo này không lấy từ guide best practices của Anthropic, nhưng thực ra đó là cách Anthropic thiết kế nhiều skill của chính họ, và anh lấy ý tưởng từ đó.

Vậy là chỉ một rule đơn giản bạn có thể thêm vào skill. Ben cũng để sẵn prompt nếu bạn muốn cập nhật hoặc build skill mới có sẵn rule này, hoặc bạn có thể dùng skill creator skill của anh (cũng nằm trong bộ tài liệu miễn phí) để tự động gắn rule này vào skill.

13. Nguyên tắc 8: tắt auto-trigger khi bạn không muốn

Nguyên tắc cuối cùng là chặn skill tự kích hoạt (auto-trigger) nếu bạn không muốn nó tự kích hoạt. Skill tất nhiên có thể được gọi bằng slash command, nhưng cũng có thể tự kích hoạt nếu Claude nghĩ skill đó liên quan tới task bạn đưa. Claude quyết định điều đó bằng cách đọc description của skill.

Theo kinh nghiệm của Ben và của nhiều người khác, khi muốn dùng một skill, bạn luôn gọi bằng slash command. Còn auto-trigger thường khiến model kích hoạt skill vào lúc bạn không hề muốn.

Nhiều người không biết là điều này làm được, nhưng Anthropic thật ra đã cho phép tắt auto-trigger. Tất cả những gì ta cần thêm vào skill là một rule tên disable-model-invocation và đặt nó thành true. Ví dụ trong skill LinkedIn writer của Ben, ngay trên cùng có dòng "disable model invocation: true". Điều đó có nghĩa là Claude không thể tự kích hoạt skill này, nhưng anh vẫn dùng được nó bằng slash command.

Cách này còn có thêm một lợi ích: giờ description của skill không còn được nạp vào mỗi chat mới với Claude nữa, nên context window sạch hơn. Ben nói làm việc này khá dễ. Bạn có thể dùng prompt sau (cũng nằm trong bộ tài liệu miễn phí):

Make this a human-triggered skill only. I don't want Claude to auto-invoke it. Set disable-model-invocation: true in the frontmatter, and keep the description short as a display fallback only. It should only ever run when I type the slash command.

Hoặc bạn có thể dùng skill creator skill của Ben: nó sẽ hỏi bạn có muốn skill tự kích hoạt hay không, và dựa vào câu trả lời đó, nó sẽ tự động gắn rule này vào skill.