Superpowers 實測分析：從小遊戲案例看其 14 個 Skills 如何協同

好多人接觸 coding agent 嘅時候，有時都會有種錯覺：模型已經好強，點解佢一去到真實嘅工程入面，成日都仲會行錯路？

佢可以好快寫出函數，又可以補幾段 code，甚至砌得出一個頁面。

但係一旦個任務有少少複雜，問題就會集中出現：需求都未講清楚，佢就開始狂寫；bug 嘅根因都未揾到，佢就開始修；測試都未跑，佢就話已經完成咗。

（先唔講質素點樣，你就話快唔快啦...）

呢類問題，表面睇好似係模型唔得，實際上好多時未必係能力問題，而可能係流程問題。

今日要分享嘅係一個13.8萬 Star 嘅項目superpowers，最近我認真研究咗一次 superpowers 呢個倉庫，發現佢最有癮嘅地方唔係發明咗一套 prompt，而係佢想畀 coding agent 加返一層工程流程約束。

佢要解決嘅唔係點樣令 agent 寫多啲 code 或者寫得快啲，而係點樣令 agent 少做啲會令工程失控嘅動作。

我用一句話概括嚇：

Superpowers 唔係提示詞集合，而係一套將設計、計劃、實現、審查、驗證同收尾串成閉環嘅 AI 編碼工作流

一、 code 寫得好快但係冇約束

coding agent 最常見嘅默認傾向，係收到任務之後即刻行動。

呢個喺簡單任務入面睇落好高效，但係喺真實項目入面成日會變成問題。

因為工程工作並唔係將 code 快快打出來咁簡單。佢需要一套順序：

先釐清問題，再確定範圍；

先設計，再實施；

先驗證，再聲稱完成；

先收尾，再進入下一個階段。

而 agent 就偏偏容易喺呢啲地方失控。

比如在 superpowers 呢個倉庫入面，using-superpowers 明確強調一條規則：

如果哪怕得1% 嘅概率某個 skill 適用，都一定要先 call skill，再開始行動。

呢個其實係對抗 agent 嘅一種天然傾向：“快啲畀我做啲嘢先講”。

類似嘅約束喺呢個倉庫入面成日出現：

• brainstorming 強調，喺任何創作型或者實現型任務入面，都唔可以跳過設計確認直接進入實現
• systematic-debugging 強調，唔容許冇根因分析就直接修 bug
• verification-before-completion 強調，冇新鮮嘅驗證證據，就唔可以話完成
• test-driven-development 強調，如果先寫咗 code 再補測試，要刪咗重新嚟過

將呢啲約束連埋一齊睇，你會發現 Superpowers 嘅設計意圖非常明確：

佢唔係增強 agent 嘅創造力，而係約束 agent 嘅衝動。

呢件事非常重要，因為喺 AI 輔助研發入面，最貴嘅成本往往唔係模型寫唔出，而係模型好快寫咗出嚟，但係條路錯咗，效果唔達預期。返工、誤判、錯誤完成聲明、無效修復，呢啲先至最傷協作效率。

二、咩嘢係 Superpowers

從項目官方嘅 README.md 嚟睇，Superpowers 嘅定義非常直接：佢係一套完整嘅軟件開發工作流，建立喺一組可組合嘅 skills 同一段確保 agent 會用呢啲 skills 嘅初始指令之上。

呢個定義有兩個關鍵詞好關鍵。

第一個係 workflow。

佢唔係一個 library，唔係一個 SDK，亦都唔係一個畀你導出若干 API 嘅運行時框架。呢個倉庫嘅主體都證明到呢點：你會見到大量 skills/、commands/、hooks/ 和 docs/。

第二個係 skills。

呢度嘅 skill 係行為約束同流程指導單元。每個 SKILL.md 都包含觸發條件、執行原則、紅線、流程圖同常見反模式，佢哋就係用嚟塑造 agent 行為嘅。

從呢個倉庫嚟睇，skills/ 目錄下共有 14 個核心 skill：

如果一定要畀佢一個更好理解嘅比喻，我會話：Superpowers 更加似畀 coding agent 裝咗一層流程操作系統。

普通 prompt 係話畀 agent 做啲乜，而 Superpowers 係規定 agent 一定要跟邊個順序做。

三、Superpowers 嘅整體架構

如果將呢個項目當做一個系統嚟睇，佢大致可以拆成四層

第一層係平台接入層。README 入面已經清楚寫咗支援嘅入口形態，包括 Codex、Claude Code、Gemini CLI、Cursor、Copilot CLI 等。即係話 Superpowers 唔係綁死單一產品，而係想做到一套跨 agent 運行環境嘅工作流插件。

