Superpowers sửa Claude Code, nhưng có một cái giá thật

Superpowers là một plugin cho Claude Code do Jesse Vincent viết, người đã phát hành công cụ mã nguồn mở cho dev từ thập niên 1990. Ông ra mắt nó vào tháng 10, và chưa đầy một năm sau, repository đã đạt 280.000 sao và 25.000 fork, với lần push cuối diễn ra hai ngày trước khi chúng tôi ghi hình. Dự án đã ở phiên bản lớn thứ sáu với 681 commit trên nhánh main, nên đây không phải một bộ prompt bị ai đó bỏ rơi sau đợt ra mắt.

Chỉ số	Giá trị
Sao GitHub	280.000
Fork	25.000
Phiên bản lớn	6
Commit trên main	681
Issue đang mở	125

Ý tưởng của Vincent gói gọn trong một câu: thứ các coding agent còn thiếu không phải năng lực, mà là kỷ luật. Kỷ luật đó được đóng gói thành các file markdown thuần mà ai cũng có thể đọc, fork và chỉnh sửa. Chúng tôi đã cài plugin, đọc từng dòng của cả mười bốn skill, và xem nó thay đổi gì trên bốn mặt: năng suất, độ tin cậy của code, chi phí token và tài liệu.

Superpowers là một plugin mã nguồn mở, miễn phí cho Claude Code. Nó nằm trên marketplace plugin chính thức của Anthropic và cài chỉ bằng một lệnh. Cùng phương pháp này tồn tại cho hơn một chục harness khác, gồm Cursor, Codex và Gemini, mỗi cái có cách cài riêng.

Cốt lõi là mười bốn skill: các file hướng dẫn markdown mà agent nạp vào mỗi khi gặp tình huống phù hợp. Brainstorming, viết plan, phát triển bằng subagent, test-driven development và debug có hệ thống, mỗi skill mã hóa một cách làm việc hoàn chỉnh, với checklist và rào chắn riêng. Skill debug cấm đề xuất cách sửa trước khi xác định được nguyên nhân gốc. Một skill xác minh buộc agent phải chứng minh việc đã xong thay vì chỉ tuyên bố là xong. Mỗi skill tự thông báo khi được nạp, nên bạn luôn biết agent đang làm việc ở chế độ nào.

Một hook lúc bắt đầu phiên buộc Claude kiểm tra, trước mỗi task, xem có skill nào trong số này áp dụng được không. Quy tắc được viết thẳng vào skill đầu vào: chỉ cần một phần trăm khả năng skill có liên quan, agent bắt buộc phải nạp nó. Kết quả không giống một hộp công cụ, mà giống một phương pháp phát triển được tiêm vào agent.

Vincent kể về nguồn gốc trên blog của mình. Ông xây các skill bằng cách đào 2.249 file markdown chứa bài học mà chính các agent của ông đã rút ra, rồi thử sức các bản nháp với đúng kho lưu trữ đó. Phương pháp được rút ra từ những lần agent thất bại thật, thay vì viết ra từ lý thuyết.

Brainstorming là skill mà mọi thứ đều phải đi qua. Ngay khi bạn yêu cầu một tính năng, Claude nạp nó và hành xử như một chuyên gia về yêu cầu trong suốt cuộc trò chuyện định hình. Cả phương pháp gói gọn trong một file dễ đọc.

File mở đầu bằng một cổng cứng: không code, không scaffolding, không skill triển khai nào cho đến khi bạn duyệt một ý định rõ ràng. Không gì được xây từ phỏng đoán, và cổng này áp dụng cho mọi task, dù trông nhỏ đến đâu. Sau đó skill xếp mỗi yêu cầu vào một trong ba đường.

Đường	Định nghĩa	Đầu ra
Spike	Một câu hỏi về tính khả thi	Một câu trả lời, không phải code để giữ lại
Bounded	Một thay đổi nhỏ trên một luồng đã có trong repo	Một thay đổi có phạm vi rõ
Architectural	Bất cứ gì tái cấu trúc cách các phần của dự án khớp với nhau	Một spec bạn duyệt, rồi một plan triển khai

Agent nói rõ cách phân loại của nó để bạn có thể ghi đè, và cái chốt này chỉ xoay một chiều: độ phức tạp ẩn phát hiện giữa task sẽ nâng cấp đường đi, không bao giờ ngược lại. File kèm một bảng dấu hiệu đỏ, những ý nghĩ như "cái này đơn giản quá, không cần thiết kế", với lời phản bác ngay bên cạnh: task đơn giản chính là nơi các giả định không được xét kỹ làm bạn tốn nhiều nhất. Ngay cả spike cũng giữ rào chắn. Bất cứ gì agent xây để trả lời câu hỏi đều được gắn nhãn dùng-rồi-bỏ, và việc giữ lại code đó trở thành một yêu cầu mới cần phân loại.

Trong cuộc đối thoại, agent đặt những câu hỏi mà một lead engineer sẽ hỏi và trình bày thiết kế theo từng phần dễ tiêu hóa. Trên pipeline của chính chúng tôi, giai đoạn này đã loại bỏ những tính năng mà chúng tôi hẳn đã xây một cách vô ích.

