Quy trình năm bước Matt Pocock dùng để làm Claude skill

1. Matt Pocock và quy trình năm bước đằng sau mọi skill

Austin mở đầu bằng một con số: Matt Pocock là người có những Claude skill được cài nhiều nhất hành tinh, với hơn 22 triệu người đang dùng. Vì vậy Austin quyết định đào sâu xem chính xác Matt tạo skill như thế nào, và kết quả làm anh bất ngờ. Anh bước vào với kỳ vọng sẽ gặp những quy trình cực kỳ phức tạp. Nhưng sau khi phân tích mọi video Matt từng đăng và mọi skill Matt từng tạo, anh nhận ra Matt có một quy trình năm bước, dùng cho việc tạo mọi skill.

Điều đáng tiếc, theo Austin, là video của Matt cực kỳ kỹ thuật, phần lớn nội dung của Matt dành cho kỹ sư. Nên trong video này Austin sẽ đi qua từng bước trong năm bước Matt dùng để tạo skill, đơn giản hoá nó, rồi nói chính xác cách bạn áp quy trình này vào công việc hằng ngày để skill của bạn tốt hơn và bạn build nhanh gấp mười lần. Cuối video, anh sẽ nói lý do vì sao Matt cho rằng bạn đừng bao giờ sao chép mù quáng skill của người khác.

2. Bước 1: skill là một lần sửa mà bạn đã chán phải làm

Bước một là về việc để ý (notice), cụ thể là để ý thứ mà bạn cứ phải gửi trả lại (send back). Austin kể anh đã nghe rất nhiều cách giải thích Claude skill thật ra là gì: đó là một prompt dùng lại được, đó là một quá trình dạy Claude một điều mới. Những cách nói này không sai.

Nhưng Matt có một trong những định nghĩa Austin thích nhất mà anh từng gặp: một skill là một lần sửa mà bạn đã chán phải làm (a skill is a correction you are tired of making). Austin chiếu đoạn Matt giải thích ý này trên một podcast. Matt kể: anh đi ăn nhà hàng, gọi một đĩa salad chorizo, và nhận về một chiếc bánh sandwich chorizo. Vậy là anh phải gửi trả lại. Và điều Matt nhận ra là anh cứ phải gửi trả lại đồ cho AI suốt.

Nói cách khác, lý do then chốt để tạo một skill không phải là thứ bạn làm với Claude thường xuyên nhất. Mà là thứ bạn cứ phải sửa đi sửa lại. Nếu model đã làm đúng một việc ngay từ lần đầu, thì một skill cho việc đó chỉ là thứ phình to không cần thiết (unnecessary bloat). Austin nói đây cũng chính là một phần lý do vì sao người tạo ra Claude Code từng bảo mọi người hãy xoá hết Claude skill của mình: nếu Claude vốn đã làm đúng, skill đó chẳng làm gì ngoài việc tốn token. Với framework của Matt, về bản chất Matt nói: nếu Claude không làm đúng ngay lần đầu, hãy gửi trả lại.

Austin bảo điều này làm anh nhớ tới cảnh trong phim The Office, khi Michael Scott gọi món: "Cho tôi mì spaghetti với một phần salad ăn kèm. Nếu salad mà để trên đĩa mì, tôi sẽ gửi trả lại." Đúng cái năng lượng Michael Scott đó. Nếu model làm sai, hãy tạo một skill, để bạn khỏi phải gửi trả nữa.

3. Asset rush: vì sao model càng giỏi bạn vẫn phải gửi trả

Câu hỏi đặt ra là: vì sao bạn vẫn cứ phải gửi trả mọi thứ khi model ngày càng tốt hơn? Matt có một câu trả lời cụ thể, và anh gọi nó là asset rush. Trong đoạn Austin chiếu, Matt nói model có chút gì đó mà anh gọi là asset rush: nó lao tới việc tạo ra một sản phẩm (asset), giống như hoàn thành quá sớm (premature completion).

Nói theo ngôn ngữ đời thường, điều này có nghĩa là các model được huấn luyện để làm cho xong, để tạo ra một thứ gì đó ngay bây giờ. Framework mà Austin thích là hãy nghĩ về model như một cậu học sinh quá hăng hái (over eager student): giơ tay lên, câu trả lời đã sẵn sàng trước cả khi cậu chắc nó đúng.