第二層係入口與路由層。呢度嘅核心就係 using-superpowers。佢唔係又一個 skill，而更加似一個總調度器。佢定義咗最重要嘅一條上層規則：收到任務之後，先判斷有冇 skill 適用；有嘅話，就一定要用 skill。

第三層係主工作流層。呢層負責將一個任務由模糊需求一路帶到分支收尾。核心鏈路大致係：

brainstorming -> writing-plans -> using-git-worktrees -> subagent-driven-development / executing-plans -> finishing-a-development-branch

第四層係質量與糾偏層。呢層唔會單獨完成一個功能，但佢會喺關鍵節點不斷打斷、校驗同糾偏，包括：

• test-driven-development
• systematic-debugging
• requesting-code-review
• receiving-code-review
• verification-before-completion

呢張圖最重要嘅閲讀方式，唔係由左到右背 skill 名，而係可以睇到：Superpowers 嘅核心唔係 skill 數量，而係分層組織。

翻譯成白話，就係：平台只係入口，真正決定 agent 行為嘅，係中間嗰層路由規則，同埋下面嗰兩層工作流同質量約束

四、一次請求過嚟會發生啲乜

Superpowers 最有代表性嘅地方，係佢將收到請求之後到底應該點樣做拆咗一條順序明確嘅鏈路。

第一步通常係 using-superpowers。

呢個 skill 嘅作用，唔係完成具體任務，而係阻止 agent 喺冇做 skill 判斷之前就開始行動。佢幾乎似一個“元規則”，要求所有任務都要先經過 skill 檢查。呢個係成個系統嘅入口控制器。

如果任務係創作型、功能型、需要構建或者修改行為嘅，咁下一步通常會入 brainstorming。呢個 skill 嘅核心思想係：唔好以為任務睇落簡單，就跳過設計過程。就算係一個小功能，都要先理解目標、約束同成功標準，再提出方案，再展示設計，再畀用戶確認。

設計確認之後，鏈路會入 writing-plans。呢個 skill 要求將實現計劃拆成夠細嘅步驟，細到一個“上下文好少、判斷力一般嘅工程師”都可以跟住做。佢會要求寫明文件路徑、code 片段、驗證命令同預期結果。

真正開始實施之前，仲會經過 using-git-worktrees。呢一步嘅意義係畀執行創造隔離空間，避免直接喺主工作區或者主分支上亂咁操作。

接下來先至入執行階段。呢度有兩個主分支：

• subagent-driven-development：適合喺而家呢個會話入面，用子代理逐個任務推進，並喺每個任務之後做兩階段 review
• executing-plans：適合執行已有嘅實現計劃，按任務推進並喺關鍵位停低嚟確認

最後，完成開發並唔等於完成交付。系統仲會要求入 finishing-a-development-branch，喺呢度決定係本地合併、發 PR、保留分支定係丟棄工作，並先驗證測試狀態。

佢想表達嘅重點得一個：

Superpowers 想將 agent 由“收到任務就開寫”，改造成“先定規則、再按階段推進”嘅執行者。

五、14 個 Skills 點樣分層理解

如果按檔案名平鋪介紹 14 個 skills，文章會好似說明書，唔利於理解。更好嘅方法，係按職責佢哋分層。

1. 入口與路由層

呢度得一個核心 skill：using-superpowers。

佢負責定義“所有嘢開始前先檢查 skill”呢條總規則。可以理解成系統嘅入口守門員。

2. 設計與計劃層

呢一層包含兩個 skill：

• brainstorming
• writing-plans

前者負責將模糊想法打磨成經過確認嘅設計，後者負責將設計變成可執行嘅工程計劃。一個偏設計收斂，一個偏實現拆解。

3. 執行與協作層

呢一層負責將計劃真正變成 code 同工程動作：

• using-git-worktrees
• subagent-driven-development
• executing-plans
• dispatching-parallel-agents
• finishing-a-development-branch

呢度你可以見到 Superpowers 嘅另一個特點：佢唔將“寫 code”睇成單線程過程，而係將隔離工作區、並行代理、任務審查、開發收尾都納入執行範疇。

4. 質量與糾偏層

呢一層係成個系統嘅“停車同校準系統”：

• test-driven-development
• systematic-debugging
• requesting-code-review
• receiving-code-review
• verification-before-completion
• writing-skills

嚴格嚟講，writing-skills 有少少元能力嘅意味，因為佢係用嚟擴展同構建新 skill 嘅，但係從讀者理解上，將佢放喺質量與糾偏層最適合。因為佢強調嘅仍然係：就算寫文檔型 skill，都要測試、都要壓力測試、都要驗證。