Skill viết plan mở đầu bằng một chỉ dẫn đặt ra giọng điệu của nó: viết plan cho một dev giỏi nhưng không biết gì về codebase của bạn và, theo đúng lời trong file, có gu đáng ngờ.

Cụ thể, công việc được cắt thành các task mà mỗi bước mất hai đến năm phút: viết test thất bại, chạy để chắc là nó thất bại, viết code tối thiểu để pass, chạy test lại, commit. Một hành động, một lần xác minh, và công việc tiến lên bằng các commit dày đặc. Đó là chu trình test-driven development, được một skill khác trong plugin ép buộc, nên mỗi task mang chu trình test riêng của nó.

Mỗi task liệt kê đúng các file cần tạo hay sửa, tới cả số dòng. Plan mở đầu bằng một header bắt buộc: mục tiêu trong một câu, kiến trúc trong hai hoặc ba câu, tech stack, link tới spec, và các ràng buộc chung của dự án được chép nguyên văn. Nếu spec bao gồm nhiều hệ thống con độc lập, skill đòi các plan riêng, một cho mỗi hệ thống con, mỗi cái tạo ra phần mềm tự test được.

Kích cỡ task là trái tim của lập luận về độ tin cậy. Task ngắn nghĩa là agent hoàn thành việc với một context window vẫn còn gần như trống. Nó không bao giờ tới khoảnh khắc phiên bị tràn, agent mất mạch và bắt đầu bịa ra những hàm không tồn tại. Không bản demo năm phút nào cho thấy vấn đề này, nhưng nó quyết định mọi thứ trên một dự án thật: chất lượng của agent ở cuối phiên không liên quan gì tới chất lượng ở prompt đầu tiên. Context ít bão hòa hơn thì về mặt cơ học ít ảo giác hơn, và code làm đúng điều plan đã nói.

Lúc thực thi, một skill chuyên dụng cô lập công việc trong một git worktree, một bản làm việc riêng của repository, nên plan chạy mà không đụng vào việc bạn đang làm bên cạnh.

Skill thực thi điều khiển phát triển qua các subagent. Nguyên tắc của nó gói trong một dòng của file: một subagent mới cho mỗi task, một review sau mỗi task, và một review tổng cho cả nhánh ở cuối. Phiên chính của bạn trở thành orchestrator. Nó không code nữa, nó điều phối. Mỗi subagent nhận đúng context mà task của nó cần và không bao giờ nhận lịch sử phiên của bạn, điều này tránh ô nhiễm context và giữ cửa sổ của bạn rảnh cho việc điều phối.

Subagent có thể đặt câu hỏi trước khi bắt đầu, rồi triển khai, test, commit và tự review việc của mình. Khi xong, orchestrator chạy một review gồm hai phần, tuân thủ spec trước và chất lượng code sau, với một ghế reviewer riêng cho mỗi task. Không gì là tùy hứng: skill kèm một prompt mẫu cho mỗi vai trò (implementer, reviewer của task, và reviewer kiểm tra lại các bản sửa) mà orchestrator điền bằng context của task.

Kết quả review	Điều gì xảy ra
Đạt	Orchestrator ghi hoàn thành vào sổ cái và đi tiếp theo plan
Không đạt, lượt 1 đến 3	Implementer ban đầu tiếp tục, vì nó đã biết code và các lựa chọn của chính nó
Không đạt, lượt 4	Một implementer mới được cử đi trên một model mạnh hơn
Không đạt, lượt 5	Cầu dao ngắt và orchestrator tự phán quyết mọi vấn đề còn mở

Skill cũng tránh sự thái quá ngược lại: một loạt task cơ học nhỏ được gửi đi thành một nhóm, review như một đơn vị duy nhất. Không gì được merge mà chưa qua một reviewer. Kết quả là cái mà một đội người thật gọi là quy trình code review, chỉ khác là nó tự chạy, hết task này đến task khác.

Hệ điều phối mở cửa cho lợi ích thứ ba: kinh tế token. Skill có một mục chọn model mở đầu bằng một quy tắc: dùng model yếu nhất có thể xử lý được mỗi vai trò. Orchestrator đánh giá độ khó của từng task trong plan và gán model tương ứng.

Task	Bậc model
Task cơ học được mô tả rõ, chạm một hai file, hoặc một plan đã chứa sẵn code cần viết	Bậc rẻ nhất (triển khai trở thành chép lại cộng test)
Phối hợp trên nhiều file, debug	Một model tiêu chuẩn
Kiến trúc, review cuối cùng của nhánh	Model mạnh nhất hiện có

File thêm hai điểm tinh tế. Một, luôn nêu tên model rõ ràng khi cử đi: một subagent không có tên model sẽ kế thừa model của phiên bạn, thường là cái đắt nhất, âm thầm phá hỏng cả mục này. Hai, số lượt quan trọng hơn giá token. Các model rẻ nhất tốn nhiều lượt hơn trên công việc có nhiều bước và cuối cùng tốn hơn về tổng thể, vì thế reviewer và implementer làm việc từ văn xuôi được một sàn cao hơn một bậc thay vì hàng giá rẻ.

