Đến nội dung chính
Phạm Nam

Tìm kiếm

Nhập từ khoá để tìm trong các bài viết.

Quay lại

Superpowers AI coding agent: spec trước, test trước

Superpowers giúp AI coding agent làm việc kỷ luật hơn: hỏi rõ ý đồ, viết plan task 2–5 phút, TDD và review hai vòng trước khi merge. Cách cài cho từng harness.

10 phút đọc—

Bạn giao cho AI coding agent một yêu cầu, nó viết code ngay, test chạy được, bạn merge. Vài tuần sau, người khác mở file đó ra và không hiểu vì sao tính năng lại làm theo cách này, test che chỗ nào, và quyết định thiết kế nằm ở đâu. Code chạy, nhưng không ai dám sửa.

Đó là kiểu nợ kỹ thuật mà agent tạo ra rất nhanh, vì agent hiếm khi tự dừng lại để hỏi: “Anh thực sự muốn cái này làm gì?” Superpowers, dự án mã nguồn mở của obra trên GitHub, sinh ra để chặn đúng chỗ đó. Nó là một bộ kỹ năng kèm phương pháp làm việc cài vào agent bạn đang dùng: hỏi rõ ý đồ trước, viết spec và plan trước, viết test trước, và review trước khi merge.

Vấn đề: vì sao agent viết code ngay lại gây nợ kỹ thuật?

Yêu cầu của con người hiếm khi đầy đủ. “Thêm tính năng xuất báo cáo” không nói rõ xuất cho ai, định dạng nào, dữ liệu lấy từ đâu, và khi không có dữ liệu thì xử lý ra sao. Con người nhận yêu cầu mơ hồ thường hỏi lại. Agent mặc định thì ngược lại: nó lấp khoảng trống bằng giả định và viết code cho cách hiểu đó. Kết quả vẫn chạy được trong demo, nhưng không phải thứ bạn cần.

Workflow viết code ngay có ba lỗ hổng nối tiếp. Thứ nhất, không có spec: quyết định thiết kế nằm rải rác trong code, không có văn bản nào để đối chiếu khi tranh luận. Thứ hai, không có test viết trước: test thường viết sau để khớp với code vừa sinh ra. Thứ ba, không có review tách bạch: người giao việc cũng là người duy nhất đọc code.

Theo mình, viết code ngay không phải lúc nào cũng sai. Sửa một dòng hay viết script dùng một lần rồi bỏ thì không cần spec. Chi phí của kỷ luật chỉ đáng trả khi thay đổi có người khác phải đọc, phải bảo trì, hoặc sai thì phải trả giá: tính năng cho người dùng thật, thay đổi schema, logic tính tiền, script vận hành chạy trên hệ thống thật.

Superpowers là gì? Framework kỹ năng, không phải ứng dụng độc lập

Superpowers là một framework kỹ năng và phương pháp phát triển phần mềm cho AI coding agent, phát hành dưới giấy phép MIT tại repo obra/superpowers. Phiên bản mới nhất tại thời điểm đối chiếu là v7.0.1, phát hành ngày 21/10/2026. Theo bản chụp GitHub Trending của OctoCounts ngày 30/10/2026, repo này đứng thứ hai trong ngày với khoảng 1.034 sao mới. Đó là dấu hiệu đang được chú ý, không phải bằng chứng chất lượng.

Điểm cần hiểu rõ ngay từ đầu: Superpowers không có server riêng, không có ứng dụng để mở, không thay model bạn đang dùng, và không thay CI của team. Nó là một tập hợp các skill dạng Markdown kèm hướng dẫn khởi động, được đóng gói riêng cho từng harness. Bạn cài nó vào Claude Code, Cursor, Gemini CLI hay Codex, và agent trong harness đó làm việc theo phương pháp trong skill.

Nó giải quyết một vấn đề về kỷ luật, không phải về năng lực: các skill biến thói quen tốt thành workflow bắt buộc, và code viết trước test sẽ bị xóa theo luật của skill TDD. Đối tượng phù hợp nhất là người dùng AI coding agent hàng ngày cho những thay đổi cần bảo trì lâu dài.

