Một vấn đề tôi hay gặp khi làm việc với coding agent là nó có xu hướng bắt tay vào code ngay lập tức. Tôi đưa ra một yêu cầu mơ hồ, nó cũng hiểu theo cách của nó và bắt đầu viết. Kết quả là phải đi sửa lại nhiều hơn mức cần thiết, hoặc tệ hơn là nó đi sai hướng hoàn toàn mà tôi không hay biết cho đến khi quá muộn.
Superpowers là một dự án mã nguồn mở giải quyết đúng vấn đề này. Nó cung cấp một bộ 14 "kỹ năng" (skills) có cấu trúc, buộc agent phải đi qua các bước bài bản trước khi chạm vào code.
§1Bộ quy trình 7 bước
Các skill trong Superpowers nối với nhau thành một quy trình, mỗi skill là một mắt xích:
- Brainstorming: Trước khi làm bất cứ điều gì, agent phải hỏi, thảo luận, và đề xuất 2–3 hướng giải quyết để bạn chọn.
- Using git worktrees: Tạo môi trường làm việc riêng biệt, tránh làm bẩn nhánh chính.
- Writing plans: Lên kế hoạch chi tiết với các task nhỏ 2–5 phút, bao gồm đường dẫn file chính xác và bước kiểm tra.
- Subagent-driven development: Triển khai bằng cách dispatch các subagent độc lập cho từng task, kèm review hai tầng.
- Test-driven development: Bắt buộc theo chu trình RED–GREEN–REFACTOR, tức viết test trước rồi mới viết code.
- Requesting code review: Review có hệ thống, phân loại mức độ nghiêm trọng của từng vấn đề.
- Finishing development branch: Kiểm tra toàn bộ, dọn dẹp branch, đề xuất merge hoặc tạo PR.
Quy trình này là bắt buộc, agent không được bỏ qua bước nào.
§2Những chi tiết thú vị bên trong
Đọc kỹ từng skill thì tôi mới thấy từng quyết định thiết kế đã được nghĩ kỹ đến mức nào.
HARD-GATE trong Brainstorming
Skill brainstorming có một nguyên tắc cứng:
"Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity."
Và nó còn xử lý trực tiếp cái tâm lý "task này quá đơn giản, không cần design":
"Simple projects are where unexamined assumptions cause the most wasted work."
Quy trình brainstorming bao gồm 9 bước từ khám phá project context, hỏi từng câu một (không hỏi nhiều câu cùng lúc), đề xuất 2–3 hướng tiếp cận, trình bày design theo từng phần để lấy phê duyệt, viết spec document, cho subagent review spec, rồi mới chuyển sang lên kế hoạch. Agent chỉ được phép chuyển sang writing-plans sau khi bạn đã approve spec.
Iron Law trong Debugging
Skill systematic-debugging gọi nguyên tắc của nó là "Iron Law":
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRSTQuy trình debug được chia thành 4 phase: điều tra nguyên nhân gốc rễ, phân tích pattern, đặt giả thuyết và kiểm tra, rồi mới implement fix. Điểm hay nhất là phần xử lý "3+ lần fix thất bại":
"If 3+ fixes failed: Question the architecture — each fix reveals new shared state/coupling/problem in a different place. Stop and discuss with your human partner before attempting more fixes."
Đến lúc đó, skill này yêu cầu agent dừng lại và đặt câu hỏi về kiến trúc thay vì thêm fix thứ 4. Đọc là biết quy tắc này đến từ người đã debug nhiều.
Skill còn liệt kê các "red flag", tức những dấu hiệu cho thấy agent đang debug sai cách, ví dụ: "Quick fix for now, investigate later", "Just try changing X and see if it works", "I don't fully understand but this might work". Khi agent bắt đầu nghĩ như vậy, nó phải dừng lại và quay về Phase 1.
Kế hoạch viết cho người không biết gì
Skill writing-plans có một tiêu chuẩn rất cụ thể cho chất lượng của một bản kế hoạch:
"Clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow."
Mỗi task trong kế hoạch phải có đường dẫn file chính xác, code hoàn chỉnh (không phải "add validation" chung chung), lệnh chạy cụ thể kèm output mong đợi. Mỗi task chỉ làm một việc, theo đúng thứ tự: viết test, chạy test để xác nhận nó fail, viết code, chạy test để xác nhận nó pass, rồi commit.
§3Toàn bộ 14 skills
| Skill | Mục đích | |
|---|---|---|
brainstorming |
Khám phá ý tưởng và thiết kế trước khi code | ↗ |
writing-plans |
Lên kế hoạch chi tiết từng task nhỏ | ↗ |
executing-plans |
Thực thi kế hoạch theo từng bước | ↗ |
subagent-driven-development |
Dispatch subagent độc lập cho từng task | ↗ |
dispatching-parallel-agents |
Chạy nhiều agent song song | ↗ |
test-driven-development |
Chu trình RED–GREEN–REFACTOR | ↗ |
systematic-debugging |
Debug 4 phase có hệ thống | ↗ |
verification-before-completion |
Xác nhận kết quả trước khi khai báo xong | ↗ |
requesting-code-review |
Khởi tạo và cấu trúc code review | ↗ |
receiving-code-review |
Tiếp nhận và xử lý phản hồi review | ↗ |
using-git-worktrees |
Quản lý môi trường làm việc riêng biệt | ↗ |
finishing-a-development-branch |
Hoàn tất và dọn dẹp sau khi xong | ↗ |
writing-skills |
Viết thêm skill mới | ↗ |
using-superpowers |
Giới thiệu hệ thống cho agent | ↗ |
§4Triết lý đằng sau
Thứ Superpowers thêm vào cho agent là kỷ luật. Bốn nguyên tắc cốt lõi của dự án là: test trước code, có hệ thống thay vì tự phát, đơn giản là mục tiêu hàng đầu, và bằng chứng thay vì tuyên bố.
Tôi thấy triết lý này quen thuộc, vì một senior developer có kinh nghiệm vẫn làm đúng như vậy theo thói quen. Superpowers chỉ đang encode những thói quen đó thành các rule để agent không được phép bỏ qua.
Có một câu trong README mà tôi thích: "It's not uncommon for Claude to be able to work autonomously for a couple hours at a time without deviating from the plan." Theo tôi, agent làm được vậy là nhờ có một bản đồ rõ ràng để đi theo.