Superpowers 是 Jesse Vincent（obra）開源的 AI 編碼代理技能框架，包含 14 個用 Markdown 寫成的可組合技能，將先測試、系統化除錯、子代理自主開發、上線前驗證整理成代理自動觸發的流程。本手冊涵蓋安裝步驟、Brainstorm→Finish 完整生命週期說明、進階密技，以及一段從模糊需求到有測試 PR 的實戰示範。
Jesse Vincent（GitHub 帳號 obra）長期研究 AI 編碼代理的協作流程，累積了紅綠 TDD、規劃步驟、自我更新記憶筆記等一套完整做法。Claude Code 推出 plugin 機制後，他將這些實踐整理成一個 plugin，即 Superpowers。GitHub 上的專案描述是：「一套真的有用的代理技能框架與軟體開發方法論」。
它的本質不是斜線指令,而是 14 個用 Markdown 寫成的可組合技能,放在 skills/ 目錄下。每個技能描述一段工作紀律:brainstorming 用蘇格拉底式提問先把需求磨清楚、test-driven-development 強制 RED-GREEN-REFACTOR、systematic-debugging 規定四階段根因分析、subagent-driven-development 讓代理派子代理連續自主工作兩小時以上。重點是:這些技能會自動觸發,不需要你下特殊指令。
框架的設計信念依官方 README 明文記載：先寫測試，永遠先寫；系統化勝過臨場發揮；複雜度削減是首要目標；用證據說話，而非宣稱完成。Superpowers 的目標不是讓代理輸出更快，而是強制代理按步驟完整走完每個階段。關鍵的程式碼審查問題會直接擋下進度，品質驗證優先於速度。
Superpowers 已經上架 Claude 官方 plugin 市集。在 Claude Code 裡直接貼這行,裝完技能就會自動生效,不需要記任何指令。
Superpowers 是跨平台框架，但不會自動同步到所有工具。使用幾個編碼代理，就需要按下面的對應指令各裝一次。
Superpowers 的技能是強制執行的工作守則：先釐清需求再寫 code、測試沒先失敗不准寫實作、沒查到根因不准修 bug、沒驗證過不准宣告完成。以下依生命週期分組列出 14 個技能；無需記名稱，代理會在對應階段自動載入。
Superpowers 的每條設計信念都有對應技能負責強制執行，而非僅作為建議。違反條件時，技能會直接阻擋後續進度。
| 設計信念 | 負責強制的技能 | 它怎麼擋你 |
|---|---|---|
| 先寫測試,永遠先寫 | test-driven-development |
測試沒先紅,不准寫實作 |
| 系統化勝過臨場發揮 | systematic-debugging |
沒查到根因,不准動手修 |
| 用證據說話,不靠宣稱 | verification-before-completion |
沒驗證過,不准說完成 |
| 先把問題想清楚 | brainstorming → writing-plans 先磨需求、出計畫,核准才開工 |
|
Superpowers 已獲 Simon Willison 於 2025 年 10 月專文介紹、Marc Nuri 稱其為「以 Markdown 出貨的 Claude Code 技能框架」，並收錄於 Claude 官方 plugin 頁面。以下技巧依官方 README 與公開部落格整理，按優先順序排列。
Superpowers 的技能自動觸發，無需記憶 brainstorming、test-driven-development 等名稱。直接描述要實作的功能，代理會在對應階段載入對應技能。
它是跨平台框架,但不會自動同步。你同時用 Claude Code 與 Cursor,就得兩邊各裝一次;少裝一邊,那個代理就沒有這套紀律。
來源 · 官方 README · 安裝段落brainstorming 採蘇格拉底式提問，在寫第一行 code 前持續反問，將需求磨清楚。這個階段多花的時間，通常省去後續整段重寫的成本。
test-driven-development 強制 RED-GREEN-REFACTOR:測試必須先失敗,才准寫實作。代理想跳步直接寫功能時,這條技能會把它拉回來。
systematic-debugging 強制執行四階段根因分析。沒有定位到真正原因之前，不允許進行任何修補操作，避免猜測式修改。
Simon Willison 觀察到的賣點:subagent-driven-development 讓代理依核准計畫連續自主工作兩小時以上,中間自動夾程式碼審查,而不是每幾分鐘就回來問你。
repo 內建 writing-skills:它本身就是「怎麼寫一個 Superpowers 技能」的技能。把你團隊重複的工作守則寫成新技能,代理就會在對的時機自動套用。
README 講得很白:貢獻請照 writing-skills 自己寫、自己用;新技能投稿一般不會被接受。想客製,做法是 fork 後在本地擴充,而不是發 PR 等合併。
以下是一段情境改寫:你只丟一句「幫我加個匯出 CSV 的功能」。看 Superpowers 怎麼不問你要哪個指令,而是自動先 brainstorm、出計畫等你核准、強制 TDD、子代理連續執行、任務間夾審查、驗證後才收尾。
receiving-code-review 在任務間攔截浮點數金額問題，修完重跑後才放行。全程輸入三句話，沒有下任何斜線指令，技能在對應階段自動觸發。關鍵節點：先釐清需求、先寫紅測試、審查攔截金額型別錯誤後擋下進度，修完重跑才放行。
這是框架定位「方法論」而非「提示詞集合」的具體表現：流程在你宣告完成之前先要求拿出驗證證據。
每個技能都是純 Markdown，放在 skills/ 目錄下，可直接讀取、修改、新增自訂紀律，不需要寫程式碼。授權為 MIT，可自由 fork。依官方 README 說明，作者通常不接受新技能 PR，因此 fork 自用是預期的客製方式。
1. 用 writing-skills 寫團隊紀律。把你們重複踩的坑(命名慣例、發布檢查、資料遷移守則)照 writing-skills 的規範寫成新技能,代理就會在對的時機自動套用。
2. fork 後在本地擴充。clone 一份到自己的維護分支,在現有技能裡追加你公司的規則;升級上游時自己處理分歧,而不是發 PR 等合併。
3. 跨平台一致化。你團隊同時用 Claude Code 與 Cursor / Gemini 時,把各平台都裝上同一版 Superpowers,讓不同代理跑同一套流程,交付品質才一致。
4. 用 worktree 開並行線。搭配 using-git-worktrees 與 dispatching-parallel-agents,把可獨立的工作拆成多條平行開發線,壓縮整體交期。
5. 讓 brainstorming 變需求關卡。把「未經 brainstorming 不准進 plan」當成團隊規矩,從源頭擋掉沒想清楚就開工的專案。
① obra/superpowers README：框架定位、安裝矩陣、設計信念的官方說明。
② Simon Willison：Superpowers（2025-10）：外部視角分析框架的實際效果。
③ skills/ 目錄：14 個技能的原始 Markdown，修改前建議先閱讀。