Vì vậy khi tự làm skill, hãy để ý tránh việc chạy dồn các bước từ đầu tới cuối. Khi skill của bạn không tập trung vào một bước duy nhất của quy trình, bạn rơi vào vùng nguy hiểm của vấn đề asset rush. Nói thẳng hơn, nếu không làm vậy, bạn sẽ tạo ra AI slop.

Vậy thay đổi trong tư duy ở đây là: suốt ngày làm việc, đừng hỏi bản thân "hôm nay mình đã dùng AI vào việc gì?" nữa, mà hãy bắt đầu hỏi "mình đã phải gửi trả lại cái gì?". Rồi khi đã có câu trả lời, hỏi tiếp: đó là bước cụ thể nào của quy trình?

Austin đưa một prompt bạn có thể chạy ngay bây giờ để quét lịch sử hội thoại của 30 ngày qua, đánh dấu những chỗ bạn đã gửi trả lại, để xem các ứng viên đó có thể trở thành một skill dùng lại được hay không. Trên màn hình, prompt có tiêu đề "Flag what you sent back":

Scan my conversation history from the past 30 days.
Flag every place I sent something back: where I corrected, redid, or re-explained what you gave me.

Group the repeats. For each one, show me my correction
in my own words and the specific step of the process it happened in.

Rank which ones are candidates to become a skill.
Stop at the ranked list.

4. Bước 2: dùng leading words, mượn chữ model đã biết

Tới đây bạn đã biết thứ gì cần một skill, nhưng làm sao để thật sự tạo ra nó? Bước hai là về việc dùng leading words: bạn mượn một từ mà model đã biết sẵn. Khi tạo skill, bạn muốn tránh bắt đầu từ con số không, hay giải thích lại một thứ mà Claude đã hiểu rồi. LLM có lượng dữ liệu huấn luyện khổng lồ, đến mức có những từ cụ thể, gọi là leading words, lập tức hướng Claude kéo kiến thức từ khối dữ liệu đó ra. Nên nếu bạn chọn đúng từ, cái từ mà model đã biết rất sâu, bạn đơn giản hoá được cả skill một cách triệt để.

Austin chiếu tiếp một đoạn Matt giải thích, và dặn nếu nghe có vẻ kỹ thuật thì đừng lo, anh sẽ đơn giản hoá ngay sau đó. Matt nói: Refactoring là một cuốn sách rất cũ, được trích dẫn rất nhiều, đến mức những "smell" kiểu này đã nằm sâu trong priors của agent. Trên màn hình lúc đó là một file SKILL.md của Matt, phần process liệt kê các code smell như Mysterious Name, Duplicated Code, Feature Envy, Data Clumps.

Austin giải thích: điều Matt đang nói thật ra rất đơn giản. Chỉ bằng việc nói từ "refactor", bạn đang bảo model kéo kiến thức từ hàng tỷ dòng dữ liệu huấn luyện, cụ thể là về việc refactor code. Còn cách làm ngược lại, giả sử bạn cố giải thích cho Claude refactoring là gì, tức là bạn bắt đầu từ con số không. Thực tế đó là rất nhiều công sức phí phạm, output sẽ không tốt bằng, và đây lại là điều rất nhiều người đang làm. Model đã đọc hết thông tin đó rồi. Bạn không cần dạy lại nó. Bạn chỉ cần dùng một leading word cụ thể để chỉ nó đi đúng hướng.

Austin trích thêm lời Matt: "Một từ tự bịa ra không tuyển được prior nào. Bạn phải trả bằng token định nghĩa cho thứ mà một từ đã có sẵn trong pre-training cho bạn miễn phí" (A made-up word recruits no priors. You pay in definition tokens what a pre-trained word gives free).

5. Những leading word trong skill grill me

Về logic thì điều này bắt đầu dễ hiểu rồi, nhưng có những leading word nào khác? Austin đưa ra vài từ mà Matt dùng trong skill grill me của anh, skill phỏng vấn bạn liên tục để mài sắc một plan.

• Relentlessly (không ngừng, không buông tha): từ này xuất hiện ở cả description lẫn dòng đầu tiên. Theo Austin, riêng từ này đã làm gần hết công việc của cả file.
• Design tree (cây thiết kế): mỗi quyết định rẽ nhánh thành những quyết định khác treo vào nó. Skill bảo agent đi qua cây theo từng vòng (rounds), chứ không phải mỗi lần một câu hỏi.
• Frontier (biên): mọi quyết định mà các điều kiện tiên quyết của nó đã được chốt xong.

