Superpowers 讓 Claude Code 更守紀律，但代價只有一個

Superpowers 是 Jesse Vincent 為 Claude Code 寫的 plugin，他從 1990 年代起就一直在推出開源開發者工具。他在十月發布這個專案，不到一年，repo 已經累積 280,000 顆星和 25,000 個 fork，最近一次 push 就落在我們錄影前兩天。專案已經來到第六個主要版本，主分支上有 681 個 commit，所以這不是那種發布熱潮過後就被丟掉的 prompt 合集。

指標	數值
GitHub 星數	280,000
Fork 數	25,000
主要版本	6
主分支 commit 數	681
未關閉的 issue	125

Vincent 的賭注一句話就能說完：coding agent 缺的不是能力，而是紀律。這份紀律以純 markdown 檔案的形式交付，任何人都能讀、fork 和修改。我們安裝了這個 plugin，把全部十四個 skill 一行一行讀完，並從四個面向檢視它到底改變了什麼：生產力、程式碼可靠性、token 消耗，以及文件。

Superpowers 是 Claude Code 的免費開源 plugin。它放在 Anthropic 官方的 plugin marketplace 上，安裝只需要一個指令。同樣的方法論也有十幾個其他 harness 的版本，包括 Cursor、Codex 和 Gemini，各有自己的安裝方式。

核心是十四個 skill：也就是 markdown 指令檔，agent 在情境符合時就會載入它們。腦力激盪、撰寫計畫、subagent 驅動開發、測試驅動開發和系統化除錯，每一個都編入了一套完整的工作方式，附帶自己的檢查清單和護欄。除錯的 skill 禁止在找出根本原因之前提出修法。驗證的 skill 要求 agent 證明工作真的完成了，而不是嘴上說完成。每個 skill 載入時都會自我宣告，所以你永遠知道 agent 目前在哪個模式下工作。

session 開始時的一個 hook 強制 Claude 在每個任務之前先檢查是否有這些 skill 適用。這條規則直接寫在入口 skill 裡：只要有百分之一的機率某個 skill 相關，agent 就必須載入它。結果就是，這東西不太像工具箱，更像是注入 agent 裡的一套開發方法論。

Vincent 在部落格上描述了它的起源。他從 2,249 個 markdown 檔案裡挖出這些 skill，那些是他自己的 agent 學到的教訓，再拿草稿回去對著同一批檔案做壓力測試。這套方法論是從真實的 agent 失敗中提煉出來的，不是從理論寫出來的。

腦力激盪是一切都要經過的 skill。你一提出功能需求，Claude 就載入它，在整段框定對話裡扮演需求分析專家。整套方法裝在一個易讀的檔案裡。

檔案一開頭就是一道硬性閘門：不寫程式碼、不搭骨架、不載入任何實作類 skill，直到你批准一個明確的意圖。沒有東西是憑直覺就開建的，而且這道閘門適用於每個任務，不管看起來多小。接著這個 skill 把每個需求分到三條路徑之一。

路徑	定義	產出
Spike	一個可行性問題	一個答案，不是要保留的程式碼
Bounded	對 repo 裡既有流程的小改動	一個範圍明確的改動
Architectural	任何會重新調整專案整體結構的東西	一份你要驗證的 spec，接著是一份實作計畫

agent 會把分類明講出來，讓你可以推翻它，而且這個棘輪只往一個方向轉：任務中途發現的隱藏複雜度會把路徑往上升級，絕不會往下降。檔案附了一張警訊表，列出像「這太簡單了，不需要設計」這類想法，旁邊就放著反駁：簡單任務正是未經檢驗的假設最傷你的地方。就算是 spike 也保有護欄。agent 為了回答問題而做的東西一律標記為丟棄用，想保留那段程式碼，就得當成新需求重新分類。

在這段對話裡，agent 會問出資深工程師會問的問題，並把設計拆成好消化的段落呈現。在我們自己的 pipeline 上，這個階段已經砍掉了幾個我們本來會白做的功能。

