Pocock, pstack hay Osmani: chọn skill pack nào

1. Addy Osmani mở mã nguồn bộ agent skills, mảnh thứ ba của "big three"

Rob mở đầu bằng tin chính của video: Addy Osmani, có lẽ là một trong những engineer được kính trọng nhất ở Google suốt hơn một thập kỷ, vừa chuyển sang Anthropic, công ty làm ra Claude Code. Và anh vừa open source toàn bộ bộ agent skills của mình. Sau khoảng 100.000 star, đây có lẽ là một trong những repo AI phổ biến nhất trên GitHub lúc này.

Ai theo dõi kênh sẽ biết Rob đã phân tích hai bộ trước đó: pstack của Lauren Tan ở Cursor, và bộ skills của Matt Pocock. Như vậy Addy là cái tên thứ ba trong "big three".

Số đo trên GitHub ngày 17/10/2026: addyosmani/agent-skills khoảng 108 nghìn star, nên mốc "qua 100.000" là đúng. Nhưng mattpocock/skills có khoảng 295 nghìn star, gần gấp ba. pstack là một thư mục trong monorepo cursor/plugins, không có repo riêng, nên không có số star của riêng nó; số star của repo mẹ không nói gì về pstack. Cả ba bộ đều phát hành theo giấy phép MIT.

Giờ đã có đủ cả ba, ta thấy rõ chúng đang giải những bài toán khác nhau. Rob hứa đến cuối video, người xem sẽ biết Addy đang làm gì, khi nào nên với tới pack nào, và vì sao anh nghĩ bạn không cần chạy cả ba trên mọi project: đôi khi như thế là hơi quá tay (overkill). Anh tự giới thiệu: "Tôi là Rob, đây là Switch Dimension", rồi bắt đầu với cách Addy nghĩ về bộ skill của mình.

2. Addy Osmani là ai, và vì sao nên để ý

Một chút bối cảnh cho ai chưa biết: Addy là một huyền thoại trong giới JavaScript. Anh viết cuốn Learning JavaScript Design Patterns. Anh dẫn dắt mảng Chrome Developer Experience và Web Performance ở Google. Nếu bạn từng chạy Lighthouse hay đọc về Core Web Vitals, rất có thể bạn đã chịu ảnh hưởng từ công việc của anh ở giai đoạn nào đó. Trên màn hình, Rob lướt qua trang giới thiệu Lighthouse, trang Core Web Vitals với ba chỉ số LCP, INP, CLS, và một sân khấu hội nghị có dòng chữ "Former Director of Google Cloud AI".

Theo Rob, điều đó rất đáng kể: khi một người như Addy viết ra "đây là cách bạn muốn một agent làm software engineering", bạn nên chú ý. Thứ bạn thực sự nhận được là bộ óc của một engineer dày dạn kinh nghiệm, được nén lại thành Markdown. Và đó là điều Rob thích nhất ở skill.

Trước đây, ta đọc cả chồng sách O'Reilly để học best practice. Giờ thì về cơ bản ta nghiên cứu và mổ xẻ skill của những người giỏi nhất.

3. Ý tưởng lớn: một vòng đời sáu giai đoạn, mỗi giai đoạn một slash command

Ý tưởng lớn của Addy là một vòng đời (lifecycle) gồm sáu giai đoạn: Define, Plan, Build, Verify, Review, Ship. Mỗi giai đoạn đi kèm một slash command. Nếu bạn đã xem video của Rob trong hai năm qua, hoặc từng làm spec-driven development với BMAD hay superpowers, mọi thứ sẽ rất quen. Và đó chính là điểm mấu chốt.

Skill của Matt có từ vựng riêng: grilling, wayfinder, "fog of war". pstack có poteto mode và arena. Còn của Addy là bộ bám sát software development lifecycle truyền thống nhất. Bạn không phải học một ẩn dụ (metaphor) nào cả. Đó đơn giản là software development lifecycle được làm đúng cách, với một agent. Vì vậy, trong cả ba stack, Rob nghĩ bộ này có thể khớp rất tốt với một development team đang có sẵn, hoặc trong môi trường enterprise.