Kiến trúc và cơ chế hoạt động

Bộ kỹ năng gồm 15 skill, xếp thành bốn nhóm:

NhómSkillVai trò
Định hướngbrainstorming, writing-plans, using-superpowers, writing-skillsLàm rõ ý đồ, viết spec và plan
Thực thisubagent-driven-development, executing-plans, using-git-worktrees, dispatching-parallel-agentsChia task nhỏ, chạy subagent, làm trên worktree riêng
Chất lượngtest-driven-development, systematic-debugging, verification-before-completionViết test trước, gỡ lỗi có hệ thống, kiểm chứng trước khi xong
Kết thúcrequesting-code-review, receiving-code-review, finishing-a-development-branch, diagnosing-superpowersReview hai chiều, hoàn tất branch, chẩn đoán sự cố

Luồng làm việc chuẩn gồm bảy bước: brainstorming; tạo git worktree riêng; viết plan với task 2–5 phút; subagent thực thi từng task với context sạch; TDD theo chu trình RED–GREEN–REFACTOR; code review hai vòng; rồi hoàn tất branch và merge. Luồng dữ liệu đi theo đúng thứ tự đó: ý đồ thành spec, spec thành plan, plan thành code và test, rồi bản review đạt mới thành merge.

Cơ chế bắt buộc của Superpowers là quy ước kích hoạt skill, không phải cưỡng chế ở tầng code: vì nó chỉ là hướng dẫn bằng prompt, một harness có thể tuân thủ không đầy đủ. Đây là giới hạn lớn nhất của toàn bộ phương pháp.

Về phụ thuộc kỹ thuật, Superpowers cần một harness được hỗ trợ trong số 16 harness mà tài liệu liệt kê, model và API của chính harness đó, Git, và một test runner. Nó không có runtime riêng, không có API key riêng, và không lưu trạng thái riêng ngoài những gì nằm trong repo và phiên làm việc của agent.

Hướng dẫn cài đặt theo từng harness

Trước khi cài, bạn cần ba thứ: một harness được hỗ trợ và đã đăng nhập model/API, một Git repo, và một test runner chạy được. Thiếu Git repo, worktree và quy trình branch không có chỗ đứng. Thiếu test runner, TDD chỉ còn là khẩu hiệu.

Nói rõ: các lệnh dưới đây mình đối chiếu với tài liệu chính thức ngày 31/10/2026, nhưng chưa chạy thử trên máy thật.

Mỗi harness cài riêng; không có lệnh cài toàn cục duy nhất.

Claude Code, qua marketplace chính thức:

/plugin install superpowers@claude-plugins-official

Hoặc qua marketplace của chính Superpowers: /plugin marketplace add obra/superpowers-marketplace, rồi /plugin install superpowers@superpowers-marketplace.

Cursor, trong Agent chat: /add-plugin superpowers. Gemini CLI: gemini extensions install https://github.com/obra/superpowers (cập nhật: gemini extensions update superpowers). Codex: mở /plugins, tìm superpowers, chọn Install Plugin. Copilot CLI: copilot plugin marketplace add obra/superpowers-marketplace, rồi copilot plugin install superpowers@superpowers-marketplace.

Sau khi cài, khởi động lại harness và kiểm tra Superpowers đã xuất hiện trong danh sách plugin chưa. Sau đó mở một phiên mới và bắt đầu bằng một yêu cầu brainstorming về một tính năng còn mơ hồ. Kết quả kỳ vọng: agent hỏi lại để làm rõ ý đồ và trình bày lại spec theo từng phần để bạn duyệt.

Cập nhật phụ thuộc từng harness và thường tự động. Gỡ plugin khỏi harness là xong, vì Superpowers không có server hay dữ liệu riêng cần migrate. Về telemetry, thành phần giao diện tùy chọn của skill brainstorming tải logo kèm theo chỉ phiên bản Superpowers, không kèm prompt hay mã nguồn của bạn; nếu môi trường của bạn có quy định chặt về kết nối ra ngoài, hãy đặt biến SUPERPOWERS_DISABLE_TELEMETRY thành giá trị true.