Superpowers 唔係 14 個孤立嘅小工具，而係 14 個分工明確嘅行為單元。

六、呢啲 Skills 係點樣配合

理解 Superpowers，最重要嘅唔係記住 skill 名，而係睇清楚佢哋之間嘅依賴關係。

我認為呢個倉庫入面至少存在三條主要鏈路。

第一條：主開發鏈

呢條係由“有任務”到“開發完成”嘅主路徑：

using-superpowers -> brainstorming -> writing-plans -> using-git-worktrees -> subagent-driven-development | executing-plans -> finishing-a-development-branch

呢條鏈負責將一個功能型任務由模糊狀態帶到完成狀態，係系統最核心嘅骨架。

第二條：質量保障鏈

呢條係為咗防止開發過程失控而設置嘅保障鏈：

test-driven-development -> requesting-code-review -> receiving-code-review -> verification-before-completion

佢嘅意義在於，唔畀 agent 因為“已經寫完”就自動進入“應該冇問題”嘅心理狀態。寫完唔等於通過，review 完唔等於完成，一定要有新鮮驗證證據。

第三條：問題修復鏈

呢條係面向 bug 同異常行為嘅修復鏈：

systematic-debugging -> test-driven-development -> verification-before-completion

佢解決嘅係另一類常見失控：未搞清楚根因就不斷試錯。

除此之外，仲有兩類橫向支撐關係。

第一類係 dispatching-parallel-agents。佢唔一定每次都會喺主鏈路出現，但係當任務之間彼此獨立時，佢會明顯提高並行處理能力。

第二類係 writing-skills。佢嘅作用唔係完成業務任務，而係令 Superpowers 呢套系統可以繼續擴展自己。某種意義上，呢個係一個“寫系統自身規則”嘅元技能。

以下嘅skills 依賴關係圖，你會更容易將呢啲關係放喺腦入面：有主鏈、有質量鏈、有修復鏈，仲有橫向支撐。

呢個就係點解我話佢更加似“工作流操作系統”，而唔係“skill 集合”。

七、佢同 OpenSpec 有咩分別

如果你之前瞭解過 OpenSpec，讀到呢度大概會有一個問題：佢哋唔係都係強調流程、規範同階段推進咩？分別到底喺邊？

呢個問題一定要講清楚。因為如果呢度唔展開，Superpowers 好容易會俾人誤讀成另一套流程文檔方法論。

我嘅觀點：OpenSpec 同 Superpowers 都反對冇約束就直接開寫，但佢哋切入問題嘅層級唔一樣。

OpenSpec 更加似一套規格驅動嘅方法論。佢強調將需求、設計、計劃呢啲產物先沉澱出嚟，令團隊喺實現前對做啲乜達成共識。佢嘅核心抓手比較偏文檔、規格同階段性產物。

而 Superpowers 更加似一套直接作用喺 agent 行為上嘅執行約束系統。佢唔只係要求應該先寫 spec，而係通過 using-superpowers、brainstorming、verification-before-completion 呢啲 skill 組合，直接限制 agent 喺唔同階段可以做啲乜、唔可以做啲乜。

如果用一句更直白嘅話講：

• OpenSpec 更加似係定義項目過程應該產出啲乜
• Superpowers 更加似係約束 agent 喺過程入面應該點樣行動

所以兩者嘅重點並唔相同。

OpenSpec 比較偏規格治理，Superpowers 比較偏行為治理。

OpenSpec 要解決嘅問題係：團隊喺開始做之前，係咪已經將目標、邊界、方案同計劃講清楚咗。

Superpowers 要解決嘅問題係：就算呢啲嘢未講清楚，agent 都唔可以跳過佢哋直接做落去；就算 code 已經寫咗，agent 都唔可以唔驗證就話完成；就算 bug 睇落好明顯，agent 都唔可以唔揾根因就直接修。

呢個亦都係點解我會將佢哋睇成可以疊加，而唔係互斥嘅兩種嘢。

如果你嘅團隊已經有 OpenSpec 呢類規格流程，咁 Superpowers 好適合放喺執行層，作為 agent 嘅行為護欄。

你甚至可以將佢哋理解成上下兩層：

• 上層用 OpenSpec 約束項目應該點樣被定義
• 下層用 Superpowers 約束 agent 應該點樣執行呢啲定義

所以，Superpowers 唔係 OpenSpec 嘅替代品，更準確咁講，佢更加似係 OpenSpec 呢類方法論喺 agent 執行側嘅一層強化器。

八、開發一個小遊戲案例

