subagent-driven-development

子代理驅動開發

透過為每個任務派遣一個全新的實作子代理、每個任務後進行任務審查（規格符合性 + 程式碼品質），以及最後進行廣泛的全分支審查來執行計畫。

為什麼使用子代理： 你將任務委派給具有隔離上下文的專業代理。透過精確構建他們的指令和上下文，確保他們專注並成功完成任務。他們絕不應繼承你工作階段的上下文或歷史——你只構建他們確切需要的內容。這也保留了你自己用於協調工作的上下文。

核心原則： 每個任務使用全新子代理 + 任務審查（規格 + 品質）+ 廣泛的最終審查 = 高品質、快速迭代

敘述： 在工具呼叫之間，最多敘述一行簡短內容——記錄和工具結果承載了紀錄。

持續執行： 不要在任務之間暫停與人類夥伴確認。不間斷地執行計畫中的所有任務。唯一需要停止的原因是：無法解決的 BLOCKED 狀態、真正阻礙進展的模糊性，或所有任務完成。「我應該繼續嗎？」的提示和進度摘要浪費他們的時間——他們要求你執行計畫，所以執行它。

使用時機

digraph when_to_use {
    "有實作計畫？" [shape=diamond];
    "任務大多獨立？" [shape=diamond];
    "留在當前工作階段？" [shape=diamond];
    "subagent-driven-development" [shape=box];
    "executing-plans" [shape=box];
    "手動執行或先腦力激盪" [shape=box];

    "有實作計畫？" -> "任務大多獨立？" [label="是"];
    "有實作計畫？" -> "手動執行或先腦力激盪" [label="否"];
    "任務大多獨立？" -> "留在當前工作階段？" [label="是"];
    "任務大多獨立？" -> "手動執行或先腦力激盪" [label="否 - 高度耦合"];
    "留在當前工作階段？" -> "subagent-driven-development" [label="是"];
    "留在當前工作階段？" -> "executing-plans" [label="否 - 平行工作階段"];
}

與執行計畫（平行工作階段）比較：

相同工作階段（無需切換上下文）
每個任務使用全新子代理（無上下文污染）
每個任務後進行審查（規格符合性 + 程式碼品質），最後進行廣泛審查
更快的迭代（任務之間無需人類介入）

流程

digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="每個任務";
        "派遣實作子代理 (./implementer-prompt.md)" [shape=box];
        "實作子代理提問？" [shape=diamond];
        "回答問題，提供上下文" [shape=box];
        "實作子代理實作、測試、提交、自我審查" [shape=box];
        "撰寫 diff 檔案，派遣任務審查子代理 (./task-reviewer-prompt.md)" [shape=box];
        "任務審查員回報規格 ✅ 且品質通過？" [shape=diamond];
        "針對重大/重要發現派遣修復子代理" [shape=box];
        "在待辦清單和進度記錄中標記任務完成" [shape=box];
    }

    "閱讀計畫，記錄上下文和全域限制，建立待辦事項" [shape=box];
    "還有更多任務？" [shape=diamond];
    "派遣最終程式碼審查子代理 (../requesting-code-review/code-reviewer.md)" [shape=box];
    "使用 superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "閱讀計畫，記錄上下文和全域限制，建立待辦事項" -> "派遣實作子代理 (./implementer-prompt.md)";
    "派遣實作子代理 (./implementer-prompt.md)" -> "實作子代理提問？";
    "實作子代理提問？" -> "回答問題，提供上下文" [label="是"];
    "回答問題，提供上下文" -> "派遣實作子代理 (./implementer-prompt.md)";
    "實作子代理提問？" -> "實作子代理實作、測試、提交、自我審查" [label="否"];
    "實作子代理實作、測試、提交、自我審查" -> "撰寫 diff 檔案，派遣任務審查子代理 (./task-reviewer-prompt.md)";
    "撰寫 diff 檔案，派遣任務審查子代理 (./task-reviewer-prompt.md)" -> "任務審查員回報規格 ✅ 且品質通過？";
    "任務審查員回報規格 ✅ 且品質通過？" -> "針對重大/重要發現派遣修復子代理" [label="否"];
    "針對重大/重要發現派遣修復子代理" -> "撰寫 diff 檔案，派遣任務審查子代理 (./task-reviewer-prompt.md)" [label="重新審查"];
    "任務審查員回報規格 ✅ 且品質通過？" -> "在待辦清單和進度記錄中標記任務完成" [label="是"];
    "在待辦清單和進度記錄中標記任務完成" -> "還有更多任務？";
    "還有更多任務？" -> "派遣實作子代理 (./implementer-prompt.md)" [label="是"];
    "還有更多任務？" -> "派遣最終程式碼審查子代理 (../requesting-code-review/code-reviewer.md)" [label="否"];
    "派遣最終程式碼審查子代理 (../requesting-code-review/code-reviewer.md)" -> "使用 superpowers:finishing-a-development-branch";
}

