Theo thử skill của Matt Pocock và pstack

1. Repo mà Theo để mắt từ lâu

Theo mở đầu bằng một repo GitHub mà anh để mắt tới đã rất lâu nhưng chưa bao giờ dành thời gian đào sâu. Repo này do một người mà anh đã tương tác nhiều lần trong quá khứ tạo ra, và nếu bạn theo dõi mảng này đủ lâu thì chắc chắn đã biết. Theo hay tự gọi mình là "YouTuber TypeScript giỏi thứ hai", và lý do chính là người này, người số một: Matt Pocock.

Matt đã đăng một bộ AI skills "dành cho engineer thực thụ" (skills for real engineers). Theo thừa nhận ban đầu anh gần như gạt nó đi. Nhưng theo thời gian Matt tiếp tục tinh chỉnh chúng và giữ cho chúng thực tế. Cái anh ấy tạo ra là một tập các file markdown nhỏ và đơn giản. Theo nói trong video, đăng ngày 19/08/2026, rằng bộ này đã "racked up" hơn 200.000 star trên GitHub, và theo anh thì điều đó đưa nó vào nhóm 10 dự án được star nhiều nhất trên toàn GitHub, một con số anh gọi là "truly insane", và tất cả chỉ vì các file markdown. Số liệu này là của thời điểm Theo quay video. Đo trên GitHub vào ngày 17/10/2026, repo mattpocock/skills có khoảng 295 nghìn star.

Theo muốn biết cơn sốt này là gì từ khá lâu rồi. Anh đã nghe nhiều người nói rất tốt về các skill này, đặc biệt là skill "grill me". Đây cũng là một video anh lên kế hoạch từ lâu, đến mức cả Twitch chat của anh phát điên lên vì chờ. Anh đùa rằng mình thức đến 3 giờ sáng để làm nó, và rằng video này "quá hạn từ lâu" (long overdue), cuối cùng cũng làm sau ba buổi stream. Anh kể thêm: từ lúc video này được đưa vào Notion của anh, Matt đã cập nhật các skill nhiều lần.

Để nói được ý kiến thật lòng về các skill này, Theo biết mình phải dùng chúng. Nên anh đã dùng. Trong tuần trước đó, anh cài một loạt skill từ repo skills của Matt Pocock, một repo mà anh gọi là đầy "gems" đáng bàn, từ quy trình của Matt cho tới từng skill cụ thể.

Nhưng nếu chỉ nói về skill của Matt thì, theo Theo, anh sẽ làm một điều bất công cho cả hệ sinh thái. Phần lớn các repo skill ngoài kia là "absolute slop" và nên bỏ qua. Có một repo khác khiến anh hào hứng: pstack, do Lauren, người mà ai cũng biết với biệt danh poteto, tạo ra. Theo gọi chị là một trong những thành viên React core team mà anh yêu thích nhất từ trước, nay làm việc ở Cursor và đã xây một bộ skill vừa vui vừa mạnh một cách đáng ngạc nhiên.

Theo nói anh đã đi qua và audit phần lớn skill trong cả hai bộ, kéo những skill yêu thích về và đang dùng chúng thường xuyên. Anh nói rằng anh không thể chờ để chia sẻ mọi thứ mình học được.

2. Đừng copy mù: cách Theo dựng bảng xếp hạng skill cho riêng mình

Trước khi đi sâu vào các skill, Theo muốn nói vài điều. Điều đầu tiên, và anh nhấn mạnh rất rõ: bạn không nhận được gì từ việc copy mù setup của người khác. Hãy coi các bộ skill này không phải là một chuỗi bước phải làm theo, mà là thông tin để cân nhắc khi bạn tự xây hệ thống làm việc với AI của riêng mình.

Anh so sánh với code: nếu bạn copy paste codebase của anh rồi sửa vài chỗ thì bạn không phải một engineer giỏi. Nhưng nếu bạn dùng codebase của anh làm điểm tham chiếu để học và để rèn kỹ năng khi tự xây codebase của mình thì bạn là engineer giỏi. Với skill thì sự khác biệt cũng y như vậy. Nếu bạn sao chép mù setup chính xác của anh thì nó giống như trả một đống tiền cho một code template. Anh gọi việc đó là "cringe and bad" và nói rằng nó có nghĩa là bạn dở về engineering, thế thôi. Vì vậy đừng cài mù tất cả skill ở đây. Ít nhất hãy bắt đầu từ một điểm vào tốt hơn một chút.

Anh đọc chat: người xem vừa nhận ra Potato là một trong những người đã xây React compiler, và là một trong những contributor lớn nhất ở đó. Theo nói chị tài năng không thể tin nổi. Theo dự đoán pstack sẽ là viên ngọc bị đánh giá thấp trong video này và anh nghĩ người xem sẽ thích nó nhiều.

Rồi anh kể cách mình bắt đầu. Anh bắt đầu từ một prompt. Anh muốn biết skill nào của Lauren trong pstack khớp với công việc của mình, nên nhờ agent audit cách anh dùng AI trên các máy chính. Ghi trên màn hình, thread này nằm trong một repo tên fleet, dùng model Claude Opus 5. Theo giải thích anh lúc đó có cả đống lượt dùng Opus 5 cần tiêu cho hết, nên đó là lý do anh thử cách này.

I want to figure out which poteto "pstack" skills would map well to the work I do.

I want you to audit my usage across my main machines (this macbook, leftbook and bb-1). Compare my usage against the skills in pstack. Make a nice list ranking all of them by how well they fit me and how much they could benefit me.

Pull history here first, then break up subagents to do auditing. Opus 5 for all of them.

Pstack skills link: (đường dẫn tới thư mục pstack/skills trong repo plugins của Cursor)

Anh nói thêm là anh có dán link pstack vào prompt. Agent chạy 5 subagent, chờ bốn kết quả audit rồi quay lại với danh sách đã xếp hạng. Kết quả là một tài liệu kéo toàn bộ các skill vào, xếp hạng mức độ khớp và mức độ có lợi cho công việc của Theo, kèm một lời giải thích ngắn vì sao.

Theo nhắc ngay các skill nổi lên đầu bảng: interrogate, blast radius, technical writing, arena, skill "prove it works" và vài cái khác. Các câu giải thích khá cụ thể. Ví dụ interrogate đứng đầu vì đó là thứ anh vẫn tự làm bằng tay nhiều hơn mọi thứ: một reviewer đối kháng cho mỗi model và gộp kết quả. Blast-radius nhắm thẳng vào kiểu hỏng tệ nhất của anh: nó từ chối trả lại một bản write-up, nêu ra sự thật duy nhất khiến thay đổi này an toàn, rồi chấm bằng chứng trên một thang năm bậc, từ "you said so" (vô giá trị) đến "you ran it". Arena thì anh từng tự làm tay ba lần: ba pull request cùng làm gần như một tính năng và anh nhờ reviewer so sánh. Bảng cũng ghi arena tốn 5 subagent nên chỉ dùng cho việc thật sự đáng fork.