Đoạn văn trên màn hình nói rõ hơn: phỏng vấn người dùng không ngừng cho tới khi hai bên hiểu chung một điều; map việc đó thành một design tree, nơi mỗi quyết định rẽ nhánh thành các quyết định treo vào nó; đi qua cây theo từng vòng, frontier là mọi câu hỏi bạn có thể hỏi ngay bây giờ mà không phải đoán câu trả lời bạn chưa nghe; hỏi cả frontier trong một vòng, đánh số từng câu và đưa ra câu trả lời bạn đề xuất, rồi chờ người dùng trả lời trước vòng tiếp theo.

6. Áp leading words vào việc hằng ngày, kể cả việc không kỹ thuật

Austin hỏi: tới đây chắc đã dễ hiểu, nhưng áp vào việc hằng ngày thế nào? Hãy xác định bạn thật sự đang cố làm gì, rồi cân nhắc xem đã có sẵn một leading word cho nó chưa. Có rất nhiều framework đã thành chuẩn mà model đã được huấn luyện, bạn chỉ cần chỉ nó đi đúng hướng.

Nên trước khi viết một skill từ đầu, hãy hỏi thẳng Claude: đã có framework hay thuật ngữ nào được công nhận cho thứ tôi đang mô tả chưa? Rồi bạn chỉ việc dùng từ nó đưa ra, thay cho lời mô tả lủng củng của riêng bạn.

Ví dụ, trên màn hình là một loạt leading word áp được cho những workflow hoàn toàn không kỹ thuật. Đây là vài từ Austin thích nhất:

• SMART goal framework: giúp bạn đặt mục tiêu khả thi.
• Steelman: lập luận cho phía đối lập ở dạng mạnh nhất.
• Premortem: hình dung việc này đã thất bại rồi.
• BLUF (bottom line up front): đặt kết luận lên đầu.
• SPIN discovery: đặt những câu hỏi về pain point.

Anh cũng đưa một prompt để bạn tự kiểm (audit) setup của mình, tìm những chỗ còn thiếu leading word. Vậy là bạn đã có trigger (thứ bạn cứ phải gửi trả) và có từ (leading word).

Trước khi sang phần mà ai cũng làm hỏng, kể cả Austin, tức bước ba, anh nói video đã nói nhiều về sức mạnh của skill, nhưng một giới hạn của chúng là tạo video. Video có một đoạn quảng cáo cho AIQORA, một công ty AI video.

7. Bước 3: less is more, skill 7 dòng với 1,1 triệu lượt cài

Quay lại bước ba: less is more, làm skill nhỏ hơn và khó dùng hơn. Austin nói đây là phần trong nghiên cứu làm anh bất ngờ nhất. Có hai chuyện đang diễn ra ở đây.

Chuyện thứ nhất là độ dài skill. Trên màn hình là skill grill me của Matt trên GitHub: bảy dòng, 22 từ, chỉ vậy thôi. Riêng skill này có 1,1 triệu lượt cài. Rõ ràng skill không cần dài mới hiệu quả.

Toàn bộ nội dung file, đúng như trên màn hình và trong repo:

---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---

Call the Skill tool with "grilling".

Austin chiếu tiếp Matt nói thẳng về điều này: skill không cần dài mới tạo được tác động, bạn chỉ cần chọn đúng từ cho LLM vào đúng lúc. Câu này xây trực tiếp trên phần leading words vừa nói, nhưng giờ ta nhìn skill như một tổng thể, chứ không chỉ một dòng hay một từ bên trong nó.

8. Làm skill khó gọi hơn: tắt model invocation

Chuyện thứ hai là làm skill khó dùng hơn. Với mỗi skill, bạn có thể bật hoặc tắt khả năng Claude tự gọi nó. Việc này gọi là model invocation, và nó chỉ có nghĩa: model có được dùng skill mà không cần bạn bảo không?

Thoạt nhìn, có vẻ bạn muốn model dùng được skill, đúng không? Đó là lý do bạn tạo ra nó. Nhưng khi thật sự nhìn vào các skill của Matt, anh đã tắt khả năng để model gọi chúng, về bản chất là nói: một con người phải gọi skill này. Khi Austin đào xem vì sao, anh tìm thấy hai tweet giải thích điều đó rất trọn vẹn.