Đi qua từng bước: /spec viết một PRD tử tế, bao gồm mục tiêu (objectives), cấu trúc, code style, testing và các ranh giới (boundaries), trước khi có bất kỳ dòng code nào. /plan chia PRD đó thành các task nhỏ, nguyên tử (atomic), mỗi task có acceptance criteria. /build implement từng lát cắt dọc mỏng (thin vertical slice) một lần: bạn implement, bạn test, bạn verify. Bạn commit nó, rồi test, review và ship.

4. /build auto và các lệnh còn lại: 25 skill, bốn reviewer persona

Có một mode Rob rất thích, tên là /build auto. Bạn duyệt plan một lần, sau đó nó tự chạy mọi task một cách autonomous. Nó bỏ đi việc bạn phải nhảy vào giữa các task, nhưng nó không bỏ phần verification, và đó là chỗ quan trọng bạn cần để ý. Mỗi task vẫn được làm theo kiểu test-driven, và được commit riêng.

Rồi nó dừng lại nếu có gì đó fail. Rob cho rằng đó là cách đúng để làm autonomy. Trên màn hình, một slide tóm lại đúng ý này: "Removes the human between tasks. Not the tests."

Các lệnh khác: /constraints về cơ bản là một kiểu phỏng vấn (interview) khác, để dò xem mức chất lượng, tức quality bar, của bạn là bao nhiêu. Rồi nó ghi kết quả vào một file constraints.md. Kế đến là /webperf cho web performance: nó làm một performance audit. Rob đùa rằng với người viết ra nó, Addy Osmani, "ông vua web performance", bạn sẽ mong cái này phải tốt. Còn /code-simplify là cho lúc code chạy được nhưng chẳng ai muốn đụng vào nữa, và bạn muốn đơn giản hoá hay tách nó ra. Rob nhận xét có rất nhiều chỗ chồng lấn giữa những gì Lauren nói, những gì Matt Pocock nói, về các skill tương tự nhau.

Tổng cộng có 25 skill, cộng thêm bốn reviewer persona: một staff engineer, một test engineer, một security auditor và một web performance auditor. Trên màn hình, Rob mở file persona Web Performance Auditor, với hai chế độ làm việc: Quick mode (mặc định, không cần artifact công cụ nào) và Deep mode (bật khi có kết quả đo thật như báo cáo Lighthouse hay PageSpeed Insights).

5. Bên trong skill: bảng anti-rationalization

Giờ nhìn vào bên trong các skill. Như mọi lần trên kênh này, Rob nhấn mạnh: slash command không phải phần thú vị, file skill mới là phần thú vị. Đây là chỗ ta thật sự bước vào bộ óc của một software engineer.

Mỗi skill có cái Addy gọi là anti-rationalization table (bảng chống ngụy biện). Đó là danh sách những lý do mà một agent sẽ đưa ra để bỏ qua một bước. Ta thấy agent làm chuyện này suốt. Và ngay bên cạnh mỗi lý do là lời phản bác, giải thích vì sao không được bỏ qua.

Nó sẽ soi những thứ trong reasoning trace kiểu "cái này đơn giản quá, không cần test" hay "tôi đã test bằng tay rồi". Rob nói: nếu bạn từng làm việc với agent, hoặc từng làm việc với các bạn junior, bạn đã nghe hết những lý do này. Viết sẵn chúng ra từ trước là một nước đi thật sự thông minh.

6. Doubt-driven development: hoài nghi ngay trong lúc build

Quay lại các skill, Rob gọi skill tiếp theo là "thật sự thú vị": doubt-driven development. Ta đã nghe tới domain-driven development; đây là doubt-driven development, phát triển dựa trên sự hoài nghi.