Theo nói cuộc đào sâu này bắt nguồn từ một thứ cụ thể: sự quan tâm của anh tới skill unslop.

3. Description thực chất là trigger, và vì sao Theo bắt đầu từ unslop

Các đoạn dịch nội dung skill trong phần này theo SKILL.md của unslop trong repo cursor/plugins/pstack, của Lauren Tan, giấy phép MIT.

Theo kể anh từng thấy Lauren đăng một số đoạn văn do agent của chị viết, và anh nghĩ ngay là nó "ít cringe hơn hẳn" so với kiểu Claude thường viết cho anh. Nên anh lấy skill unslop về ngay. Anh nói skill này rất, rất đơn giản.

Anh chỉ ra một chi tiết prompting thú vị trong phần description mà Lauren dùng. Như anh đã nói trong video "markdown overhaul" trước đó, điểm duy nhất của description là kích hoạt skill vào đúng lúc nó nên được kích hoạt. Hãy coi description là thứ khiến model làm việc đó, chứ không phải một bản mô tả chính xác mọi điều model có thể làm với skill. Anh ví nó với thumbnail của video YouTube: nhiệm vụ của thumbnail là khiến đúng người dừng việc lướt, bấm vào và xem. Mục tiêu của description cũng tương tự: khiến đúng agent, cho đúng nhiệm vụ, quyết định "à, skill đó hữu ích, mình nên kéo nó vào".

Theo nói nó không nên được gọi là description. Nó nên được gọi là trigger. Anh bổ sung rằng các chuẩn này được viết từ thời "Anthropic cũ", khi chưa ai biết mình đang làm gì, và giờ mọi người đã mắc kẹt với nó. Anh nói "it is what it is".

Rồi anh xem nội dung thực sự của skill. Anh nhắc lại cách skill hoạt động nếu bạn chưa quen: mỗi skill có một name và một description. Model có quyền truy cập tới tất cả skill của bạn nhưng chỉ nhìn thấy name và description, rồi dựa trên description mà quyết định "skill này có thể hữu ích ngay lúc này". Khi quyết định kéo nó vào, model đọc file markdown đó vào context.

Khi kéo skill unslop vào, đây là thứ model đọc. Mô tả ngắn: chỉnh văn bản để bỏ các pattern của AI và thêm giọng người. Quy trình đơn giản: quét tìm các pattern, viết lại, giữ nguyên nghĩa, khớp giọng điệu mong muốn, thêm một chút "hồn", rồi tự kiểm. Câu tự hỏi là "điều gì khiến văn bản này lộ ra là do AI viết?", sau đó sửa những dấu hiệu còn sót lại.

4. Bên trong skill unslop: quy trình, "thêm hồn" và danh sách pattern

Các đoạn dịch nội dung skill trong phần này theo SKILL.md của unslop trong repo cursor/plugins/pstack, của Lauren Tan, giấy phép MIT.

Theo đọc to phần "Adding soul". Gỡ bỏ các pattern mới chỉ là một nửa công việc. Văn khô cứng, vô hồn cũng lộ rõ y như vậy. Các gợi ý trong skill: có chính kiến, hãy phản ứng với sự kiện thay vì liệt kê trung tính ưu và nhược; thay đổi nhịp câu, câu ngắn rồi đến câu dài hơn, trộn lẫn; thừa nhận sự phức tạp, ví dụ "ấn tượng, nhưng cũng hơi đáng lo" (impressive, but also kind of unsettling) tốt hơn chỉ nói "ấn tượng"; dùng "I" khi hợp lý, vì ngôi thứ nhất không phải là thiếu chuyên nghiệp; để lại một chút lộn xộn, vì cấu trúc hoàn hảo trông như máy làm; và cụ thể. Thay vì "điều này đáng lo", hãy nói "có điều gì đó đáng lo khi thấy các agent cặm cụi chạy lúc 3 giờ sáng". Theo đùa rằng skill gọi thẳng anh ra với ví dụ này.

Anh bình luận về cách skill được viết: đây là một trong những việc LLM làm rất giỏi. Nếu bạn đưa ví dụ xấu rồi chỉ ra ví dụ tốt thì chúng sẽ theo cái tốt rất tốt. Nhưng nếu trong các ví dụ đó thiếu một số thứ thì chúng sẽ tiếp tục làm sai. Vì vậy bạn phải tìm sự cân bằng.

Rồi tới danh sách pattern cần phát hiện và sửa. Nhóm đầu là nội dung, bắt đầu bằng "puffery": những cụm như "pivotal moment", "testament to", "evolving landscape", "setting the stage for". Skill bảo hãy cắt puffery và nói điều gì đã xảy ra. Tiếp theo là name-dropping, tức liệt kê các hãng truyền thông mà không có ngữ cảnh: chọn một nguồn và nói họ đã nói gì. Rồi các cụm đuôi -ing hời hợt như "highlighting", "ensuring", "reflecting", "showcasing", "fostering": xóa chúng. Ngôn ngữ quảng bá, và các cách nói mơ hồ về nguồn cũng nằm trong danh sách. Theo nói "bạn hiểu ý rồi đấy".

Skill cũng nêu việc lạm dụng em dash. Theo nói bằng giọng bực bội rằng anh vẫn thấy rất nhiều em dash từ Opus; các model khác tuân thủ điều này tốt hơn nhiều. Người xem trong chat nhận xét rằng mật độ ngữ nghĩa của skill rất tốt, và Theo đồng ý: đây không phải slop, nó rất dễ đọc và thông tin được truyền đạt hiệu quả, nó chỉ đơn giản là được viết tốt. Anh thêm rằng khi trong lịch sử của bạn có văn tốt thì model càng dễ làm theo, và nếu bạn bảo model làm theo thì chúng càng dễ làm theo hơn.

Còn có một mục để bỏ các cụm của chatbot, như "I hope this helps" hay "Let me know if...", "found the smoking gun" và những thứ tương tự. Theo đùa là, đáng tiếc, không có mục nào nhắc đến "load bearing". Rồi một mục dài về jargon, mà anh nói là phần anh thích nhất: nói điều nó làm, đừng nói cảm giác của nó. Thay vì "the database stays close at hand" hãy nói thẳng hơn nhiều: ".toSQL() trả về đúng chuỗi được gửi tới database". Anh nói câu thứ hai tốt hơn hẳn. Skill còn đề nghị tự hỏi câu văn bảo người đọc làm gì hoặc biết gì, rồi viết đúng điều đó. Nếu không thể diễn đạt lại thành một chỉ dẫn, một sự kiện hoặc một con số ngắn gọn thì cắt đi. Một lần kiểm cuối: nếu câu đó có thể xuất hiện nguyên văn trong tài liệu của dự án khác thì nó chẳng nói gì về dự án này, cắt đi.