飛行前計畫審查

在派遣任務 1 之前，掃描計畫一次以檢查衝突：

任務之間互相矛盾或與計畫的全域限制矛盾
計畫明確要求但審查標準視為缺陷的內容（例如沒有斷言的測試、邏輯區塊的逐字複製）

將所有發現一次性呈現給人類夥伴——每個發現附上計畫中要求它的文字，詢問哪個為準——在開始執行之前，而不是在計畫執行中途每次發現時中斷。如果掃描結果乾淨，則無需評論直接進行。審查循環仍然是捕捉僅在實作中出現的衝突的網。

模型選擇

使用能夠處理每個角色的最不強大的模型，以節省成本並提高速度。

機械式實作任務（獨立函式、明確規格、1-2 個檔案）：使用快速、便宜的模型。當計畫規格明確時，大多數實作任務都是機械式的。

整合與判斷任務（多檔案協調、模式比對、除錯）：使用標準模型。

架構與設計任務：使用最強大的可用模型。最終的全分支審查屬於此類——使用最強大的可用模型派遣，而不是工作階段預設模型。

審查任務：根據 diff 的大小、複雜度和風險，選擇具有相同判斷力的模型。小的機械式 diff 不需要最強大的模型；微妙的並行變更則需要。

派遣子代理時務必明確指定模型。 省略模型會繼承你工作階段的模型——通常是最強大且最昂貴的——這會默默違反本節原則。

回合數比 token 價格更重要。 實際時間和上下文成本取決於子代理花費的回合數，而最便宜的模型在多步驟工作上通常需要 2-3 倍的回合數——整體成本更高。對於審查員以及從文字描述實作的實作者，使用中階模型作為下限。當任務的計畫文字包含要撰寫的完整程式碼時，實作就是抄寫加測試：對該實作者使用最便宜的層級。單一檔案的機械式修復也使用最便宜的層級。

任務複雜度訊號（實作任務）：

涉及 1-2 個檔案且規格完整 → 便宜模型
涉及多個檔案且有整合問題 → 標準模型
需要設計判斷或廣泛的程式碼庫理解 → 最強大的模型

處理實作者狀態

實作子代理回報四種狀態之一。適當處理每種狀態：

DONE： 產生審查套件（scripts/review-package BASE HEAD，從此技能的目錄執行——它會輸出寫入的唯一檔案路徑；BASE 是你記錄在派遣實作者之前的提交——永遠不要用 HEAD~1，它會默默丟棄多提交任務中除了最後一個提交之外的所有提交），然後使用輸出的路徑派遣任務審查員。

DONE_WITH_CONCERNS： 實作者完成了工作但標記了疑慮。在繼續之前閱讀這些疑慮。如果疑慮是關於正確性或範圍，請在審查之前處理。如果它們是觀察結果（例如「這個檔案變大了」），記錄下來並繼續進行審查。

NEEDS_CONTEXT： 實作者需要未提供的資訊。提供遺失的上下文並重新派遣。

BLOCKED： 實作者無法完成任務。評估阻礙：

如果是上下文問題，提供更多上下文並使用相同模型重新派遣
如果任務需要更多推理，使用更強大的模型重新派遣
如果任務太大，將其分解為更小的部分
如果計畫本身有誤，升級給人類

永遠不要忽略升級或強迫相同模型在沒有變更的情況下重試。如果實作者說它卡住了，則需要改變某些東西。

處理審查員的 ⚠️ 項目