Với mọi quyết định không tầm thường, hoặc mọi quyết định quan trọng, nó dựng lên một lượt review với context mới hoàn toàn (fresh context), và việc duy nhất của lượt review đó là nghi ngờ khẳng định. Quy trình là: claim, extract, doubt, reconcile, stop. Về cơ bản đây là adversarial review ngay trong lúc build, chứ không chỉ ở cuối. Trên slide, ô "Doubter Agent" có nhãn "Biased To Disprove" và dòng "Fresh Context".

7. Những "người bạn cũ" của nghề phần mềm

Đọc tiếp các skill còn lại, bạn sẽ bắt đầu nhận ra vài "người bạn cũ" và vài paradigm quen thuộc.

• Hyrum's Law trong skill API design: mọi hành vi quan sát được của API rồi sẽ có ai đó phụ thuộc vào.
• The Beyoncé Rule trong skill testing: "If you liked it, you should have put a test on it", nếu bạn thích nó thì lẽ ra bạn phải đặt một test lên nó. Rob nói thêm: "Tôi sẽ không hát câu này đâu."
• Chesterton's Fence trong code simplification: đừng dỡ hàng rào cho tới khi bạn biết vì sao nó ở đó.
• Và thêm trunk-based development, small atomic commits, code as a liability (code là một khoản nợ).

Đó, về cơ bản, là bộ óc software engineering của Addy Osmani được biến thành chỉ dẫn cho agent. Rob nói thật lòng: kể cả nếu bạn không bao giờ cài bộ này, chỉ đọc qua các skill thôi đã là một khoá học software engineering tốt hơn hầu hết các khoá ngoài kia.

8. Ba pack, ba câu hỏi: Matt Pocock hỏi "ta có đồng ý về thứ đang build không?"

Vậy bộ này so với hai bộ kia thế nào? Rob đặt ba pack lên cùng một trục: trước khi code, trong khi code, và sau khi code. Mỗi pack trả lời một câu hỏi khác nhau.

Skill của Matt Pocock về cơ bản hỏi: ta có đồng ý về thứ mình đang build không? Bạn và agent có thống nhất với nhau không? Bạn đang dựng lên domain. Skill phổ biến nhất của anh có lẽ là grill me: agent tra hỏi bạn trước khi viết bất kỳ thứ gì. Rồi có ý tưởng về một glossary ngôn ngữ chung (shared language), các ADR, tức architecture decision record, bản ghi quyết định. Và sau đó là spec và ticket.

Matt vẫn nằm trong SDLC truyền thống, chỉ là anh tiếp cận theo cách khác. Rất nhiều skill của anh dồn công sức lên phía trước, trước khi bạn thực sự bắt đầu code. Và anh đã nói công khai rằng mình chống framework (anti framework). Anh cho rằng những thứ như BMAD, Spec Kit, superpowers lấy mất quyền kiểm soát của bạn. Vì vậy skill của anh cố tình nhỏ, composable, bạn dùng chúng ở chỗ cần và tự hack chúng theo ý mình. Trên màn hình, README của repo Matt ghi đúng điều đó: các cách tiếp cận như GSD, BMAD, Spec-Kit "take away your control", còn skill của anh thì nhỏ, dễ chỉnh và composable.

9. pstack hỏi "bạn chứng minh được nó chạy không?", Addy hỏi "ta có theo đủ quy trình không?"

Theo cách Rob hiểu, pstack của Lauren Tan xoay quanh câu hỏi: bạn có chứng minh được nó chạy không? Lauren cố tình không có skill nào cho planning. Câu của cô là: spec tốt nhất chính là code. Toàn bộ trọng lượng đặt vào khâu investigation, verification, và review đa phương thức (multimodal) sau khi làm xong. Build pass thì không được tính là bằng chứng. Ta phải chứng minh điều đó.

Skill của Addy thì xoay quanh câu: ta có theo đủ toàn bộ quy trình không? Anh là người duy nhất trong ba người thật sự bao trọn cả vòng đời SDLC, đi tới tận continuous integration và deployment, observability, deprecation và shipping. Nó có lẽ là bộ thân thiện với team nhất, và cũng portable nhất, vì nó cài được vào khoảng 70 agent khác nhau. README của repo cho cách cài nhanh nhất bằng skills CLI:

npx skills add addyosmani/agent-skills            # install all 25 skills
npx skills add addyosmani/agent-skills --list     # browse before installing

Còn bản thân Rob thì kết thúc bằng một hỗn hợp của cả ba. Anh không dùng chúng cùng một lúc mà dùng skill khác nhau ở những thời điểm khác nhau. Anh có ba phiên bản cho "skill runtime" của mình: light, medium và heavy.

10. Khi nào dùng pack nào

Dùng Pocock khi bài toán còn mơ hồ (fuzzy), khi bạn chưa chắc mình muốn gì, hoặc khi bạn làm trên một codebase sẽ sống cùng nhiều năm và bạn thật sự quan tâm tới design. Rob nói Grill Me vẫn là skill tốt nhất mà anh sẽ cài đầu tiên cho việc đó.

Dùng Addy khi bạn làm trong một team, ship lên production, và muốn một quy trình dễ đoán mà ai cũng nhận ra, hoặc khi bạn muốn có đủ mọi quality gate mà không phải tự thiết kế chúng. Bộ skill riêng của Rob nghiêng về kiểu quy trình này, vì anh làm việc với các team developer và dạy họ cách áp dụng agent.

Dùng pstack khi mọi thứ thật sự rối rắm (gnarly): một con bug bạn không tái hiện được; bạn muốn tung swarm và arena vào một vấn đề; có một đợt migration; bạn có các agent chạy dài, có thể là một lượt chạy qua đêm và bạn cần tin được chúng khi thức dậy. Và dĩ nhiên khi bạn dùng Cursor với nhiều model, vì skill của Lauren chạy rất tốt dưới dạng plugin trong Cursor.

Bạn cũng sẽ để ý thấy chúng chồng lấn rất nhiều và có vẻ liên tục mượn của nhau.

11. Chồng lấn là bình thường, và bạn không cần mọi skill

Rob nói thật ra không phải họ mượn của nhau. Chỉ là các software engineer cùng lúc hội tụ về cách xây phần mềm. Nên sẽ có rất nhiều chồng lấn. Và một lần nữa, software engineering vốn đầy chính kiến (opinionated). Bạn chỉ cần chọn chính kiến tốt nhất và áp vào workflow của mình. Về cơ bản đây là ba góc nhìn khác nhau về cùng một nghề.

Quan điểm thật của Rob về tất cả chuyện này: bạn thật sự không cần mọi skill trên từng project. Như thế là quá tay khủng khiếp. Agent giờ đang rất thông minh. Một trong những việc tốt nhất bạn có thể làm là rà lại file AGENTS.md hoặc các skill hiện có, và bắt đầu cắt tỉa (prune) chúng, vì bạn sẽ bất ngờ với độ mạnh của các model.

Rob nghĩ giờ skill là thứ nói lên "đây là cách tôi thích làm việc", hơn là nhất thiết phải dạy agent điều gì mới. Thực tế, có file skill quá dài và quá nhiều skill sẽ chỉ làm phình to và làm rối context window của bạn. Slide "Your Context Window" minh hoạ điều đó: phần task chỉ là một mẩu nhỏ, phần còn lại bị lấp bởi mấy file skill.md, và context đã đầy 70% trước khi làm việc thật.

12. Ceremony phải tương xứng với mức rủi ro

Nếu bạn chỉ đổi màu một cái nút, bạn không cần PRD, không cần chia task, không cần một lượt arena review năm trục của pstack hay một security auditor. Bạn chỉ cần đổi cái nút rồi nhìn nó. Cách Rob nghĩ về chuyện này là theo mức effort: ceremony phải tương xứng với mức rủi ro (stakes) của việc bạn đang làm.