5. Thử unslop: cùng một model, cùng một câu hỏi, hai kiểu văn

Theo muốn xem skill này chạy ra sao. Anh bắt đầu với GPT ở mức "high fast", rồi đổi ý: cho nó việc khó hơn. Anh định dùng Opus 5 nhưng sợ chạy lâu, nên chọn Sol cho bài này vì nhanh hơn. Anh hỏi: dự án này là gì, giúp tôi hiểu nó và vì sao ai đó muốn dùng nó. Anh cũng có thể lấy bất kỳ thread Codex cũ nào của mình để cho thấy sự khác biệt.

Anh mở một thread cũ, nơi anh nhờ cập nhật một app SwiftUI. Câu trả lời đã dùng unslop: "Build 26 đã được upload lên App Store Connect và đang xử lý. Cũng đã hoàn tất", rồi danh sách gạch đầu dòng chính xác các việc đã làm. Phần phân phối công khai chưa thể kiểm chứng vì phiên trình duyệt App Store Connect đã hết hạn. Đăng nhập tại link, rồi anh có thể gán build 26 vào nhóm public beta nếu cơ chế tự động phân phối không xử lý. Theo nói câu trả lời này rất dễ đọc, tốt hơn nhiều.

Anh chỉ ra rằng khi gửi prompt mới, một trong những điều đầu tiên xảy ra là model nói rằng nó đang áp dụng skill unslop bắt buộc để câu trả lời ngắn gọn và dễ quét. Rồi nó viết ra một đoạn đơn giản, dễ đọc: T3 Code là trung tâm điều khiển mã nguồn mở cho các coding agent. Thay vì dùng Codex, Claude Code, Cursor, Grok hoặc OpenCode qua các công cụ terminal riêng, bạn điều khiển chúng trong một ứng dụng desktop, web hoặc mobile duy nhất.

Để so sánh theo cách dễ nhất anh nghĩ ra được, anh hỏi trực tiếp trong ChatGPT, nơi không có skill của anh, với cùng một prompt gần như y hệt, chỉ nói rõ hơn về nó là gì cho dễ trả lời. Câu trả lời mở đầu bằng "The core idea is already clear. T3 Code is not another coding model and not mainly an editor." Theo reo lên rằng anh không nhận ra mình đã quen với văn đã unslop nhanh đến thế, và giờ đọc văn slop khiến anh đau. Anh nói thật sự điên rồ khi thấy sự khác biệt lớn như vậy ngay lập tức.

Theo đọc to phần văn slop: một workflow bình thường là chạy lệnh, mở project, bắt đầu thread, nhờ nó kiểm tra hoặc đổi project, xem lại message và thay đổi code, rồi tiếp tục từ desktop, trình duyệt hoặc điện thoại. T3 Code cũng quản lý terminal, phiên agent, git diff và checkpoint; mỗi lượt có một checkpoint để bạn kiểm tra hoặc hoàn tác thay đổi của agent. Rồi "Short version: T3 Code is a cross-provider control center", cùng một trích dẫn từ tài liệu nói nó biến các provider từ các chương trình terminal riêng lẻ thành một agent workspace thống nhất, với client desktop, web, iOS và Android. Tiếp theo là bảng "T3 Code is / T3 Code is not", rồi "The strongest pitch is not chat with AI in nicer windows. It is operating several autonomous developers without living in several terminal tabs", "Remote agents become practical", "One interface across providers", "It's designed for parallel work", và "The especially compelling use case for your setup".

Đối lập là bản có skill, ở mục "Why someone would use it": một giao diện làm việc với nhiều provider; thread được lưu lại nên dễ tiếp tục; bạn có thể điều khiển agent trên một máy khác từ điện thoại hoặc trình duyệt; file và thông tin đăng nhập provider vẫn nằm trên máy đang chạy server. Theo nói thật điên rồ khi cả hai kết quả đến từ cùng một model, chỉ vì thêm một file markdown. Văn bản dễ đọc hơn rất nhiều. Anh nói anh thích code hơn hẳn kể từ khi có chỉ một skill ngớ ngẩn này, và cảm ơn Lauren cùng pstack vì skill unslop tuyệt vời.

6. Sang skill của Matt: thử mà không cần cài

Theo nói hy vọng giờ người xem đã hiểu vì sao anh lao vào cái hố thỏ này nhanh như vậy: anh bị skill đó gây ấn tượng ngay khi cài. Sau đó anh đi qua toàn bộ skill của pstack để xem cái nào khác cũng hợp với mình. Trong lúc làm vậy, anh nhận ra, và chắc người xem cũng đoán được, rằng anh cũng nên xem skill của Matt Pocock. Nên anh gắn link repo đó vào và nhận được một tài liệu khác liệt kê tất cả skill của Matt và cái nào hợp với trường hợp của anh. Giờ là lúc đi sâu vào các skill và giá trị chúng mang lại.

Anh nói mình đã tập trung vào pstack hơi lâu, nên giờ chuyển sang skill của Matt. Thư mục đáng quan tâm là skills/skills/engineering. Trong đó có: ask-matt, code-review, codebase-design, diagnosing-bugs, domain-modeling, grill-with-docs (một bản cập nhật của skill grill-me cũ), implement, improve-codebase-architecture, prototype, research, resolving-merge-conflicts, setup-matt-pocock-skills (một skill dùng để cài chính bộ skill), tdd, to-spec, to-tickets, triage, wayfinder và wizard.

Theo muốn bắt đầu bằng cách chơi thử vài skill. Anh chọn improve-codebase-architecture và grill-with-docs. Và anh chia sẻ một mẹo: nếu tò mò về một skill và cách nó hoạt động, cách dễ nhất không phải cài rồi hy vọng điều tốt nhất. Thực ra rất đơn giản: thường bạn có thể copy paste nó.

Trong trường hợp này, skill gọi tới các skill khác. Anh thấy buồn cười vì grill-with-docs đơn giản đến thế: đó là một cuộc phỏng vấn không khoan nhượng để làm sắc nét một kế hoạch hoặc thiết kế, đồng thời tạo tài liệu, ADR và glossary trong lúc làm.