我揀咗一個比較經典嘅小遊戲：“彈球打磚塊”，提示詞都比較簡單，就一句需求：“幫我開發一個彈球打磚塊嘅遊戲”。

首先我揀咗唔開 superpowers 插件嚟開發

開發得好快，當然效果都幾好，總共 1 分 39 秒就搞掂

我覺得效果唔錯，起碼一次性玩得，70 分

以下係遊玩交互效果

跟住，我再開啓 Superpowers 插件，再用同樣嘅提示詞，睇嚇效果

開始首先佢開啓頭腦風暴模式，進行需求討論與分析

開啓 UI 模式，居然叫我喺線選擇交互嘅 UI 稿（有啲嚇親）

有啲犀利，然後可以進行 UI 交互方案選擇

接下來進行產品佈局設計同功能，UI 設計稿直接出，可以提前見到成品 UI 稿同功能列表

仲有道具規則，遊戲規則設計得相當全面

最後每個任務完成之後，有相關狀態進行功能驗證

以下係交付結果，效果相當唔錯而且可以直接玩

透過下面嘅動圖感受嚇，提升至少兩個層次（有道具、有關卡、有生命），互動感提升好明顯

直觀睇對比，產品交付效果提升得非常明顯。

九、Superpowers 使用場景

如果讀到呢度，一個自然嘅問題就係：既然呢套系統咁強調流程，咁係咪所有任務都應該用佢？

答案啱啱相反。

Superpowers 並唔係要將所有對話都變成重型工程流程。佢真正適合嘅係嗰啲有階段、有協作、有驗證要求嘅任務。

例如下面呢啲場景，就好適合：

• 你做緊一個需求仲未夠清晰嘅新功能
• 你需要實現一組多步驟、多檔案、多階段嘅改動
• 你希望 agent 唔係“幫你打一段 code”，而係“按過程推進一個任務”
• 你要喺多個子任務之間做並行協作
• 你對“最後係咪真係完成”呢件事有明確驗證要求

但如果只係下面呢啲任務，Superpowers 就唔一定係最佳選擇：

• 一次性問答
• 輕量信息查詢
• 唔涉及設計、實現、驗證、收尾嘅小任務
• 你已經非常確定做法、只係想令 agent 幫你補一段局部 code
• 你處於探索初期，只想快啲試錯，唔想引入完整流程負擔

換句話講，如果任務本身唔需要“階段化協作”，Superpowers 嘅價值就會下降。

呢一點一定要講清楚，因為佢亦都係呢套系統最明顯嘅代價來源。

佢嘅第一個缺點，係流程偏重。

你會明顯感覺到，任務開始前嘅釐清、設計、計劃、拆解、驗證都更加嚴格。對複雜任務嚟講，呢個係收益；對簡單任務嚟講，呢個可能係額外摩擦。

第二個缺點，係對平台能力有依賴。

呢個倉庫嘅設計明顯依賴 skill discovery、hook、甚至 subagent 呢啲能力。平台能力越強，Superpowers 嘅效果越完整；平台支援越弱，佢嘅好多優勢就發揮唔出嚟。

第三個缺點，係佢要求使用者接受“先慢啲”。

呢套系統嘅核心邏輯係：前期多啲約束，後期少啲返工。但如果你嘅當下目標就係“快啲試一個諗法”，咁佢唔一定符合你嘅節奏。

所以更準確嘅結論唔係“Superpowers 值唔值得用”，而係：

你嘅任務值唔值得流程化。

佢嘅價值在於提醒讀者：Superpowers 唔係默認全開，而係應該喺值得流程化嘅時候啓用。

呢點好關鍵。因為一個真正成熟嘅工作流系統，唔係將所有嘢都複雜化，而係知道幾時應該上流程，幾時唔應該。

十、點樣接入你嘅 Coding Agent

Claude Code 官方插件市場

Superpowers 插件已經喺 Claude 官方插件市場上線。

安裝方式（Claude 官方市場）

直接執行：

/plugin install superpowers@claude-plugins-official

Claude Code（透過自訂插件市場）

喺 Claude Code 入面，要先註冊插件市場：

1. 加市場

/plugin marketplace add obra/superpowers-marketplace

2. 安裝插件

/plugin install superpowers@superpowers-marketplace

Codex

對 Codex 輸入以下指令：

Fetch and follow instructions from:
https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md

Gemini CLI

安裝插件

gemini extensions install https://github.com/obra/superpowers

Cursor（透過插件市場）

喺 Cursor 嘅 Agent 聊天中執行：

/add-plugin superpowers

或者喺插件市場入面搜尋 “superpowers” 並安裝。

OpenCode