撰寫計畫的 skill 開場指令就定下了調子：為一位對你的程式庫零背景的熟練開發者寫計畫，而且用檔案自己的話說，這個人「品味可疑」。

具體來說，工作會被切成任務，每一步都只需要兩到五分鐘：寫一個會失敗的測試，跑一次確認它真的失敗，寫最少的程式碼讓它通過，再跑一次測試，commit。一個動作、一次驗證，然後工作靠頻繁的 commit 往前推。這就是測試驅動開發的循環，由 plugin 裡另一個 skill 強制執行，所以每個任務都帶著自己的測試循環。

每個任務會列出要建立或修改的確切檔案，精確到行號。整份計畫以一個必填的開頭起手：一句話說目標，兩三句說架構，技術堆疊，spec 的連結，還有專案的全域限制，逐字複製過來。如果 spec 涵蓋好幾個獨立的子系統，這個 skill 會要求分開的計畫，每個子系統一份，各自產出可以獨立測試的軟體。

任務切分正是可靠性論點的核心。任務短，代表 agent 做完工作時，它的 context window 大部分還是空的。它永遠不會走到 session 爆掉、agent 失去脈絡、開始編出不存在的函式的那一刻。五分鐘的 demo 從來不會出現這個問題，但在真實專案上它決定一切：agent 在 session 尾聲的品質，和它在第一個 prompt 時的品質完全是兩回事。context 越不飽和，幻覺在機制上就越少，程式碼也就真的照計畫寫的去做。

到了執行階段，一個專門的 skill 把工作隔離在 git worktree 裡，也就是 repo 的另一份獨立工作副本，讓計畫跑起來不會干擾你旁邊正在做的事。

執行的 skill 透過 subagent 推動開發。它的原則在檔案裡一行就寫完：每個任務一個全新的 subagent，每個任務結束後一次審查，最後再對整條分支做一次全面審查。你的主 session 變成協調者。它不再寫程式碼，它負責派工。每個 subagent 只拿到任務需要的上下文，絕不會拿到你的 session 歷史，這避免了 context 污染，也讓你自己的視窗保持乾淨給協調工作用。

subagent 開始前可以先提問，然後實作、測試、commit，並審查自己的成果。做完後，協調者進行分成兩部分的審查，先看是否符合 spec，再看程式碼品質，每個任務都有專屬的審查者席位。這裡沒有任何東西是即興的：這個 skill 為每個角色（實作者、任務審查者，以及複查修正的審查者）都附上 prompt 範本，由協調者填入任務的上下文。

審查結果	後續動作
通過	協調者在帳本裡記下完成，然後繼續往計畫下方走
未通過，第 1 到 3 輪	原本的實作者接著做，因為它已經熟悉程式碼和自己的取捨
未通過，第 4 輪	改派一個全新的實作者，使用更強的模型
未通過，第 5 輪	斷路器跳脫，協調者親自裁決每一項未解的問題

這個 skill 也避免了相反的過度：一批細小的機械性任務會合成一組派出去，當成一個單位審查。沒有東西能不經審查者就合併。你得到的，就是人類團隊所謂的 code review 流程，只是它自己跑，一個任務接一個。

這套派工系統打開了第三個收穫：token 經濟學。這個 skill 有一節模型選擇，開頭就是一條規則：每個角色都用能勝任的最弱模型。協調者評估計畫裡每個任務的難度，然後指派對應的模型。

任務	模型等級
規格明確、只碰一兩個檔案的機械性任務，或計畫裡已經寫好要寫的程式碼	最便宜的等級（實作變成抄寫加測試）
跨多個檔案的協調、除錯	標準模型
架構、最後的分支審查	能拿到的最強模型

檔案還多了兩個細節。第一，派工時一定要明確指定模型：沒指定模型的 subagent 會繼承你 session 的模型，通常是最貴的那個，整節設定就這樣悄悄失效。第二，輪數比 token 單價重要。最便宜的模型在多步驟的工作上要花更多輪，到最後整體反而更貴，所以審查者和依照文字說明工作的實作者，底線會往上調一級，而不是用最廉價的那一檔。