Anh cũng chú ý Matt đặt disable-model-invocation bật cho nhiều skill của mình, nghĩa là model sẽ không tự kích hoạt chúng; bạn phải tự kéo vào bằng lệnh slash hoặc lệnh dấu đô la hoặc tương tự. Theo thấy đó là quyết định rất hợp lý vì cách một số skill của Matt hoạt động. Nhưng có skill thì không nên như vậy. Ví dụ khi anh xem skill diagnosing-bugs, anh không muốn phải tự kéo tay. Và chắc chắn Matt không để nó ở dạng phải kéo tay: đây là skill sẽ tự kích hoạt khi nó đang giúp debug.

7. Skill grilling và lần grill đầu tiên với Opus 5

Theo nói anh đã thấy skill này tự bắn ra và giúp debug nhiều lần trong vài ngày qua, và nó khá vững. Có vẻ agent của anh tìm ra root cause và giải thích điều gì sai hiệu quả hơn nhiều.

Anh chuyển sang các skill grill me mới và grilling, vì chúng được tham chiếu ở trên. Đây là skill grilling: hãy grill người dùng không khoan nhượng về một quyết định hoặc ý tưởng đã định; dùng khi người dùng muốn stress test suy nghĩ của mình hoặc dùng bất kỳ cụm kích hoạt "grill" nào. Phỏng vấn người dùng không khoan nhượng cho đến khi đạt hiểu biết chung. Vẽ nó ra thành một design tree: mỗi quyết định rẽ nhánh thành các quyết định treo bên dưới. Làm việc với cây theo từng vòng. "Frontier" là mọi quyết định mà các điều kiện tiên quyết đã được chốt, tức là những câu hỏi bạn có thể hỏi ngay mà không phải đoán những câu trả lời chưa nghe.

Theo nhìn thấy em dash trong skill và phát bực: "Trời ơi, sao Matt lại dùng em dash trong skill của mình? Matt. Matt." Anh đếm, trang này có chín em dash, ít nhất một cái ở hầu hết các đoạn. Anh nói giờ anh hiểu vì sao mình lại thấy em dash quay lại: có thể chính là do skill của Matt. Nhưng anh vẫn sẽ thử.

Anh nhắc người xem về mẹo đã nói: copy văn bản, đến agent của bạn, làm điều bạn muốn, rồi dán vào. Anh yêu cầu agent grill anh về dự án Lakebed của mình. Prompt anh gõ, kèm văn bản của skill được dán ngay bên dưới:

I want you to grill me about Lakebed. The project itself and its goals, everything in the agents.md/claude.md, etc.

I want to make sure we are on the same page about what we are building.

I want to use Matt Pocock's grill skill. Don't have it installed, I will paste the text below.

Phần dán bên dưới bắt đầu bằng đoạn mở đầu của skill (theo SKILL.md của grilling trong repo mattpocock/skills, giấy phép MIT): "Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it."

Anh nói giờ anh đã dùng thành công skill này mà không cài gì, chỉ bằng cách copy paste văn bản. Rõ ràng cách này sẽ không chạy với skill có thêm thứ khác như script, nhưng bạn có thể copy script sang, không sao, hoặc chỉ cần nói với model về nó, nó có thể tự tìm script và tải về. Đây là cách dễ nhất để thử một skill chỉ có văn bản: copy paste đúng chữ.

Lần chạy này là Opus 5 trên máy Linux từ xa của anh. Nó mất gần hai phút để có lượt đầu. Nó nhận xét: CLAUDE.md đã cũ nghiêm trọng, repo có luật v0 riêng của nó, và trong cây có hai mô hình thực thi cạnh tranh nhau. Rồi các câu hỏi: Câu 1, ai là người dùng và ai trả tiền, kèm các ví dụ đáp án có thể đưa ra. Câu 2, cột mốc tiếp theo thật sự là gì, vì có một mớ file chuẩn bị launch, các file HTML với kế hoạch ngẫu nhiên, và file to-do là thứ được sắp xếp từ một chương trình dọn PR chứ không phải từ launch. Câu 3, định dạng capsule là một spec hay chỉ là cách triển khai của chúng tôi? Mức trần của một capsule là gì? Theo nói đó thật sự là những câu hỏi hay.

8. Grill lại bằng Sol: trả lời nhanh theo kiểu 1A, 2B, 3A

Theo tò mò: nếu hỏi model khác thì có ra câu hỏi tốt tương tự không? Anh chuyển sang Sol với đúng cùng yêu cầu. Anh nhận ra mình đã cài sẵn skill grilling ở đó, vì anh đã mang nó sang. Anh nhận xét rằng Sol làm đúng điều skill đòi: nó phải tìm các sự kiện trong repo thay vì hỏi anh.

Anh vừa nhận ra mình đang chạy ở mức "low and slow", đáng lẽ nên dùng "high and fast" để có câu trả lời tốt hơn, nhanh hơn. Anh định dừng nhưng rồi nói anh không quan tâm nữa. Hóa ra nó xong trước cả khi lệnh dừng kịp có hiệu lực, và anh thấy buồn cười. Các câu hỏi lượt này: Lakebed là gì? Khách hàng chính là ai? "Full autonomy" nghĩa là gì? Và capsule là gì? Theo nói tất cả đều là câu hỏi hay.

Anh thử bản high. Ở mức high, nó tự bật các sub-agent chạy nền để đi tìm thêm dữ liệu cho các câu hỏi sau. Nó bắt đầu với "Lakebed là gì? Ai là người dùng chính?" và đều kèm đáp án nhanh, nên rất dễ lướt qua, kiểu 1A, 2B, 3A và cứ thế. Anh nhận xét rằng công cụ đặt câu hỏi trong nhiều harness và agent hiện giờ chưa đủ tốt để hiển thị giao diện hỏi riêng, nên cách trả lời gọn này nhanh hơn nhiều để lướt qua.

Theo trả lời từng câu. Câu 1: anh nói đó là nền tảng ứng dụng tự động. Câu 2: hai nhóm này là những người dùng quan trọng. Câu 3: nó không đưa một đáp án đơn giản, nhưng anh chỉ cần nói thứ anh không muốn, tức là các agent nên làm mọi thứ ngoại trừ chi tiết thanh toán. Câu 4: Lakebed nên sở hữu bao nhiêu? Sở hữu mọi thứ khi cần. Câu 5: quy tắc nào thắng? Hướng dẫn hiện tại chứa các nguyên tắc sẽ xung đột. Anh muốn đơn giản khi có thể, nhưng cũng viết lại khi có lợi. Câu 6: ranh giới sản phẩm là gì? Lakebed nên vẫn là một hệ thống mở, thật sự hữu ích, trong khi nền tảng cloud được host là đường đi cho production, còn môi trường local chỉ là dev sim. Theo nói thế là gọn và dễ.

Và anh nói mình đã nhận ra cần dọn lại dự án này, chỉ từ phần khởi động đơn giản và nhanh của lượt grill. Rồi anh thốt lên: "Okay, I'm seeing the light. This is useful. I should have tried this before." Anh tiếp tục đi qua các skill khác.