• Chỉnh nhỏ (small tweak): cứ làm, rồi tự kiểm tra. Nếu là việc rất trực quan hay mang tính prototype, cứ tự làm, kiểm nhanh, refresh rồi đi tiếp. Bạn đang lặp (iterate) cùng agent.
• Feature nhỏ: một lượt grill me nhanh hoặc một discovery session để hai bên thống nhất, rồi một chút test-driven development.
• Feature lớn hoặc mơ hồ mà bạn còn đang cố hình dung: một spec và một plan chia thành các phase, và bạn verify từng phase ở giữa.
• Production, có dính tới bảo mật, hoặc bất cứ thứ gì không đảo ngược được: đó là lúc mang ra đầy đủ: full review, doubt-driven development, và toàn bộ phần security hardening đi kèm.

13. Chính Addy cũng bảo: đừng cài hết 25 skill

Ngay cả Addy cũng nói điều này về skill của chính mình. Hướng dẫn áp dụng (adoption guide) của anh là triển khai dần dần, verification trước, trên một codebase đang có. Đừng cài 25 skill rồi cố chạy hết mọi thứ. Đó là quá tải hoàn toàn.

Và còn một chi phí thực tế nữa. Mỗi skill bạn cài là một thứ agent phải cân nhắc. Rồi bạn có thể vô tình kích hoạt tự động (auto trigger) những skill đó vào lúc bạn không muốn. Nhiều skill hơn không có nghĩa là agent thông minh hơn. Slide lúc này chỉ có một dòng: "More skills ≠ smarter agent".

14. Bài học thật: học skill là học good practice

Rob cho rằng bài học thật ở đây, điều anh đã nói từ lâu, là: học những skill này thực chất là học software development practice tốt. Test-driven development, các lát cắt dọc nhỏ, thống nhất requirement trước khi build, viết ra lý do vì sao mình đưa ra một quyết định. Không dỡ hàng rào khi chưa biết vì sao nó ở đó: đừng đi xoá bất cứ thứ gì cho tới khi bạn biết chính xác vì sao nó tồn tại. Và chứng minh nó chạy trên thứ thật. Chỉ thấy test xanh không có nghĩa là app của bạn chạy. Bạn cần thật sự test cho đúng.

Và không có gì trong số này là mới. Không ai trong ba người phát minh ra nó. Matt Pocock ghi công cho The Pragmatic Programmer và Domain-Driven Design. Addy về cơ bản là cuốn sách engineering của Google. Lauren có nhiều năm kinh nghiệm với React và ở Meta. Skill chỉ là những ý tưởng đó, được đặt vào một định dạng mà agent làm theo được.

15. Xây bộ skill của riêng bạn

Vì vậy, Rob khuyên đừng coi pack nào là một tôn giáo. Hãy coi chúng như một cuốn sách giáo khoa O'Reilly. Bạn có thể cài chúng, đọc chúng, lấy những gì hiệu quả, rồi xây skill của riêng mình bên trên. Về cơ bản đó là mã hoá cách bạn làm việc. Bạn chia sẻ phần tốt nhất với team, và team chia sẻ ngược lại. Đó là stack của bạn, quality bar của bạn. Về cơ bản đây là team của bạn, hay harness cá nhân của bạn. Nó sẽ được may đo riêng cho bạn và giúp bạn đi nhanh hơn rất nhiều.

Và mỗi lần agent làm hỏng gì đó: "Đừng như con nít. Đừng chửi nó." Cứ đi cập nhật skill của bạn dựa trên những gì vừa học được. Đó chính xác là cách cả ba pack này được xây nên.

Rob nhắc tới khoá học và cộng đồng Switch Dimension của mình cho ai muốn đi sâu hơn vào việc xây thư viện skill và agent workflow. Anh hỏi người xem: bạn đang chạy skill pack nào, và bạn đã tự viết bộ skill nào chưa? Anh muốn biết mọi người thật sự đang build và dùng gì trên production. Đây là một series; video phân tích pstack và video về Matt Pocock là hai video nên xem tiếp theo.