Tweet đầu tiên là chính lý lẽ: cognitive load đối lại context load. Cognitive load (gánh nặng cho đầu óc bạn) giảm dần theo thời gian khi bạn giỏi hơn. Context load thì tốn token của bạn mãi mãi. Nếu bạn để model tự gọi skill, description của từng skill sẽ được nạp vào context ở mọi tin nhắn bạn gửi. Việc đó tốn token ở từng lần chạy. Nếu bỏ khả năng đó đi, bạn bỏ được gánh context thường trực, và nó buộc bạn phải nghĩ xem khi nào nên dùng skill nào. Lâu dần, điều này làm bạn giỏi dùng AI hơn, và đổi lại nó chống lại "béo phì trí tuệ" (intellectual obesity), một khái niệm mà Austin nói người xem kênh đều biết là rất quan trọng với anh.

Rồi trong tweet thứ hai, Matt nêu lợi ích thực tế của cách làm này: một lợi ích của việc có bộ skill chủ yếu do người dùng gọi là ta loại bỏ được cả một nhóm lỗi mà bạn không bao giờ phải lo nữa. "Slash to-spec có chạy không?" "Sao slash to-spec lại chạy ở chỗ đó?!" "Sao nó lại chọn slash to-tickets thay vì slash to-spec?!" Bạn giữ quyền kiểm soát. Thêm nữa, nó có nghĩa là phần lớn skill không tốn token nào cho tới khi bạn gọi chúng.

Nên Matt cố ý làm các skill này khó dùng hơn, để model thật sự không thể gọi chúng mà không có anh.

9. Khi Claude tự gọi nhầm skill, và một prompt để rút gọn

Từ kinh nghiệm của chính mình, Austin nói anh chắc chắn đã thấy mặt trái của việc không làm như vậy. Claude sẽ tự động kích hoạt một skill anh không muốn, rồi kéo chậm cả quy trình, hoặc kích hoạt thứ hoàn toàn không cần cho việc anh đang thật sự làm.

Cách áp dụng: Austin đưa một prompt rút gọn các skill hiện có của bạn và đánh dấu skill nào là ứng viên tốt để chuyển sang chỉ cho người dùng gọi. Trên màn hình, prompt có tiêu đề "Simplify" và mở đầu bằng: "Simplify my existing skills. For each one, propose a shorter version that keeps only the lines that change the output."

Trước khi sang bước bốn, Austin nhắc tới "thoả thuận chống slop" của kênh: mọi thứ trong video do con người làm, cho con người. Anh xin người xem subscribe để nội dung tới được nhiều người hơn, kể rằng mỗi video anh tặng một gói Claude Max để cảm ơn người ủng hộ, chúc mừng người thắng của video trước (người đã build một phần mềm quản lý dự án), và mời người xem bình luận xem mình đang build gì để cùng bàn skill có thể giúp gì cho việc đó.

10. Bước 4: lặp theo thời gian, đo bằng vibes và send it back test

Bước bốn: lặp theo thời gian và đừng nghĩ quá nhiều xem nó có hiệu quả không. Bạn đã viết xong skill. Nó ngắn. Nó có đúng leading word. Nhưng nó có hiệu quả không? Những thay đổi của bạn có giúp kết quả cuối cùng không? Làm sao để đo điều đó?

Austin nói đây là chỗ phần lớn mọi người "mid-curve" cả chuyện skill (kiểu người ở giữa đường cong trong meme, nghĩ quá phức tạp). Họ căng thẳng cố định lượng xem skill đã tốt lên hay chưa. Và đó chính là lý do bước này trong quy trình của Matt rất dễ chịu: Matt không đo một cách định lượng xem một thay đổi có làm skill tốt hơn không. Anh chủ yếu dựa vào vibes.

Austin chiếu đoạn Matt nói đúng điều này: ít nhất là về mặt vibes, anh không làm eval ở đây, có lẽ anh nên làm eval cho trường hợp này, nhưng điều anh thấy là mọi người không còn báo lỗi đó nữa. Người có 22 triệu lượt cài không có hệ thống test nào. Anh tự dùng skill khoảng một tuần, và chỉ quan sát xem mọi người có thôi phàn nàn hay không.

Austin thừa nhận bạn sẽ không có nhiều người test như Matt, nhưng rủi ro trong thế giới của riêng bạn cũng cao không kém. Và Matt vẫn chỉ dựa vào vibes. Nên để tự test, bạn không cần cuống lên cố đánh giá xem skill có đang tốt lên không. Bạn chỉ cần dùng nó và chạy cái Austin gọi là send it back test: nếu bạn không phải gửi trả kết quả, skill đang hiệu quả. Thật sự đơn giản vậy thôi.

