Superpowers 能引導 Claude Code 使用者在自己管理的 Git 儲存庫中完成較大的變更：議定設計、核准任務計畫、透過測試實作、審查各項任務並檢查最後分支。本指南依據2026年10月20日查核的 Superpowers 7.0.0 官方手冊。BIG CHANGE 閱讀了文件，但未安裝外掛，也未以此實際執行專案。

關鍵變化

  • 改變了什麼：經核准的設計與實作計畫，讓程式代理在修改儲存庫前取得明確任務與限制。
  • 為什麼重要：文件中的任務流程，將實際觀察的測試失敗及通過，搭配同一名審查者分別提出的規格符合性與品質判斷，之後再審查整個分支。
  • 需要留意：負責人仍須檢查完整 diff 與最新驗收結果，並決定分支的處理方式。代理流程即使完成，也可能保留已揭露的問題。

開始之前

在自己擁有或有權編輯的儲存庫中，選擇一項獲准的多步驟程式碼變更。它應能拆成可審查任務，並具備可測試的行為。寫下需要的行為、影響範圍、排除事項、原始驗收指令與起始 commit。開始前執行該指令及相關現有檢查。如果基準狀態已失敗，先釐清該故障；後續紅色或綠色結果都需要已知起點。

你需要 Git、完成驗證的 Claude Code 安裝、安裝外掛及建立分支或 worktree 的權限，以及足夠支援 Claude Code 和子代理的方案或 API 額度。核對組織的原始碼存取與外掛政策。啟用前檢查外掛內容、實際權限、供應商資料條款及支出控制。Anthropic 提醒，外掛 hook 與伺服器程序可能以使用者權限在工具呼叫沙箱外執行；一般工具授權提示未涵蓋所有這類程式碼。機密、相依項目、外部寫入、推送與發布都須符合實際權限。Claude Code 外掛安全文件說明了這項界線。

下文使用 Superpowers 的 subagent-driven-development 技能處理含多項任務的變更。手冊也介紹直接進行的 executing-plans 路徑，並允許小型工作採用較簡化的設計約定。實作前與負責人選定路徑，不要假設每個專案都須走完整流程。

1. 安裝外掛並核對啟用中的版本

在互動式 Claude Code 工作階段中，輸入官方市集指令：

Text
/plugin install superpowers@claude-plugins-official

Claude Code 會在安裝前開啟外掛詳細資料面板。檢查內容並選擇獲准的作用範圍。本機範圍只為你在此儲存庫啟用；專案範圍會影響協作者的儲存庫設定。閱讀安裝摘要與 Errors 分頁。遵循工作階段的啟用指示或重新啟動，再檢查 Installed 分頁，並在終端機執行 claude plugin list。記錄顯示的 Version、Scope 與 Status，確認目前工作階段可用 Superpowers 技能。市集指令不會固定本指南研究採用的 commit。如果安裝版本或技能文字不同於7.0.0，先依實際版本核對流程再繼續。安裝失敗或停用時應停止，不能視為流程已載入。Claude Code 安裝指南說明這些檢查。

2. 先核准設計，再核准計畫

向 Claude Code 提供真實變更、驗收標準、基準結果及禁止修改事項。利用 Superpowers 的 brainstorming 流程確定意圖、設計選擇與限制。針對這項多步驟變更，檢查書面設計及建構者檢查結果，解決須由負責人決定的問題，再核准完整描述。核准內容應說明要建置的行為；不能因代理繼續對話就視為批准。設計手冊允許較小工作採取簡化約定或明確選擇不使用，因此這裡是為較大任務刻意選擇完整路徑。

接著請 writing-plans 流程將設計轉為任務。審查計畫的檔案界線、介面、全域限制、測試指令與 Review Focus。每項任務應小到足以檢查，其測試應衡量約定行為。修改程式碼前，核准計畫與子代理執行方式。規劃手冊定義交接。合理的計畫不代表有權加入相依項目或修改無關檔案。

執行時，using-git-worktrees會檢查是否有合適的現有工作區，或在取得必要同意後準備隔離工作區。記錄實際分支、基準 commit 及乾淨的起始狀態。可用時採用 Claude Code 原生 worktree 支援。工作區若有無關編輯，先釐清歸屬再繼續。worktree 手冊描述檢查與建立路徑。

3. 觀察每次測試與任務審查

計畫核准後，使用 subagent-driven-development 處理可獨立審查的任務。現行手冊為任務指定實作者，再將實作及 diff 交給一名任務審查者。該審查者回傳兩項判斷：任務是否符合規格，以及實作品質是否可接受。這是同一次審查的兩個結論，不是依序執行兩個審查代理。同類型的小任務可依手冊規則合併處理。任務流程與審查者提示詞規定這個順序。

對每項適合先寫測試的行為，要求可觀察的紅綠循環：新增行為測試、執行並看到預期失敗；以最小實作再次執行並看到通過；之後在檢查持續通過時重構。匯入錯誤或測試框架損壞不是預期的紅色結果。保留每項任務的指令、輸出及相關 commit 或 diff。測試驅動開發手冊說明須取得人類同意的例外；本指南假設任務適合一般測試先行路徑。

閱讀審查者的兩項判斷及實際 diff。接受任務前，依計畫與儲存庫解決所有「無法從 diff 驗證」的事項。檢查修正及其限定範圍複審；新的成功聲明不等於新的測試結果。7.0.0流程限制修復迴圈次數，並可用書面裁定暫緩處理問題。保留這些問題供後續審查。任務標記完成，不必然代表審查沒有保留意見。

任務完成後，檢查獨立進行的完整分支審查。它可辨識任務間的交互影響，並重新處理單一任務審查者無法從一個 diff 解決的暫緩問題。要求每個未結事項的證據與裁定。在外掛清理暫存工作區前，保留設計、計畫、測試輸出、審查報告與完整 diff。若預期技能未觸發，檢查啟用的外掛狀態、版本及文件中的診斷路徑；不能只因外掛已安裝就假設流程獲得強制執行。

4. 檢查分支並決定處理方式

在最終程式碼上再次執行原始驗收指令及專案完整測試套件。檢查最新輸出、完整分支 diff 和所有未結問題。Superpowers 驗證手冊要求完成聲明須有目前狀態的證據。如果測試套件失敗，找出確切錯誤並修復，或留下分支供審查；套件失敗時不會進入文件中的分支完成選單。

在具名分支上，finishing-a-development-branch提供本機合併、推送並建立 pull request，或原樣保留分支。分離的 HEAD 提供 pull request 與保留選項。捨棄操作僅在負責人明確要求並輸入確認後另行處理，不是例行第四選項。分支完成手冊說明這些選擇。負責人決定前，向其展示檢查結果、diff 與殘留問題。合併、推送、刪除或發布都需要相應操作權限。

有用的產物是與原始需求相關、可供審查的分支：核准的設計與計畫、實際觀察的測試結果、任務審查的兩項結論、完整分支審查、完整 diff，以及最新驗收結果。如果安裝、存取、預算或某項檢查讓執行停止，保留已驗證產物並說明最後完成階段。文件描述流程，不能證明本指南未執行的變更更快、更便宜或缺陷更少。

來源與延伸閱讀

若要修復單項驗收檢查，請參閱 BIG CHANGE 的儲存庫失敗檢查驗證指南。本文流程從更早階段開始，為多任務變更確定設計與計畫。