對 OpenCode 輸入以下指令：

Fetch and follow instructions from:
https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md

最後：佢最重要嘅係佢嘅系統觀

所以如果你已經用緊 Codex、Claude Code 或者 Gemini CLI，我覺得 Superpowers 畀你嘅最大收益唔係裝一個插件試嚇，而係可以收穫：普通 prompt 係話畀 agent 做啲乜，Superpowers 係規定 agent 一定要跟邊個順序做。

而呢件事，正正係 AI 編碼由用得走向可協作、可驗證、可交付時，最缺嘅一層嘢。

總結嚇，Superpowers 解決嘅唔係 code 生成問題，而係工程行為失控問題。

嚟啦，快啲安裝試嚇啦~  

下期分析 OpenSpec 原理與實踐案例

很多人接觸 coding agent 時，有時都會有一種錯覺：模型已經很強了，為什麼它一到真實工程裏，還是經常會跑偏？

它能很快寫出函數，也能補幾段代碼，甚至能把一個頁面搭出來。

但一旦任務稍微變複雜，問題就會集中出現：需求還沒講清楚，它先開始一頓寫；bug 的根因還沒找到，它先開始修；測試還沒跑，它先說已經完成了有沒有。

（先不說質量怎麼，你就說快不快吧...）

這類問題，表面上看像模型不行，實際上很多時候不一定能力問題，而可能是流程問題。

今天要分享的是一個13.8萬Star的項目superpowers，最近我認真研究了一遍 superpowers 當前倉庫，發現它最有意思的地方不是發明了一套 prompt，而在於它試圖給 coding agent 加上一層工程流程約束。

它要解決的不是怎麼讓 agent 多寫一點代碼或者寫得更快，而是怎麼讓 agent 少做那些會讓工程失控的動作。

我用一句話概括一下：

Superpowers 不是提示詞集合，而是一套把設計、計劃、實現、審查、驗證和收尾 串成閉環的 AI 編碼工作流

一、 代碼寫得飛快但缺少約束

coding agent 最常見的默認傾向，是收到任務後立刻行動。

這在簡單任務裏看起來很高效，但在真實項目裏經常會變成問題。

因為工程工作並不是把代碼儘快打出來這麼簡單。它需要一套順序：

先澄清問題，再確定範圍；

先設計，再實施；

先驗證，再宣稱完成；

先收尾，再進入下一個階段。

而 agent 恰恰容易在這些地方失控。

比如在 superpowers 當前倉庫裏，using-superpowers 明確強調一條規則：

如果哪怕只有 1% 的概率某個 skill 適用，也必須先調用 skill，再開始行動。

這其實是在對抗 agent 的一種天然傾向: “快讓我先做點什麼再說”。

類似的約束在這個倉庫裏反覆出現：

• brainstorming 強調，在任何創作型或實現型任務中，都不能跳過設計確認直接進入實現
• systematic-debugging 強調，不允許在沒有根因分析的情況下直接修 bug
• verification-before-completion 強調，沒有新鮮的驗證證據，就不能宣稱完成
• test-driven-development 強調，如果先寫了代碼再補測試，要刪掉重來

把這些約束連起來看，你會發現 Superpowers 的設計意圖非常明確：

它不是在增強 agent 的創造力，而是在約束 agent 的衝動。

這件事非常重要，因為在 AI 輔助研發裏，最貴的成本往往不是模型沒寫出來，而是模型很快寫出來了，但路徑錯了，效果不達預期。返工、誤判、錯誤完成聲明、無效修復，這些才是最傷協作效率的部分。

二、什麼是 Superpowers

從項目官方的 README.md 來看，Superpowers 的定義非常直接：它是一套完整的軟件開發工作流，建立在一組可組合的 skills 和一段確保 agent 會使用這些 skills 的初始指令之上。

這個定義有兩個關鍵詞很關鍵。

第一個是 workflow。

它不是一個庫，不是一個 SDK，也不是一個給你導出若干 API 的運行時框架。當前倉庫的主體也能證明這一點：你會看到大量 skills/、commands/、hooks/ 和 docs/。

第二個是 skills。

這裏的 skill 是行為約束和流程指導單元。每個 SKILL.md 都包含觸發條件、執行原則、紅線、流程圖和常見反模式，它們就是用來塑造 agent 行為的。

從當前倉庫來看，skills/ 目錄下共有 14 個核心 skill：

如果一定要給它一個更好理解的比喻，我會說：Superpowers 更像給 coding agent 裝上了一層流程操作系統。

普通 prompt 在告訴 agent做什麼，而 Superpowers 在規定 agent必須按什麼順序做。