Setup này biến một điều ngược đời thành khả thi: chạy Opus hay Fable, những model đắt nhất trong danh mục, trên gói Pro 20 đô. Model đắt chỉ làm việc trên vài quyết định xứng đáng với nó, còn phần còn lại của plan chạy trên những model chỉ tiêu một phần nhỏ quota của bạn.

Lợi ích cuối là thứ không ai nghĩ tới khi cài plugin. Spec và plan không phải tin nhắn chat biến mất khi phiên kết thúc. Chúng là file markdown được lưu trong repository và commit cùng với công việc. Skill cố định cả vị trí: một thư mục plans có ngày tháng, một file mỗi tính năng, với mục tiêu, kiến trúc và link tới spec trong header.

Spec đi cùng plan, và xung đột giữa hai cái được giải quyết theo spec: tài liệu là thẩm quyền, không phải bộ nhớ của agent. Lịch sử git không còn chỉ cho bạn biết cái gì đã thay đổi. Nó cho biết tại sao, và agent đã quyết định gì vào lúc đó. Sáu tháng sau, nhắc tới file plan trong một prompt cho phép agent nhặt lại ngay context của tính năng ban đầu, và một tính năng mới chạm cùng hệ thống con sẽ xây trên spec sẵn có thay vì khám phá lại địa hình.

Không còn cái gọi là task không được truy vết: mọi thứ một agent làm trên codebase đều để lại một tài liệu, từ lần brainstorm đầu tới commit cuối. Dự án tóm triết lý của mình trong hai nguyên tắc, có hệ thống thay vì tùy tiện và bằng chứng thay vì lời nói. Tài liệu tự rơi ra từ quy trình.

Giới hạn là có thật và repository không quảng cáo nó: toàn bộ kỷ luật này có một chi phí cố định, và chi phí đó không bao giờ tắt. Skill đầu vào nói thẳng. Chỉ cần chút nghi ngờ, agent phải nạp skill, và file brainstorming nói rõ rằng nghi thức tăng theo cỡ task nhưng bước duyệt của con người thì không bao giờ.

Với một bản sửa hai dòng, điều đó nghĩa là trả lời các câu hỏi định hình, duyệt một thiết kế dài hai câu, rồi chờ trọn chu trình trước khi thấy bản sửa. Với một lỗi chính tả trong file config, cả quy trình đơn giản là chậm hơn tự sửa. Bản thân việc điều phối cũng tiêu token: brief điều phối, hai review mỗi task và sổ cái được trả mỗi lần một, và bạn cảm nhận rõ nhất trên những task nhỏ nhất.

Còn có triệu chứng ngược lại, và nó trả lời thẳng câu hỏi trên Reddit. Nếu thống kê sử dụng cho thấy plugin chỉ chiếm vài phần trăm, yêu cầu của bạn gần như không bao giờ kích hoạt skill, nên bạn trả phí kiểm tra đầu vào mỗi phiên mà chẳng bao giờ chạm tới lợi ích. Một vòng sửa đi hết năm lượt là năm diff, năm review nữa và một phán quyết, cho một task vốn chỉ nên mất vài phút. Dự án cũng không bao giờ đứng yên: nó đi từ phiên bản một lên phiên bản sáu trong chưa đầy một năm và vẫn còn 125 issue mở, nên các skill bạn đọc hôm nay sẽ đổi ở bản cập nhật sau.

Plugin tự lên kế hoạch lối ra cho mình. Chỉ dẫn của nó đặt chỉ thị của bạn trên các skill, nên bạn có thể bảo agent, một cách rõ ràng, bỏ qua quy trình. Quy tắc của chúng tôi: Superpowers bật mặc định cho mọi việc làm tính năng, và chủ động bỏ qua với các bản sửa nhỏ.

Cách bạn dùng Claude Code	Kết luận
Tính năng mất hàng giờ	Cài đi: bước định hình giúp bạn không triển khai sai thứ, task ngắn giữ agent xa khỏi bão hòa context, chọn model kéo dài quota của bạn, và bạn thừa hưởng tài liệu mà mình sẽ chẳng bao giờ tự viết
Script dùng-rồi-bỏ và sửa nhỏ	Cứ đi tiếp: bạn sẽ trả chi phí cố định của quy trình cho những task không cần nó
Ở giữa	Cài và học cách nói skip: một câu trong prompt của bạn trao quyền kiểm soát trở lại tay bạn

Nếu bạn muốn thử mà không cần áp dụng tất cả, chỉ để skill brainstorming chạy vài ngày. Nó mang phần lớn lợi ích, và các skill khác tự nhiên ghép vào sau đó. Plugin giữ đúng bốn lời hứa của nó miễn là bạn đưa cho nó những tính năng xứng với nghi thức của nó. Giờ nó chạy trên các dự án của chính chúng tôi, và giai đoạn brainstorming là thứ chúng tôi sẽ không tắt nữa. Repository miễn phí và mã nguồn mở, với 280.000 người xếp hàng trước bạn.