任務審查員可能回報「⚠️ 無法從 diff 驗證」的項目——這些要求存在於未變更的程式碼中或跨越多個任務。這些不會阻止其餘審查，但你必須在標記任務完成之前自行解決每個項目：你掌握審查員缺乏的計畫和跨任務上下文。如果你確認某個項目是真實的差距，將其視為失敗的規格審查——將其送回給實作者並重新審查。

構建審查員提示

每個任務的審查是任務範圍的關卡。廣泛審查僅在最終的全分支審查中進行一次。當你填寫審查員模板時：

不要添加開放式指令，如「檢查所有使用情況」或「如果有用則執行競爭測試」，除非有具體的任務特定原因
不要要求審查員重新執行實作者已在相同程式碼上執行的測試——實作者的報告包含測試證據
不要預先判斷審查員的發現——永遠不要指示審查員忽略或不標記特定問題。如果你認為某個發現是誤報，讓審查員提出並在審查循環中裁決。如果你正在撰寫的提示包含「不要標記」、「不要將 X 視為缺陷」、「最多 Minor」或「計畫選擇了」——停止：你正在預先判斷，通常是為了讓自己省去審查循環。
你交給審查員的全域限制區塊是其注意力鏡頭。從計畫的全域限制部分或規格中逐字複製綁定要求：確切的值、確切的格式以及組件之間的陳述關係（「與 X 相同的佈局」、「匹配 Y」）。審查員的模板已經包含流程規則（YAGNI、測試衛生、審查方法）——限制區塊是針對此專案規格要求的內容。
將 diff 作為檔案交給審查員：執行此技能的 scripts/review-package BASE HEAD 並將輸出的檔案路徑傳遞給審查員（或者，如果沒有 bash：使用 git log --oneline、git diff --stat 和 git diff -U10 獲取範圍，並重定向到一個唯一命名的檔案）。輸出永遠不會進入你自己的上下文，審查員在一次 Read 呼叫中看到提交列表、統計摘要和帶有上下文的完整 diff。使用你在派遣實作者之前記錄的 BASE——永遠不要用 HEAD~1，它會默默截斷多提交任務。
派遣提示描述一個任務，而不是工作階段的歷史。不要將累積的先前任務摘要（「任務 1-3 之後的狀態」）貼到後續的派遣中——一個真實工作階段的派遣提示達到了 42k 字元，其中 99% 是貼上的歷史。一個全新的子代理需要它的任務、它接觸的介面以及全域限制。沒有其他東西。
針對重大和重要的發現派遣修復子代理。將次要發現記錄在進度記錄中，並在最終的全分支審查中指向該列表，以便它可以分類哪些必須在合併前修復。沒有人閱讀的彙總就是默默丟棄。
標記為計畫要求的發現——或任何與計畫文字要求衝突的發現——是人類的決定，就像任何計畫矛盾一樣：呈現發現和計畫文字，詢問哪個為準。不要因為計畫要求就駁回發現，也不要在未詢問的情況下派遣與計畫矛盾的修復。
最終的全分支審查也需要一個套件：執行 scripts/review-package MERGE_BASE HEAD（MERGE_BASE = 分支開始的提交，例如 git merge-base main HEAD）並在最終審查派遣中包含輸出的路徑，以便最終審查員讀取一個檔案，而不是使用 git 命令重新推導分支 diff。
每個修復派遣都帶有實作者合約：修復子代理重新執行涵蓋其變更的測試並報告結果。在派遣中命名涵蓋的測試檔案——一行修復不需要整個測試套件。在重新派遣審查員之前，確認修復報告包含涵蓋的測試、執行的命令和輸出；一旦三者都存在，就派遣重新審查。
如果最終的全分支審查返回發現，派遣一個修復子代理處理完整的發現列表——而不是每個發現一個修復者。每個發現的修復者都會重建上下文並重新執行測試套件；一個真實工作階段的最終審查修復波成本超過其所有任務的總和。

檔案交接

你貼到派遣提示中的所有內容——以及子代理回傳的所有內容——都會在你工作階段的其餘時間保留在上下文中，並在後續每個回合重新讀取。將工件作為檔案傳遞：