三、Superpowers 的整體架構

如果把當前項目當成一個系統來看，它大致可以拆成四層

第一層是平台接入層。README 裏已經明確寫了支持的入口形態，包括 Codex、Claude Code、Gemini CLI、Cursor、Copilot CLI 等。這意味着 Superpowers 不是綁定單一產品的，而是試圖做成一套跨 agent 運行環境的工作流插件。

第二層是入口與路由層。這裏的核心就是 using-superpowers。它不是又一個 skill，而更像一個總調度器。它定義了最重要的一條上層規則：收到任務後，先判斷有沒有 skill 適用；有，就必須先用 skill。

第三層是主工作流層。這層負責把一個任務從模糊需求一路帶到分支收尾。核心鏈路大致是：

brainstorming -> writing-plans -> using-git-worktrees -> subagent-driven-development / executing-plans -> finishing-a-development-branch

第四層是質量與糾偏層。這層不會單獨完成一個功能，但它會在關鍵節點不斷打斷、校驗和糾偏，包括：

• test-driven-development
• systematic-debugging
• requesting-code-review
• receiving-code-review
• verification-before-completion

這張圖最重要的閲讀方式，不是從左到右背 skill 名字，而是可以看出：Superpowers 的核心不是 skill 數量，而是分層組織。

翻譯成白話，就是：平台只是入口，真正決定 agent 行為的，是中間那層路由規則，以及下面那兩層工作流和質量約束

四、一次請求過來會發生什麼

Superpowers 最有代表性的地方，是它把收到請求之後到底該怎麼做拆成了一條順序明確的鏈路。

第一步通常是 using-superpowers。

這個 skill 的作用，不是完成具體任務，而是阻止 agent 在沒有做 skill 判斷之前就開始行動。它幾乎像一個“元規則”，要求所有任務都先經過 skill 檢查。這是整個系統的入口控制器。

如果任務是創作型、功能型、需要構建或修改行為的，那麼下一步通常會進入 brainstorming。這個 skill 的核心思想是：不要因為任務看起來簡單，就跳過設計過程。哪怕是一個小功能，也要先理解目標、約束和成功標準，再提出方案，再展示設計，再讓用戶確認。

設計確認後，鏈路會進入 writing-plans。這個 skill 要求把實現計劃拆成足夠細的步驟，細到一個“上下文很少、判斷力一般的工程師”也能照着做。它會要求明確文件路徑、代碼片段、驗證命令和預期結果。

真正開始實施之前，還會經過 using-git-worktrees。這一步的意義在於給執行創造隔離空間，避免直接在主工作區或主分支上野蠻操作。

接下來才進入執行階段。這裏有兩個主分支：

• subagent-driven-development：適合在當前會話裏，用子代理逐任務推進，並在每個任務後做兩階段 review
• executing-plans：適合執行已有實現計劃，按任務推進並在關鍵處停下來確認

最後，完成開發並不等於完成交付。系統還會要求進入 finishing-a-development-branch，在這裏決定是本地合併、發 PR、保留分支還是丟棄工作，並先驗證測試狀態。

它想表達的重點只有一個：

Superpowers 試圖把 agent 從“收到任務就開寫”，改造成“先定規則、再按階段推進”的執行者。

五、14 個 Skills 怎麼分層理解

如果按文件名平鋪介紹 14 個 skills，文章會很像說明書，不利於理解。更好的辦法，是按職責給它們分層。

1. 入口與路由層

這裏只有一個核心 skill：using-superpowers。

它負責定義“所有事開始前先檢查 skill”這條總規則。可以把它理解成系統的入口守門員。

2. 設計與計劃層

這一層包含兩個 skill：

• brainstorming
• writing-plans

前者負責把模糊想法打磨成經過確認的設計，後者負責把設計變成可執行的工程計劃。一個偏設計收斂，一個偏實現拆解。

3. 執行與協作層

這一層負責把計劃真正變成代碼與工程動作：

• using-git-worktrees
• subagent-driven-development
• executing-plans
• dispatching-parallel-agents
• finishing-a-development-branch

這裏你能看到 Superpowers 的另一個特點：它並不把“寫代碼”看成單線程過程，而是把隔離工作區、並行代理、任務審查、開發收尾都納入執行範疇。

4. 質量與糾偏層

這一層是整個系統的“剎車和校準系統”：

• test-driven-development
• systematic-debugging
• requesting-code-review
• receiving-code-review
• verification-before-completion
• writing-skills

嚴格來說，writing-skills 有一點元能力意味，因為它是拿來擴展和構建新 skill 的，但從讀者理解上，把它放在質量與糾偏層最合適。因為它強調的仍然是：就算寫文檔型 skill，也要測試、也要壓測、也要驗證。