Lỗi thường gặp: cài nhầm marketplace thì gỡ plugin và cài lại đúng lệnh; harness ngoài 16 harness được hỗ trợ thì đừng cố chép skill sang tay; skill không kích hoạt thường do bạn ra lệnh code trực tiếp, hãy bắt đầu lại bằng brainstorming.

Đánh giá kỹ thuật

Ưu điểm rõ nhất là spec được chốt trước khi code, nên tranh luận diễn ra lúc còn rẻ. Task 2–5 phút có file đích, nội dung và bước kiểm chứng rõ ràng, nên bạn review từng mẩu nhỏ thay vì đọc một diff khổng lồ cuối ngày. TDD buộc hành vi phải được viết thành test trước, thay vì test viết sau để khớp code. Hai vòng review trước khi merge tạo ra một con mắt thứ hai.

Nhược điểm cũng đến từ chính những ưu điểm đó. Hỏi đáp, viết plan, chạy subagent và hai vòng review đều tốn thêm lượt tương tác, token và thời gian. Với task nhỏ hoặc task thăm dò, phần overhead này lớn hơn phần việc chính. Theo mình, đây không phải lỗi của công cụ mà là bản chất của kỷ luật: nó được thiết kế để làm chậm những việc đáng làm chậm.

Chạy song song bằng nhiều subagent, mỗi subagent mang context riêng, cộng với hai vòng review, cũng tốn token hơn hẳn một lần chạy agent trực tiếp. Dự án không công bố benchmark nào đã được kiểm chứng cho sự đánh đổi này, nên bạn phải tự đo trên dự án của mình.

Về bảo mật, mã nguồn MIT và không có server riêng là hai điểm cộng: không có thêm bên thứ ba nào giữ code của bạn. Rủi ro chính nằm ở prompt và quyền mà bạn cấp cho agent trong repo. Agent làm việc trên worktree vẫn có quyền đọc và sửa code trong repo đó, và review bằng agent không thay thế review của con người với những thay đổi nhạy cảm. Vì vậy hãy giới hạn quyền agent ở mức cần thiết và không đưa secret vào prompt brainstorming.

Về vận hành, thử trên một branch thì dễ, chuẩn hóa cho cả team thì khó hơn: cập nhật tự động theo từng harness, hành vi skill khác nhau giữa 16 harness, và không có bảng điều khiển tập trung nào cho thấy team đang dùng phiên bản nào.

So sánh với các lựa chọn cùng phạm vi

Tiêu chí: phạm vi, cơ chế bắt buộc, TDD, review trước merge, hỗ trợ harness, chi phí vận hành.

Lựa chọnPhạm viTDD và reviewChi phí vận hành
SuperpowersToàn quy trình, 15 skillCó, là một phần của workflowCao: nhiều lượt agent, token, review
Skill đơn mục đích (Impeccable, Hallmark, Cloudflare Security Audit Skill)Một khâu: thiết kế hoặc auditKhông, trừ khi bạn tự thêmThấp: chỉ chạy khi cần khâu đó
Agent mặc định không có phương phápKhông có quy trìnhKhông bắt buộcThấp nhất, nhưng rủi ro lệch yêu cầu cao nhất
Quy trình tự viết của team (AGENTS.md, custom skill, checklist review)Tùy team định nghĩaTùy team viếtTrung bình: team tự bảo trì tài liệu

So với skill đơn mục đích, Superpowers không thay thế chúng mà có thể đi cùng chúng. Bạn có thể dùng Impeccable cho khâu thiết kế hay Hallmark để chống thiết kế cẩu thả, trong khi Superpowers lo phần khung. Tương tự, Cloudflare Security Audit Skill chỉ là skill audit cho một mục đích hẹp.

So với agent mặc định, khác biệt lớn nhất nằm ở những gì còn lại sau đó: spec đã duyệt, plan có task nhỏ, test ràng buộc hành vi, và bản review. Nếu bạn cần thứ mà ba tháng sau người khác vẫn hiểu và dám sửa, khung quy trình mới bắt đầu đáng giá.