這套配置讓一件反直覺的事變得可行：用 20 美元的 Pro plan 跑 Opus 或 Fable，也就是目錄裡最貴的模型。貴的模型只處理少數值得它出手的決策，計畫的其餘部分交給只吃你一小部分額度的模型。

最後一個收穫，是大家安裝 plugin 時都不會想到的那個。spec 和計畫不是 session 結束就消失的聊天訊息。它們是 markdown 檔案，存在 repo 裡，和工作成果一起 commit。這個 skill 連存放位置都規定好了：一個依日期命名的 plans 資料夾，每個功能一個檔案，開頭有目標、架構，以及 spec 的連結。

spec 跟著計畫走，兩者有衝突時以 spec 為準：文件才是權威，不是 agent 的記憶。git 歷史不再只告訴你改了什麼。它告訴你為什麼，以及 agent 當時做了什麼決定。六個月後，在 prompt 裡提到那份計畫檔，agent 就能直接接回原功能的上下文，而碰到同一個子系統的新功能會建立在既有的 spec 上，而不是重新摸索地形。

再也沒有「沒留下紀錄的任務」這種事：agent 在你的程式庫上做的每件事都留下了一份文件，從第一次腦力激盪到最後一個 commit。這個專案用兩條原則總結它的哲學：系統化勝過臨時起意，證據勝過口頭宣稱。文件會從流程裡自己長出來。

限制是真的，而 repo 不會主動宣傳：這一切的紀律都有固定成本，而且這個成本永遠不會關掉。入口 skill 說得很直白。只要有一點懷疑，agent 就必須載入 skill，而腦力激盪的檔案也明講，儀式會隨任務規模伸縮，但人工批准這一步永遠不會省。

對一個兩行的修正來說，這代表要回答框定問題、批准一份兩句話的設計，然後等完整個循環才看得到修正。為了設定檔裡的一個錯字，走完整套流程就是比自己動手改慢。協調本身也在消耗 token：派工簡報、每個任務兩次審查，還有帳本，這些每次都要付，而在最小的任務上你感受得最明顯。

還有一個相反的症狀，它直接回答了 Reddit 上的那個問題。如果你的使用統計顯示這個 plugin 只佔幾個百分點，表示你的需求幾乎從來沒觸發過這些 skill，所以你每個 session 都付了入口檢查，卻從沒碰到好處。一個跑滿五輪的修正迴圈，就是五份 diff、五次額外審查，再加一次裁決，只為了一個本來幾分鐘就該完成的任務。這個專案也從不停下來：它在不到一年內從第一版走到第六版，還有 125 個未關閉的 issue，所以你今天讀到的 skill 到下次更新就會變了。

這個 plugin 也規劃了自己的退出方式。它的指令把你的指示放在 skill 之上，所以你可以明確告訴 agent 跳過流程。我們的規則：任何功能開發都預設開著 Superpowers，小修正則刻意跳過。

你使用 Claude Code 的方式	結論
要花好幾個小時的功能	裝：框定讓你不會實作錯的東西，短任務讓 agent 遠離 context 飽和，模型選擇拉長你的額度，你還白拿一份自己永遠不會寫的文件
丟棄式腳本和小修正	略過：你會在不需要的任務上付流程的固定成本
介於兩者之間	裝，並學會說跳過：prompt 裡一句話就把控制權交回你手上

如果你想先試用而不全盤採用，可以先只讓腦力激盪的 skill 跑幾天。它承載了大部分的收穫，其他 skill 之後會自然接上。只要你餵給這個 plugin 的功能配得上它的儀式，它就守得住四個承諾。它現在跑在我們自己的專案上，而腦力激盪階段是我們再也不會關掉的那一個。repo 免費且開源，前面已經有 28 萬人排隊了。