任務簡報： 在派遣實作者之前，執行此技能的 scripts/task-brief PLAN_FILE N——它會將任務的完整文字提取到一個唯一命名的檔案並輸出路徑。撰寫派遣時，讓簡報成為需求的單一來源。你的派遣應包含：(1) 一行說明此任務在專案中的位置；(2) 簡報路徑，介紹為「先閱讀此檔案——這是你的需求，包含要逐字使用的確切值」；(3) 來自先前任務的介面和決策，簡報無法得知；(4) 你對簡報中注意到的任何模糊性的解決方案；(5) 報告檔案路徑和報告合約。確切值（數字、魔術字串、簽名、測試案例）僅出現在簡報中。
報告檔案： 將實作者的報告檔案命名為與簡報相對應（簡報 …/task-N-brief.md → 報告 …/task-N-report.md）並將其放在派遣提示中。實作者在那裡撰寫完整報告，僅回傳狀態、提交、一行測試摘要和疑慮。
審查員輸入： 任務審查員獲得三個路徑——相同的簡報檔案、報告檔案和審查套件——以及約束任務的全域限制。
修復派遣將其修復報告（含測試結果）附加到相同的報告檔案並回傳簡短摘要；重新審查讀取更新後的檔案。

持久化進度

對話記憶無法在壓縮後存活。在真實工作階段中，失去位置的控制器已重新派遣整個完成的任務序列——這是觀察到的最昂貴的失敗。在記錄檔案中追蹤進度，而不僅僅是待辦事項。

在技能啟動時，檢查記錄檔案：cat "$(git rev-parse --show-toplevel)/.superpowers/sdd/progress.md"。那裡標記為完成的任務是 DONE——不要重新派遣它們；從第一個未標記完成的任務繼續。
當任務的審查乾淨返回時，在與其他簿記相同的訊息中附加一行到記錄檔案：Task N: complete (commits <base7>..<head7>, review clean)。
記錄檔案是你的恢復地圖：它命名的提交存在於 git 中，即使你的上下文不再記得建立它們。壓縮後，信任記錄檔案和 git log 勝過你自己的記憶。
git clean -fdx 會銷毀記錄檔案（它是 git 忽略的暫存檔案）；如果發生這種情況，從 git log 恢復。

提示模板

implementer-prompt.md - 派遣實作子代理
task-reviewer-prompt.md - 派遣任務審查子代理（規格符合性 + 程式碼品質）
最終全分支審查：使用 superpowers:requesting-code-review 的 code-reviewer.md

範例工作流程

你：我正在使用子代理驅動開發來執行此計畫。

[讀取計畫檔案一次：docs/superpowers/plans/feature-plan.md]
[為所有任務建立待辦事項]

任務 1：掛鉤安裝腳本

[為任務 1 執行 task-brief；使用簡報 + 報告路徑 + 上下文派遣實作者]

實作者：「在我開始之前——掛鉤應該安裝在使用者層級還是系統層級？」

你：「使用者層級 (~/.config/superpowers/hooks/)」

實作者：「收到。正在實作...」
[稍後] 實作者：
  - 實作了 install-hook 命令
  - 新增測試，5/5 通過
  - 自我審查：發現我遺漏了 --force 標誌，已新增
  - 已提交

[執行 review-package，使用輸出的路徑派遣任務審查員]
任務審查員：規格 ✅ - 所有需求已滿足，無多餘內容。
  優點：測試覆蓋良好，乾淨。問題：無。任務品質：通過。

[標記任務 1 完成]

任務 2：復原模式

[為任務 2 執行 task-brief；使用簡報 + 報告路徑 + 上下文派遣實作者]

實作者：[無問題，直接進行]
實作者：
  - 新增 verify/repair 模式
  - 8/8 測試通過
  - 自我審查：一切正常
  - 已提交

[執行 review-package，使用輸出的路徑派遣任務審查員]
任務審查員：規格 ❌：
  - 缺少：進度報告（規格說「每 100 項報告一次」）
  - 多餘：新增了 --json 標誌（未要求）
  問題（重要）：魔術數字 (100)

[使用所有發現派遣修復子代理]
修復者：移除了 --json 標誌，新增了進度報告，提取了 PROGRESS_INTERVAL 常數

[任務審查員再次審查]
任務審查員：規格 ✅。任務品質：通過。

[標記任務 2 完成]

...

[所有任務完成後]
[派遣最終程式碼審查員]
最終審查員：所有需求已滿足，準備合併

完成！

優勢

與手動執行比較：