Và khi làm skill, đừng cố hoàn hảo ở phiên bản một. Hoàn hảo là kẻ thù của cái tốt. Tốt là đủ rồi. Cứ viết skill, rồi lặp từ phiên bản đầu tiên.

11. Mỗi dòng trong skill kể một câu chuyện

Nếu bóc tách cách một vài skill nổi tiếng nhất của Matt được build, mỗi dòng đều kể một câu chuyện. Trên màn hình là lịch sử changelog của skill đó (skill grilling). Austin đọc từng dòng và lý do nó được thêm vào:

• "Give your recommended answer" (đưa ra câu trả lời bạn đề xuất) được thêm vì các cuộc hội thoại bị kéo dài lê thê.
• "Ask one question at a time" (mỗi lần hỏi một câu) được thêm vì việc bắn ra nhiều câu hỏi cùng lúc làm người dùng bối rối (bewildering). Austin khen: thật là một từ hay.
• "Do not enact the plan until I confirm" (đừng thực thi plan cho tới khi tôi xác nhận) được thêm vì agent cứ nhảy cóc lên trước và cứ thế build.
• "Split facts from decisions" (tách sự thật khỏi quyết định) được thêm vì agent bắt đầu tự grill chính nó.

Trên màn hình, commit cho dòng cuối ghi rõ lý do: học viên báo một lệnh khác (wayfinder) nhặt một ticket grilling rồi tự grill chính nó thay vì quay sang hỏi con người; nguyên nhân gốc là một dòng viết cho trường hợp có người thật ("explore the codebase instead") bị hiểu thành giấy phép tự trả lời câu hỏi. Cách sửa dùng câu khẳng định (affirmative framing), không dùng "don't": tách sự thật (tự tra) khỏi quyết định (đưa cho con người và chờ).

Austin chốt: không điều nào trong số này được lên kế hoạch từ trước. Mỗi dòng là một thứ đã hỏng, được để ý thấy, và được sửa bằng một câu bổ sung.

12. Ba việc để test và tinh chỉnh skill

Để khép lại bước này, Austin nói có ba việc cần thật sự làm:

1. Chạy skill trên công việc thật, không phải trên test case.
2. Cuối tuần, để Claude phân tích lịch sử hội thoại tìm mọi chỗ bạn đã gửi trả lại một thứ gì đó, rồi biến những lần sửa lặp lại thành một câu sửa (one sentence fix).
3. Có câu sửa rồi thì dừng lại và thử lại. Đừng thêm bất cứ thứ gì mà bạn chưa tự mình thấy nó hỏng.

Tới đây bạn sẽ cứ lặp và cải thiện skill, và điều đó tạo ra một vấn đề mới mà không ai cảnh báo bạn.

13. Bước 5: cắt bỏ no-op

Bước năm: bạn phải cắt nó đi. Ai cũng đối xử với skill như một thứ chỉ có lớn thêm. Không ai lên lịch một ngày để làm nó nhỏ lại. Austin thú thật đây là bước anh quên suốt.

Bài đăng về skill có tương tác cao nhất của Matt thậm chí không nói về chuyện viết, mà nói về chuyện xoá. Trên màn hình là bài đó: hãy nhìn skill yêu thích của bạn. Nào, nhìn đi. Kiểm tra những dòng như "Make the commit message very detailed", "Be thorough", "Make the implementation easy to read". Những dòng này có gì chung? Chúng là no-op: chúng chẳng làm thay đổi gì trong hành vi của agent. Agent lúc nào cũng viết commit message tốt, lúc nào cũng cố gắng kỹ lưỡng, lúc nào cũng cố tạo ra code dễ đọc. Thử xoá chúng đi. Output có đổi không? Không? Vậy dòng đó là một no-op. Skill do agent viết ra thì đầy rẫy no-op.

Nói đơn giản: hãy đi qua skill của bạn từng câu một và tự hỏi: Claude có làm việc đó đằng nào cũng làm không? Nếu câu trả lời là có, dòng đó chỉ là trang trí. Matt gọi chúng là no-op, và chúng đang tốn token của bạn để nói đúng con số không.

14. Precise hay aggressive, và hai luật khi dọn skill

