很多技能包只是「一袋工具」——需要時才拿出來用，平時擺著。Superpowers 不是。它的核心主張是：這 14 個技能接成一條完整的開發工作流，從「你冒出一個想法」一路到「程式碼合併上線」。
而且關鍵在於：流程是自動觸發的。開場指令（using-superpowers）讓 agent 在「任何回應之前」先檢查有沒有技能適用——這不是建議，是強制。所以你不必記得去呼叫技能，agent 會在你動手之前先把你推到正確的流程上。
| 階段 | 技能 | 做什麼 |
|---|---|---|
| 0. 開場 | using-superpowers | 每個 session 啟動時注入：先檢查技能，再行動 |
| 1. 腦力激盪 | brainstorming | 動工前把點子敲成設計——agent 反問你，直到設計明確 |
| 2. 開 worktree | using-git-worktrees | 建立隔離工作區，主分支不受干擾 |
| 3. 寫計畫 | writing-plans | 把設計拆成 2–5 分鐘的小任務，每個都標檔案與驗證方式 |
| 4. 執行 | subagent-driven-development / executing-plans | 逐任務派子代理實作，兩階段審查（規格 → 品質） |
| 5. 測試 | test-driven-development | 實作過程強制 RED-GREEN-REFACTOR |
| 6. 審查 | requesting / receiving-code-review | 任務之間與收尾前送審，按嚴重度回報 |
| 7. 收尾 | finishing-a-development-branch | 全綠之後，決定合併／發 PR／保留／丟棄 |
另有兩個「遇到問題隨時進來」的支線：systematic-debugging（出 bug 時）與 verification-before-completion（宣告完成前），以及一個 meta 技能 writing-skills（怎麼寫新技能）。
不用你記指令。開場指令強制 agent 在回應前檢查技能適用性。這解決了「技能裝了但永遠沒被用」的通病。
每個任務派「全新的子代理」實作，一次只做一件事，做完立刻兩階段審查。子代理沒有你對話的上下文，反而迫使它照計畫行事、產出可驗證的結果。
「測過了」「應該可以」都不算數。TDD 要求親眼看測試紅、再親眼看它綠；verification-before-completion 要求真的跑指令、貼出輸出。用證據取代宣稱。
Superpowers 把 TDD 當成鐵律：沒有先寫失敗的測試，就不准有正式程式碼。原因很務實——你沒看過測試失敗，你就不知道它測的是不是對的東西。事後補的測試永遠會通過，卻證明不了任何事。這條鐵律貫穿整個流程，寫技能、修 bug、做功能都一樣。
GSD、BMAD、Spec-Kit 這類做法「接管流程」——它們拿走你的控制權，讓流程本身的 bug 難以解決。Superpowers 反過來：技能小、容易改、可組合，agent 只是照著技能指示行動，你隨時保有控制權。這跟 mattpocock/skills 的設計哲學一致：給真人工程師掌控，而不是讓流程凌駕於你之上。