Superpowers 不是 14 個孤立的小工具，而是 14 個分工明確的行為單元。

六、這些 Skills 是怎麼配合

理解 Superpowers，最重要的不是記住 skill 名字，而是看清它們之間的依賴關係。

我認為當前倉庫裏至少存在三條主要鏈路。

第一條：主開發鏈

這是從“有任務”到“開發完成”的主路徑：

using-superpowers -> brainstorming -> writing-plans -> using-git-worktrees -> subagent-driven-development | executing-plans -> finishing-a-development-branch

這條鏈負責把一個功能型任務從模糊狀態帶到完成狀態，是系統最核心的骨架。

第二條：質量保障鏈

這是為了防止開發過程失控而設置的保障鏈：

test-driven-development -> requesting-code-review -> receiving-code-review -> verification-before-completion

它的意義在於，不讓 agent 因為“已經寫完了”就自動進入“應該沒問題了”的心理狀態。寫完不等於通過，review 完不等於完成，必須要有新鮮驗證證據。

第三條：問題修復鏈

這是面向 bug 和異常行為的修復鏈：

systematic-debugging -> test-driven-development -> verification-before-completion

它解決的是另一類常見失控：在沒有搞清根因時就連續試錯。

除此之外，還有兩類橫向支撐關係。

第一類是 dispatching-parallel-agents。它不一定每次都在主鏈路中出現，但當任務之間彼此獨立時，它會顯著提高並行處理能力。

第二類是 writing-skills。它的作用不是完成業務任務，而是讓 Superpowers 這套系統能夠繼續擴展自己。某種意義上，這是一個“寫系統自身規則”的元技能。

如下的skills 依賴關係圖，你會更容易把這些關係放到腦海中：有主鏈，有質量鏈，有修復鏈，還有橫向支撐。

這就是為什麼我說它更像“工作流操作系統”，而不是“skill 集合”。

七、它和 OpenSpec 有什麼區別

如果你之前瞭解過 OpenSpec，讀到這裏大概率會有一個問題：它們不是都在強調流程、規範和階段推進嗎？差別到底在哪裏？

這個問題必須講清楚。因為如果這裏不展開，Superpowers 很容易被誤讀成另一套流程文檔方法論。

我的觀點：OpenSpec 和 Superpowers 都反對無約束地直接開寫，但它們切入問題的層級並不一樣。

OpenSpec 更像是一套規格驅動的方法論。它強調把需求、設計、計劃這些產物先沉澱出來，讓團隊在實現前對要做什麼形成共識。它的核心抓手更偏文檔、規格和階段性產物。

而 Superpowers 更像是一套直接作用在 agent 行為上的執行約束系統。它不只是要求應該先寫 spec，而是通過 using-superpowers、brainstorming、verification-before-completion 這種 skill 組合，直接限制 agent 在不同階段能做什麼、不能做什麼。

如果用一句更直白的話說：

• OpenSpec 更像是在定義項目過程應該產出什麼
• Superpowers 更像是在約束 agent 在過程裏應該怎麼行動

所以兩者的重點並不相同。

OpenSpec 更偏規格治理，Superpowers 更偏行為治理。

OpenSpec 要解決的問題是：團隊在開始做之前，是否已經把目標、邊界、方案和計劃說清楚了。

Superpowers 要解決的問題是：哪怕這些東西還沒說清楚，agent 也不能跳過它們直接往下做；哪怕代碼已經寫了，agent 也不能不驗證就宣佈完成；哪怕 bug 看起來很明顯，agent 也不能不找根因就直接修。

這也是為什麼我會把它們看成可以疊加，而不是互斥的兩種東西。

如果你的團隊已經有 OpenSpec 這類規格流程，那麼 Superpowers 很適合放在執行層，作為 agent 的行為護欄。

你甚至可以把它們理解成上下兩層：

• 上層用 OpenSpec 約束項目該怎麼被定義
• 下層用 Superpowers 約束agent 該怎麼執行這些定義

所以，Superpowers 不是 OpenSpec 的替代品，更準確地說，它更像是 OpenSpec 這類方法論在 agent 執行側的一層強化器。

八、開發一個小遊戲案例

我選擇了一個比較經典的小遊戲："彈球打磚塊"，提示詞也比較簡單，就一句話需求："幫我開發一個彈球打磚塊的遊戲"。

首先我選擇不啓用superpowers插件來進行開發

開發的非常快，當然效果也還不錯，總耗時1分39秒就完成了

我覺得效果還不錯，至少一次性能玩起來，70分