9. Teach, ask-matt, triage, wizard và phần còn lại của thư mục engineering

Skill tiếp theo là teach, một skill anh đã nghe nhiều người khen. Cũng như nhiều skill khác của Matt, nó tắt model invocation, nên bạn phải kích hoạt bằng /teach. Nội dung: người dùng nhờ bạn dạy họ một điều gì đó. Đây là một yêu cầu có trạng thái (stateful): họ muốn học chủ đề qua nhiều phiên. Hãy coi thư mục hiện tại là một teaching workspace. Trạng thái việc học của họ được lưu trong thư mục đó qua một số file. Theo thấy rất thú vị, vì như vậy skill teach được dùng trong một thư mục riêng của nó. Anh nói: "Huh." Rồi anh nhận ra mình chưa đọc đúng cách và muốn đọc thêm ở cấp cao nhất.

Ở cấp cao nhất, anh thấy skill ask-matt, dùng riêng để giúp bạn tìm ra skill hoặc flow nào hợp tình huống của mình. Có grill-with-docs như đã nói. Có triage, giúp đẩy issue qua một state machine gồm các vai trò triage. Rồi improve-codebase-architecture, cái anh thực sự muốn thử. Nhiều skill trong bộ này tự tham chiếu lẫn nhau: ví dụ skill này bảo chạy skill codebase-design để lấy từ vựng, rồi trình bày các ứng viên dưới dạng một báo cáo HTML. Theo nói: "Nice. Nếu ai thích HTML skill thì tôi rất thích cái này." Nó dùng CONTEXT.md làm từ vựng của domain, rồi gọi grilling và domain modeling. Wayfinder cũng vui, dùng để lập kế hoạch các khối công việc rất lớn.

Anh cũng rất thích việc tài liệu tách bạch user-invoked và model-invoked, vì chúng rất khác nhau. Skill user-invoked thực chất giống plugin bạn gọi khi tự muốn dùng. Skill model-invoked thì thiên về lái model làm những việc theo cách khác. Loại sau rất hữu ích, như anh đã nói, diagnosing-bugs đã giúp anh rất nhiều.

Wizard cũng có vẻ rất hay: dẫn con người đi qua những bước chỉ con người làm được. Anh nói điều này tuyệt khi một agent không thể vào một dashboard nó cần, hoặc có lệnh sudo nó không chạy được. Wizard là một hướng dẫn giúp agent chuẩn bị mọi thứ để bạn chỉ phải chạy một script rồi từ đó mọi việc còn lại được xử lý.

Theo hỏi chính mình: anh đã có cái này chưa, vì nếu chưa thì anh sẽ đi cài ngay. Và anh nói sẽ "spoil" cách anh thật sự dựng tất cả những thứ này. Anh làm toàn bộ trong một thread của T3 Code, trong một repo tên fleet anh đã tạo, nơi anh quản lý mọi file skill của mình. Trong đó anh hỏi như sau, kèm một gợi ý rằng đã có thêm một máy mới là Mac mini để nó cũng cập nhật máy đó:

did we set up the wizard skill from matt's repo? if not, set it up now. know that we have one more machine in the fleet to deal with too, since last time I worked on this I added my new mac mini

Anh vừa nói vừa đọc lại tài liệu và nhận ra: "Lẽ ra tôi nên đọc tài liệu từ đầu, my bad."

10. Main flow trong tài liệu và cách Theo giữ bộ skill của mình

Trong tài liệu, phần Getting Started dùng lệnh setup skills, giúp thiết lập issue tracking và những thứ tương tự theo cách các skill sẽ xử lý được. Main flow bắt đầu với grill-with-docs: được phỏng vấn về một kế hoạch và ghi lại các quyết định. Sau đó đến spec: biến nó thành spec. Rồi tickets: cắt thành ticket cho Jira, Linear, GitHub issues hoặc bất cứ thứ gì bạn dùng. Rồi implement để thực sự xây, và code review để xem lại sau đó.

Phần Shaping: Shaping vui, dùng để biến ý tưởng mơ hồ thành kế hoạch có thể thực thi. Wayfinder giúp vạch một nỗ lực lớn thành bản đồ các quyết định và giải quyết chúng. Prototype dùng để thực sự làm thiết kế và mock mọi thứ để thấy mình muốn gì trước khi ship, tức là code xóa được. Còn skill research để có câu trả lời có trích dẫn từ nguồn gốc. Theo nói anh không biết mình có bao giờ cần nó không, vì anh thấy agent khá giỏi trong việc kiểm chứng các tuyên bố của chúng nếu bạn chỉ cần hỏi.

Trên trang AIHero, phần "Install the skills" cho thấy Lệnh cài chung là npx skills@latest add mattpocock/skills, cập nhật bằng npx skills update. Cho Claude Code có lệnh claude plugins install mattpocock-skills, cập nhật tự động. Dòng "Works with any agent" ghi Claude Code, Cursor, Codex, Copilot, 25 skills, giấy phép MIT, và bộ đếm star ghi 215.184 khi Theo quay hình.

Mục Upkeep có improve-codebase-architecture, diagnosing-bugs, resolving-merge-conflicts, triage và wizard. Theo nói anh rất hào hứng muốn thử wizard. Tiếp theo là nhóm productivity skills như grill me, handoff, to-questionnaire, teach, wait-what và writing-for-agents. Rồi các reference skill như codebase-design, từ vựng để thiết kế các module sâu (deep modules), và domain-modeling, mục ghi lại các từ mà dự án dùng. Anh nghĩ domain-modeling thực sự hữu ích: anh vẫn tự viết ngữ pháp và glossary riêng với agent trong mỗi dự án, về những thuật ngữ dùng để chỉ các việc khác nhau. Ý tưởng biến nó thành một skill nghe hợp lý với anh.

Anh nói mình ngày càng muốn cài hết chúng. Nhưng anh rất hài lòng với setup hiện tại và không muốn làm nó lộn xộn thêm. Nên anh tiếp tục làm điều thường làm: bảo agent "rip" những phần anh muốn và giữ chúng trong thư mục fleet của mình. Theo nói repo fleet nhỏ này đã cứu anh vô số lần. Trong lúc đó lệnh anh gửi đang chạy, và anh chờ phần tiếp theo.

11. Vòng grill thứ hai, wizard được cài lên mọi máy

Lệnh chạy xong và có thêm nhiều câu hỏi. "Dạng đơn giản nào quan trọng nhất?" Theo thấy câu này tàn nhẫn, vì anh muốn tất cả các dạng đơn giản. Anh nói câu hỏi này đi rất sâu và anh không muốn trả lời, "that's the point, isn't it?". Thực ra anh không cần trả lời vì đáp án là cả ba. Anh muốn tất cả. Cuối cùng anh nói sẽ miễn cưỡng chọn A dù muốn hết.