Lựa chọn của bạn ở đây là làm theo kiểu chính xác (precise) hoặc mạnh tay (aggressive).

• Precise: đi từng dòng. Xoá dòng bạn nghi là no-op, chạy lại. Nếu output không đổi, dòng đó chưa bao giờ làm gì cả.
• Aggressive (cách Austin thích hơn): cứ để Claude quét toàn bộ skill tìm ngôn ngữ no-op và xoá những chữ đó đi. Rồi xem chuyện gì xảy ra.

Dù chọn cách nào, có vài luật khi dọn skill:

1. Xoá cả câu, đừng chỉ tỉa bớt vài chữ trong câu.
2. Nói điều bạn muốn, không nói điều bạn không muốn. Những câu kiểu "đừng làm cái này" kéo chính thứ bị cấm quay lại context. Matt có một câu về chuyện này: nếu bạn nói "đừng nghĩ tới con voi", thì bỗng nhiên con voi là tất cả những gì còn lại. Chỉ bằng việc nói ra chữ "con voi", bạn đã đặt nó vào đầu model rồi.

15. Ghép từ skill có sẵn trước khi tạo skill mới, và tóm tắt năm bước

Vậy Matt tự áp điều này thế nào? Anh liên tục rút ngắn và xoá skill, và cũng cẩn thận y như vậy khi tạo skill mới. Luật của anh là: nếu bạn có thể ghép (compose) hành vi đó từ các skill đang có, thì đừng tạo skill mới.

Bạn áp tư duy này theo hai bước: một, kiểm toàn bộ skill của mình tìm dòng no-op rồi xoá nguyên câu; hai, kiểm xem các skill có chồng lấn nhau không, rồi gộp chúng lại hoặc cắt hẳn. Trên màn hình là một prompt giúp làm cả hai việc, tiêu đề "Audit for no-op lines":

Audit my skills for no-op lines.

For every sentence, ask: would Claude have done that
anyway? If yes, delete the whole sentence. Rewrite any "don't" line as what I want instead.

Then check which of my skills overlap. Show me which
to condense into one or cut entirely.

End with a list of every sentence you deleted.

Rồi Austin tóm lại cả năm bước:

Một, để ý thứ bạn cứ phải gửi trả để xác định chỗ cần skill. Hai, dùng leading word mà model đã biết để đơn giản hoá skill. Ba, giữ skill nhỏ và làm chúng khó tự gọi hơn để tránh phình to. Bốn, lặp bằng send back test đơn giản. Và năm, cắt no-op trước khi thêm bất cứ thứ gì mới.

16. AI ăn mất phần làm, nhưng không lấy được trách nhiệm

Có một điều Matt nói đã đóng khung lại toàn bộ video này cho Austin. Matt nói: AI đã ăn mất phần lập trình chiến thuật (tactical programming), nó không còn nữa. Có một kiểu khủng hoảng trách nhiệm khi làm việc với AI: người ta bắn mấy thứ này đi, chúng được merge vào main, rồi không ai chịu trách nhiệm cả. Kiểu: "AI làm đấy. Không phải tôi. Đó không phải code của tôi."

Theo Austin, điều Matt đang nói là AI đã ăn mất phần làm (the doing), nhưng nó không thể lấy đi quyền sở hữu (ownership). Thực tế là mọi thứ quy về con người, và bạn phải làm chủ quy trình của mình, và skill là cách để làm điều đó. Kết quả là bạn chẳng được gì từ việc sao chép mù quáng setup của người khác, vì bạn không hiểu sâu nó vận hành ra sao.

Matt đồng ý với điều này. Anh nói vậy khi trả lời một người chê skill của anh là tệ: phản hồi tiêu cực là một món quà, anh muốn biết cụ thể chỗ nào sai để làm skill tốt hơn; và anh cũng đồng ý rằng phần lớn mọi người nên tự viết skill và làm chủ quy trình của mình.

Nên đừng sao chép mù quáng. Thay vào đó, hãy tự tạo skill của mình bằng framework năm bước trong video. Khi làm vậy, có thể bạn gặp vấn đề: "Tôi gửi trả rất nhiều thứ, bắt đầu từ đâu?". Để giải quyết, Austin giới thiệu video anh phân tích chính xác cách đội ngũ của Anthropic dùng skill, video đó sẽ gợi ý cho bạn nên bắt đầu từ đâu. Anh hẹn gặp người xem ở video đó.