子代理自然遵循 TDD
每個任務使用全新上下文（無混淆）
平行安全（子代理不互相干擾）
子代理可以提問（工作之前和期間）

與執行計畫比較：

相同工作階段（無需交接）
持續進度（無需等待）
審查檢查點自動化

效率提升：

控制器精確策劃所需的上下文；大量工件以檔案形式移動，而非貼上的文字
子代理事先獲得完整資訊
問題在工作開始前浮現（而非之後）

品質關卡：

自我審查在交接前捕捉問題
任務審查包含兩個裁決：規格符合性和程式碼品質
審查循環確保修復確實有效
規格符合性防止過度/不足建構
程式碼品質確保實作建構良好

成本：

更多子代理呼叫（每個任務實作者 + 審查員）
控制器做更多準備工作（事先提取所有任務）
審查循環增加迭代次數
但及早捕捉問題（比後續除錯便宜）

紅旗

絕不：

在未經使用者明確同意的情況下開始在主分支上實作
跳過任務審查，或接受缺少任一裁決的報告（規格符合性和任務品質兩者都需要）
在未修復問題的情況下繼續進行
平行派遣多個實作子代理（衝突）
讓子代理讀取整個計畫檔案（改為交給它任務簡報——scripts/task-brief）
跳過場景設定上下文（子代理需要了解任務的位置）
忽略子代理的問題（在讓他們繼續之前回答）
在規格符合性上接受「差不多」（審查員發現規格問題 = 未完成）
跳過審查循環（審查員發現問題 = 實作者修復 = 再次審查）
讓實作者的自我審查取代實際審查（兩者都需要）
告訴審查員不要標記什麼，或在派遣提示中預先評級發現的嚴重性（「最多視為 Minor」）——計畫的範例程式碼是起點，而非其弱點是被選擇的證據
在沒有 diff 檔案的情況下派遣任務審查員——先產生它（scripts/review-package BASE HEAD）並在提示中命名輸出的路徑
在審查仍有未解決的重大/重要問題時移動到下一個任務
重新派遣進度記錄已標記為完成的任務——在任何壓縮或恢復後檢查記錄檔案（和 git log）

如果子代理提問：

清晰且完整地回答
如有需要提供額外上下文
不要催促他們進行實作

如果審查員發現問題：

實作者（同一個子代理）修復它們
審查員再次審查
重複直到通過
不要跳過重新審查

如果子代理任務失敗：

使用具體指示派遣修復子代理
不要嘗試手動修復（上下文污染）

整合

所需的工作流程技能：

superpowers:using-git-worktrees - 確保隔離的工作區（建立一個或驗證現有的）
superpowers:writing-plans - 建立此技能將執行的計畫
superpowers:requesting-code-review - 最終全分支審查的程式碼審查模板
superpowers:finishing-a-development-branch - 在所有任務完成後完成開發

子代理應使用：

superpowers:test-driven-development - 子代理為每個任務遵循 TDD

替代工作流程：

superpowers:executing-plans - 用於平行工作階段而非相同工作階段執行

您可能也喜歡

golang-how-to

2.3Ktesting-qa

Golang 技能編排器 — 在任何 Golang 編碼、審查、除錯或設定任務中始終啟用。讀取任務上下文並從 samber/cc-skills-golang 載入最相關的技能，通常一次載入多個：撰寫 gRPC 服務時載入 golang-grpc + golang-testing + golang-error-handling；除錯 panic 時載入 golang-troubleshooting + golang-safety；稽核安全性時載入 golang-security + golang-lint + golang-safety。此外，當兩個技能看似重疊時（效能 vs 基準測試 vs 疑難排解、samber/lo vs mo vs ro、DI 叢集、安全性 vs 安全），進行消歧，並設定 CLAUDE.md 或 AGENTS.md 以在專案中強制觸發技能（/golang-how-to configure）。

samber

獲取

check

6.4Ktesting-qa

Reviews code diffs, PRs, issue queues, release readiness, commits, pushes, publishing, and project audits. Use when users ask in any language for code review, issue or PR triage, release gates, publishing follow-through, or project audits. Not for debugging root causes or prose review.

tw93

獲取

observability-and-instrumentation

79Ktesting-qa

Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

addyosmani

獲取

繼續探索

瀏覽 testing-qa 熱門 Skills 最近更新