Các câu tiếp theo và câu trả lời của anh: Lakebed phải hỗ trợ những loại app nào? A và B, không phải C. Hai người dùng chính chia quyền kiểm soát thế nào? Nếu nhà phát triển và agent đều là người dùng chính, mỗi bên sở hữu cái gì, ai chọn kiến trúc, mô hình dữ liệu, thời điểm deploy và những thứ tương tự? Anh trả lời: nhà phát triển không chọn gì ngoài chức năng của app. Câu số 10: "mọi thứ" có bao gồm các hành động không thể đảo ngược không? Có nên cho phép agent xóa dữ liệu production? Anh nói có, chúng nên làm được bất cứ gì. Còn ranh giới thanh toán thì là gói thuê bao cộng hạn mức hàng tháng, và agent có thể dùng chúng thoải mái. Câu 12: simulation local phải giữ lại những gì? Theo nói thế là tuyệt.

Anh nhận xét rằng mình khá thường xuyên không đồng ý với các câu trả lời được đề xuất, và điều này thật sự sẽ giúp anh. Anh nói anh thấy bực. Giờ skill này đã nằm trên mọi máy của anh. Opus bắt được hết các thay đổi trong hệ thống của anh. Anh biết có vẻ ngớ ngẩn, nhưng toàn bộ văn bản này dễ đọc hơn nhiều so với những thứ agentic cũ anh từng làm trong cùng dự án, cùng codebase, cùng agent và cùng model. Anh hỏi một câu và nó trả lời trực tiếp. "No, Wizard was never set up. It ranked seventh in the previous report, but you only pick seven skills, and it wasn't among them." Và nó đã được cài.

Để đối chiếu, anh cuộn lại các thread từ trước khi có các skill này. Một thread cũ có bản "recent changes summary" kèm một bản write-up sẵn để chia sẻ. Anh đọc một dòng về việc xuất bản release nay dùng token GitHub gắn theo job thay vì tranh chấp hạn mức API của app release dùng chung, sửa các lỗi nightly lặp đi lặp lại, và thốt lên "Oh god, the m-hell" vì dày đặc em dash. Anh đọc to một thread cũ khác, nơi anh đã bảo agent đẩy thẳng lên nhánh của một người khác: "Done. The follow-up commit is now on his PR branch directly" kèm số commit và việc các review bot chạy lại trên head mới. PR của người đó còn chậm một merge so với nhánh chính, vì PR phân trang thread đã vào sau; nó vẫn mergeable theo GitHub nên không cần làm gì. Rebase nhánh của người đó ngay dưới chân họ có vẻ xâm phạm hơn mức tình huống cần. Đáng theo dõi xem kiểm tra quy ước effects service có xanh không, vì đó là blocker cứng, và cách tiếp cận context.reference của anh là cách chữa nhẹ hơn.

Theo nói anh thậm chí đọc không nổi, mà còn phải đọc to trong video cho người xem: "It's so much worse." Anh nói: "Life post slop is unbelievably cool." Anh còn hơn mười câu hỏi nữa từ skill để trả lời. Anh sẽ làm việc đó ngoài stream, nhưng vẫn sẽ làm vì đó là những câu hỏi hay.

12. Nhận xét: skill của Matt thiên về quy trình có sẵn, và ý tưởng skill manager

Việc này khiến Theo nhớ ra một nhánh anh đang làm trong T3 Code, giờ anh có ý tưởng mới. Anh đang làm một tính năng quản lý skill, một trang skill manager chạy qua nhiều máy, để dễ quản lý skill trên các máy của mình qua một lớp duy nhất. Điều anh muốn thêm bây giờ là khả năng tắt hàng loạt: có các nhóm skill, như nhóm skill pstack và nhóm skill của Matt Pocock, rồi bật hoặc tắt cả nhóm, hoặc chỉ bật những cái mình muốn. Anh nói: "Oh, that would be so nice." Rồi anh thấy skill wizard đã xuất hiện trên tất cả các máy của mình. Anh chưa có việc nào cần wizard lúc này nhưng rất hào hứng thử, vì nó rất hợp lý với anh.

Đây là phần đánh giá chung của Theo. Anh nói phần lớn các skill này giống như đang kê đơn các quy trình tư duy (mental workflows) và cho bạn một điểm vào dễ để thử, đặc biệt phần "main flow" với chuỗi grill-with-docs, spec, tickets, implement, code review. Anh không nhất thiết muốn có nhiều chỉ định như vậy về cách anh đi từng bước. Anh đã tự xây các workflow của mình và chúng không khớp lắm với kiểu truyền thống. Nhưng có rất nhiều thứ tốt anh kéo về từ đây, như skill wizard. Anh nói skill grilling rõ ràng cực kỳ hữu ích. Anh sẽ chơi thêm với codebase-design và vài skill khác trong cùng bộ. Anh cũng nghe nói wait-what rất hay, và writing-for-agents mà anh đã dùng khá nhiều.

Về writing-for-agents: nó được đổi từ tên "writing great skills" thành "writing for agents". Anh thấy nó hữu ích vì agent rất kém khi viết hướng dẫn cho agent khác. Nếu bạn để agent viết skill, viết markdown, viết prompt cho sub-agent giùm bạn, tất cả những thứ như vậy, nó có thể làm rất tệ. Nên đưa cho nó hướng dẫn tốt hơn về cách làm đúng nghe rất hấp dẫn với anh.

13. wait-what, writing-for-agents và chuyện văn bản do AI viết

Một skill khác anh rất hào hứng là wait-what, skill kéo theo Simplified Technical English. Theo nói sắp có một video riêng của anh về phần này trong tương lai gần. Đây là skill do người dùng tự gọi và chỉ dài ba dòng. Mục đích là có một mô tả đơn giản, dễ tiêu hóa hơn về một thứ khi bạn nhận phản hồi chẳng có nghĩa gì. Theo ghi nhận rằng Matt tự nói rõ điều này: nó chỉ sửa được một tin nhắn, không ngăn được tin nhắn cẩu thả kế tiếp. Cách chữa cho kiểu jargon này là một ngôn ngữ chung được xây từ đầu bằng skill grill-me-with-docs. Hãy dùng wait-what khi bạn chưa làm xong phần đó. Theo nói anh rất hào hứng với wizard và sẽ dùng nó rất nhiều, anh có thể nghĩ ra bốn việc đáng lẽ đã dùng hôm qua. Anh cũng thích cách Matt ghi tài liệu cho tất cả những thứ này: đó là một trang docs tốt và có rất nhiều điều để học theo nghĩa tốt nhất.