如下是遊玩交互效果

接下來，我再開啓Superpowers插件，再用同樣的提示詞，看看效果

開始首先它開啓頭腦風暴模式，進行需求討論與分析

開啓UI模式，居然讓我在線選擇交互的UI稿（有點驚了）

有點強，然後可以進行UI交互方案選擇

接下來進行產品佈局設計與功能，UI設計稿直出，可以提前看到成品UI稿與功能列表

還有道具規則，遊戲規則設計的相當全面

最後每項任務完成後，有相關狀態進行功能驗證

如下是交付結果，效果相當不錯並且能直接玩

通過下面的動圖感受下，提升至少兩個檔次（有道具、有關卡、有生命），互動感提升明顯

直觀來看對比，產品交付效果提升非常的明顯。

九、Superpowers 使用場景

如果讀到這裏，一個自然的問題就是：既然這套系統這麼強調流程，那是不是所有任務都該用它？

答案恰恰相反。

Superpowers 並不是要把所有對話都變成重型工程流程。它真正適合的是那些有階段、有協作、有驗證要求的任務。

比如下面這些場景，就很適合：

• 你在做一個需求還不夠清晰的新功能
• 你需要實現一組多步驟、多文件、多階段的改動
• 你希望 agent 不是“幫你打一段代碼”，而是“按過程推進一個任務”
• 你要在多個子任務之間做並行協作
• 你對“最後是否真的完成”這件事有明確驗證要求

但如果只是下面這些任務，Superpowers 就不一定是最佳選擇：

• 一次性問答
• 輕量信息查詢
• 不涉及設計、實現、驗證、收尾的小任務
• 你已經非常確定做法、只是想讓 agent 幫你補一段局部代碼
• 你處在探索初期，只想快速試錯，不想引入完整流程負擔

換句話說，如果任務本身不需要“階段化協作”，Superpowers 的價值就會下降。

這一點必須說清楚，因為它也是這套系統最明顯的代價來源。

它的第一個缺點，是流程偏重。

你會明顯感覺到，任務開始前的澄清、設計、計劃、拆解、驗證都更嚴格了。對複雜任務來說，這是收益；對簡單任務來說，這可能就是額外摩擦。

第二個缺點，是對平台能力有依賴。

當前倉庫的設計明顯依賴 skill discovery、hook、甚至 subagent 這類能力。平台能力越強，Superpowers 的效果越完整；平台支持越弱，它的很多優勢就發揮不出來。

第三個缺點，是它要求使用者接受“先慢一點”。

這套系統的核心邏輯是：前期多一點約束，後期少一點返工。可如果你的當下目標就是“儘快試一個想法”，那它不一定符合你的節奏。

所以更準確的結論不是“Superpowers 值不值得用”，而是：

你的任務值不值得流程化。

它的價值在於提醒讀者：Superpowers 不是默認全開，而是應該在值得流程化的時候啓用。

這點很關鍵。因為一個真正成熟的工作流系統，不是把所有事情都複雜化，而是知道什麼時候該上流程，什麼時候不該。

十、如何接入你 Coding Agent

Claude Code 官方插件市場

Superpowers 插件已在 Claude 官方插件市場上線。

安裝方式（Claude 官方市場）

直接執行：

/plugin install superpowers@claude-plugins-official

Claude Code（通過自定義插件市場）

在 Claude Code 中，需要先註冊插件市場：

1. 添加市場

/plugin marketplace add obra/superpowers-marketplace

2. 安裝插件

/plugin install superpowers@superpowers-marketplace

Codex

對 Codex 輸入以下指令：

Fetch and follow instructions from:
https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md

Gemini CLI

安裝插件

gemini extensions install https://github.com/obra/superpowers

Cursor（通過插件市場）

在 Cursor 的 Agent 聊天中執行：

/add-plugin superpowers

或者在插件市場中搜索 “superpowers” 並安裝。

OpenCode

對 OpenCode 輸入以下指令：

Fetch and follow instructions from:
https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md

最後：它最重要的是它的系統觀

所以如果你已經在使用 Codex、Claude Code 或 Gemini CLI，我覺得 Superpowers 給你的最大收益不是裝一個插件試試，而是能收穫：普通 prompt 在告訴 agent 做什麼，Superpowers 在規定 agent 必須按什麼順序做。

而這件事，恰恰是 AI 編碼從能用走向可協作、可驗證、可交付時，最缺的一層東西。

總結一下，Superpowers 解決的不是代碼生成問題，而是工程行為失控問題。

來吧，趕快來安裝試一下吧~  

下期分析OpenSpec原理與實踐案例