So với quy trình tự viết của team, Superpowers tiết kiệm công viết và bảo trì tài liệu, đổi lại bạn chấp nhận một phương pháp do bên ngoài định nghĩa và hành vi có thể lệch giữa các harness. Một file AGENTS.md do team tự viết thì hẹp hơn nhưng team kiểm soát hoàn toàn. Theo mình, team đã có quy trình nội bộ chạy tốt thì không cần Superpowers.

Headroom lo chuyện nén context, còn Superpowers lo trình tự làm việc, nên hai thứ này không cạnh tranh nhau; tương tự, CC Switch chỉ chuyển provider cho cùng một người dùng agent.

Trường hợp sử dụng thực tế

Với team backend, Superpowers hợp nhất khi làm tính năng lớn: spec chốt trước giúp backend và frontend thống nhất hành vi API trước khi code, và review trước merge giúp giữ chuẩn chung.

Với DevOps và SRE, giá trị nằm ở chỗ thay đổi infrastructure-as-code và script vận hành cũng đi qua test và review trước khi áp dụng. Việc bắt agent viết test và để review chặn lại trước khi chạy là đáng giá, miễn là test đó thực sự chạy được trên môi trường thử.

Với IT admin, sysadmin và homelab, kịch bản thực tế là viết script tự động hóa trên branch riêng, có đường lui rõ ràng: làm sai thì bỏ worktree và chỉ merge khi đã review. Dự án có nói về agent làm việc tự chủ trong nhiều giờ, nhưng đó là tuyên bố của dự án, chưa phải kết quả mình kiểm chứng.

Rủi ro, giới hạn và phương án rollback

Rủi ro thực tế nhất là mất code viết trước test: skill TDD xóa code viết trước test, nên code thăm dò chưa commit trên branch có thể mất khi bạn vào workflow giữa chừng. Quy tắc: commit hoặc stash công việc thăm dò trước khi bắt đầu một phiên TDD.

Rủi ro thứ hai là worktree lệch với branch chính: agent làm việc càng lâu trên worktree riêng, branch chính càng đi xa, và lúc merge sẽ phải giải quyết xung đột. Cách giảm thiểu là giữ phiên làm việc gọn và merge sớm sau khi review đạt.

Rủi ro thứ ba là review vòng hai kéo dài: nếu mỗi vòng lại sinh thêm yêu cầu sửa, phiên làm việc có thể không đến được merge. Đặt giới hạn trước: review vòng hai chỉ chặn những lỗi thật sự.

Rollback thì nhẹ nhàng, vì Superpowers không lưu trạng thái riêng. Chưa merge thì bỏ worktree và branch đó là xong. Đã merge rồi thì revert commit đó trên Git. Muốn dừng hẳn thì gỡ plugin khỏi harness, không có dữ liệu nào cần migrate.

Kết luận: ai phù hợp, ai chưa phù hợp và bước tiếp theo

Superpowers phù hợp với team và cá nhân dùng AI coding agent cho những tính năng có yêu cầu phức tạp, cần test ràng buộc hành vi và cần review trước khi merge. Nó chưa phù hợp với task một dòng, sửa nóng, thăm dò nhanh, hay môi trường chưa có Git hoặc test runner.

Bước tiếp theo, theo mình, không phải cài đại trà cho cả team. Hãy cài cho một harness duy nhất mà bạn dùng nhiều nhất, chạy một phiên đầy đủ brainstorming, plan, TDD và review trên một branch thử, rồi xem ba thứ: spec có giúp phát hiện hiểu sai sớm không, task nhỏ có làm review dễ hơn không, và tổng thời gian có chấp nhận được không. Nếu cả ba đều là có, lúc đó mới tính đến chuyện chuẩn hóa cho team.

Tham khảo


Bài viết liên quan

Bình luận

Bình luận được duyệt trước khi hiển thị.

Đang tải bình luận…

Để lại bình luận