Anh mở skill: chỉ cần gõ một lệnh gọi skill, bằng dấu slash hay dấu đô la, vì nó cũng tắt model invocation. Anh đọc nội dung và nhận ra vẫn có em dash trong đó. Anh nói anh gần như muốn làm một bản fork "đã bỏ em dash" của skill Matt Pocock: đúng repo đó nhưng đã xóa hết em dash, và điều đó chỉ cần một regex. Anh còn nói anh gần như muốn đếm xem trong dự án này có bao nhiêu em dash. Trên màn hình, phần mô tả của wait-what nói "Stop. That last message did not land, re-pitch it", và thân skill bảo: giải thích lại, cho một chút ngữ cảnh, nói bằng ASD-STE100 Simplified Technical English và dùng ngôn ngữ chung trong CONTEXT.md.

Anh bảo mình thật sự hào hứng với writing-for-agents. Anh mở ra, thấy nó dài, và nói như vậy là tốt, vì nó phải dài. Đây là tài liệu tham khảo để viết bất kỳ văn bản nào mà một agent đọc: một skill, một agent hoặc CLAUDE.md, một tài liệu được tới qua một con trỏ. Anh chủ yếu dùng nó cho việc viết prompt cho sub-agent và thấy nó rất hữu ích ở đó. Anh vẫn thấy quá nhiều em dash. Khi văn bản bạn đang viết là một skill thì đọc file skill mechanics để biết front matter, cách chọn invocation và router skill. Phần "context pointers": một context pointer là một tham chiếu nằm trong context của agent, nêu tên một tài liệu nằm ngoài context và mã hóa điều kiện để tới nó. Description của skill là một con trỏ như vậy, một dòng trong AGENTS.md gọi tên một tài liệu cũng là cùng một loại đối tượng. Cách diễn đạt của con trỏ, chứ không phải đích của nó, quyết định khi nào agent tới tài liệu và mức tin cậy. Một đích bắt buộc phải có mà nằm sau một con trỏ viết yếu là một lỗi biến thiên (variance bug).

Theo nói: "Cái này đọc không nổi. Tôi không ngạc nhiên, nhưng trời ơi." Anh nói anh không còn tin mấy cái này nữa và tự hỏi liệu văn bản có bị đánh dấu là do AI viết không, hay đó là vấn đề của anh. Anh dán lần lượt ba đoạn vào công cụ phát hiện văn bản AI Pangram. Đoạn thứ nhất là phần "context pointers" của writing-for-agents (179 từ): công cụ chấm "AI Generated". Đoạn thứ hai là một đoạn của skill unslop (338 từ): cũng "AI Generated", vòng tròn 100%.

Đoạn thứ ba là văn bản hướng dẫn agent do chính Theo viết (243 từ). Theo lời Theo, kết quả là anh "qua được, 100% do người viết".

Theo nhận xét rằng rất có khả năng tất cả các skill này đều do AI viết, và điều đó làm anh khó chịu vì anh không gặp nhiều may mắn với văn bản do AI viết. Anh ngạc nhiên rằng skill unslop bị cho là do AI viết, vì skill đó đọc rất dễ, rất cô đọng và được viết tốt. Nhưng dù cả hai bộ đều do AI tạo, anh thấy văn phong của pstack dễ đọc hơn nhiều, và các hành vi của skill pstack áp dụng được nhiều hơn cho công việc hằng ngày của anh.

14. pstack: arena, bro, blast-radius và show-me-your-work

Các đoạn dịch nội dung skill trong phần này theo SKILL.md của blast-radius và show-me-your-work trong repo cursor/plugins/pstack, của Lauren Tan, giấy phép MIT.

Skill arena của pstack đã rất vui với anh. Nó chạy N lần thử song song cho cùng một việc, đọc từng ứng viên từ đầu đến cuối, chọn cái mạnh nhất làm nền, ghép những ý tưởng tốt nhất từ các cái còn lại vào, rồi kiểm chứng kết quả tổng hợp. Theo nói đây là một skill rất vui cho những người "đốt token" như anh, những người có cả đống lượt dùng cần tiêu cho hết. Skill bắt đầu bằng việc mở một danh sách việc với mỗi giai đoạn một mục trước khi chạy bất cứ thứ gì, vì arena chạy tự động và danh sách đó giữ cho các giai đoạn không âm thầm biến mất.

Theo ghi nhận: giai đoạn Frame, Fan out, Cross-judge, Pick, Graft, Verify, mỗi giai đoạn có một mô tả. Anh thấy ngạc nhiên về việc văn bản ít đến mức nào so với mức skill này làm. Anh nói một skill này đã tiêu của anh hàng trăm đô la chi phí inference vì nó làm cùng một việc nhiều lần. Điểm yếu lớn nhất của pstack, theo anh, là phần mô tả của nó gắn rất chặt với Cursor. Anh sẽ rất vui nếu ai đó clone toàn bộ skill pstack theo cách chung chung, không riêng Cursor, vì có rất nhiều thứ quý ở đó, nhưng một số skill thì hơi quá thiên về Cursor.

Lauren cũng kéo skill bro từ một skill gốc của Dillon Mulroy, theo trí nhớ của Theo, người nổi tiếng về Effect và lập trình hàm trong JavaScript. Nội dung: diễn đạt lại tin nhắn cuối của bạn, đừng dùng jargon và nói cho mạch lạc, nói đơn giản và ngắn gọn hơn, như một người nói với một người. Theo thấy nó gần như giống hệt wait-what. "Yep. Pretty much identical." Skill này cũng là một trong số rất ít skill của Lauren bật tắt model invocation, điều anh thấy thú vị, vì chị thường để model tự làm.

Blast-radius cũng tuyệt, anh dùng rất nhiều. Nó tìm xem một thay đổi sẽ làm hỏng gì ở chỗ khác trước khi ship. Dùng "blast radius of X" hoặc "what could this break?", hoặc khi xem một diff nhỏ mà bạn không tin. Anh so sánh với cặp skill đi kèm là how và why: how cho biết code làm gì, why cho biết vì sao nó có hình dạng như vậy, còn blast radius cho biết nó làm hỏng gì ở chỗ khác.

Theo ghi nhận skill này nhắc rằng bạn không thể tin write-up của chính mình, nói rõ rằng lịch sử của thread không đáng tin, nên đừng trả lại bản write-up. Hãy tìm một hoặc hai sự kiện mà toàn bộ thay đổi dựa vào và chứng minh chúng bằng cách chạy code. Anh nói skill này tuyệt và đã bắt được vài thứ mà nếu không có nó sẽ rất khổ. Skill cũng dặn viết câu trả lời qua unslop để chắc là không lộn xộn. Trên màn hình, các bước gồm: nhìn chỗ grep dừng lại; trung thực về từng rủi ro; chứng minh một sự kiện duy nhất bằng một script hoặc test chạy code thật và dán kết quả, nếu không chứng minh rẻ được thì đánh dấu "unproven"; và với thay đổi lớn thì chạy nó như một arena, hỏi nhiều model cùng một câu rồi gộp, vì các model khác nhau bắt được các bug thật khác nhau. Phần "What to hand back" gồm: nó làm gì, sự kiện duy nhất khiến nó an toàn, các rủi ro, những gì đã được xóa nghi ngờ, và việc cần làm trước khi merge.

Anh nói anh không muốn video này thành chuyện "cái này hay cái kia", pstack đấu với skill của Pocock. Anh không có ý định đó. Nhưng anh thấy mình hợp về mặt triết lý với những gì Lauren đang nấu ở đây hơn nhiều.

Anh nói chị còn có skill show-me-your-work, rất hay nếu bạn muốn hiểu vì sao một agent làm điều gì đó, để theo dõi chuyện đang diễn ra. Nó giữ một đường mòn quyết định có thể review cho công việc chạy lâu hoặc không giám sát: một log TSV, mỗi quyết định một hàng, gồm cái gì, vì sao, bằng chứng và kết quả. Mặc định lưu cục bộ; chỉ commit khi người thắng hoặc người xem cần dấu vết để tin kết quả. Dùng cho slash show-me-your-work, các lần chạy tự động hoặc nhiều giai đoạn, hoặc công việc mà con người xem lại sau khi đã rời đi. Nó cho agent một định dạng để ghi lại công việc và quá trình ra quyết định theo một dạng TSV đơn giản, dễ đọc và dễ dùng cho việc khác.

Theo đọc các quy tắc: một hàng là một quyết định hoặc một checkpoint. Nếu không vừa một dòng thì quyết định đó chưa rõ ràng. Chỉ ghi thêm (append only). Một quyết định sai thì có hàng mới thay thế nó. Ưu tiên bằng chứng sinh ra từ script đã commit hơn là việc làm tay một lần, để reviewer có thể chạy lại. Anh nói: "Interesting. Cái này có vẻ thật sự hay. Tôi sẽ chơi thêm với nó sau."

15. Kết luận: đọc, chọn, kéo về, đừng cài mù

Theo thừa nhận video này đáng lẽ là một bản tổng quan, nhưng thứ người xem nhận được thay vào đó là quy trình thật của anh. Anh đã làm gần như đúng mọi điều trong video, chỉ với độ sâu ít hơn một chút, từ vài ngày trước. Đó là cách anh tìm ra những skill hay mà anh tìm được. Và đó cũng nên là điều người xem làm. Đừng cài mù một đống thứ khi bạn có thể dành thời gian đọc những thứ khớp với công việc của mình và cách mình làm, rồi kéo về những phần thật sự muốn. Mọi thứ nên bắt đầu từ một thứ nhỏ. Hãy lấy cái bạn thích. Anh nghĩ ai cũng nên có unslop vào lúc này. Skill đó đã thay đổi hoàn toàn mức độ sẵn lòng đọc những gì agent nói với anh. Anh nói nó thật tuyệt.

Anh đùa rằng video này có thể dài hàng giờ, hoặc là một đoạn short 45 giây, hoặc nhiều thứ khác. Nó không hẳn là thứ anh mong đợi hay muốn nó thành, nhưng anh hy vọng người xem vẫn rút được vài điều có ích. Anh chốt thành các bước:

1. Việc đầu tiên: lấy agent của bạn, mở nó ra, kể về pstack và skill của Matt Pocock, nhờ nó xem qua rồi xem lịch sử của bạn và tìm ra cái nào hợp lý dựa trên cách bạn làm việc. Có lẽ nên cài skill unslop trước đó, vì như vậy bạn sẽ thật sự muốn đọc các câu trả lời nhận được.
2. Sau đó hãy xem lại kết quả. Hãy đọc phần markdown của các skill bạn sắp cài trước khi cài.
3. Rồi quyết định cái nào bạn muốn. Bạn có thể bảo agent thiết lập. Bạn có thể dùng một repo duy nhất chứa tất cả skill của mình như anh làm. Anh thấy cách đó rất mạnh. Bạn có nhiều lựa chọn về cách quản lý tất cả, nhưng bạn nên quản lý nó.

Theo nhấn mạnh: bạn không nên sao chép mù setup của người khác. Bạn không nên chạy các lệnh cài 500 skill mà bạn chẳng biết gì về chúng. Hãy tận dụng cơ hội này để tinh chỉnh bộ công cụ của mình dựa trên những gì bạn thấy hiệu quả ở người khác và những gì bạn tự thử thiết lập. Dựa trên lịch sử và cách dùng của chính mình, hãy điều chỉnh những chỗ nhỏ. Và đừng sợ sửa các file này. Anh để ý nhiều người sợ mở file Claude của họ, hay thư mục .claude và .agents trên máy. Anh nói như vậy thật ngớ ngẩn và bạn phải vượt qua nó, vì có rất nhiều thứ thú vị bạn làm được khi bắt đầu đào bới và chơi với chúng. Bạn phải sẵn lòng sửa các file đó.

Anh đùa rằng giờ lần duy nhất anh mở code editor là để sửa file markdown, và gần như không còn là đùa nữa: giờ chỉ còn file markdown và biến môi trường. Điều này giúp anh rất nhiều. Đó là một trong những thay đổi lớn nhất cho phép anh làm nhiều việc agent song song hơn hẳn. Đó là một phần lớn lý do anh ship được nhiều PR như vậy với rất ít lỗi trong cuối tuần vừa rồi. Cách anh làm việc giờ rất khác, và phần lớn là vì anh đã dành thời gian đi sâu vào các thư mục này và gom các skill phù hợp cho chính mình và cho người khác với công việc anh làm. Anh hy vọng điều này truyền cảm hứng để người xem làm điều tương tự.

Anh kết bằng lời mời: hãy khám phá các bộ skill mà mọi người đã công bố. Đừng cài mù. Hãy lục lọi, thử chúng, kéo về những phần bạn thích, bỏ qua những phần bạn không thích. Hãy chơi. Theo nói anh nghĩ mình đã nói hết những gì cần nói: có những thứ thực sự hay trong skill của Matt và còn nhiều thứ hay hơn trong skill của Lauren. Hãy xem cả hai, và có thể tự làm vài skill của riêng bạn nữa. Anh tò mò điều này ảnh hưởng thế nào đến workflow của người xem và mời để lại ý kiến. Anh chào tạm biệt như thường lệ: "peace, nerds."