執行計畫
在本次會話中親自執行計畫，一項任務接一項任務：沒有每個任務的實作子代理，也沒有每個任務的審查者。最後對整個分支進行一次全新上下文的審查。
為什麼內聯： 子代理驅動的開發模式會為每個任務支付一個全新的實作者和審查者的費用，每個都從頭重新讀取程式碼庫。內聯執行支付一個上下文（你的）加上最後一個審查者的費用。它所放棄的是每個任務的新鮮上下文和每個任務的第二雙眼睛。這個技能透過其他方式保留了這兩樣東西帶來的價值：規格書就是摘要，帳簿就是你的記憶，TDD 是每個任務的閘門，而最終審查者是第二雙眼睛。
核心原則： 計畫已經完成了思考。精確執行它，用你親眼看到失敗然後通過的測試來證明每個步驟，並留下一個在你忘記之後仍然存在的記錄。
敘述： 在工具呼叫之間，最多敘述一行簡短的內容——帳簿和工具結果承載了記錄。
持續執行： 不要在任務之間停下來與你的人類夥伴確認。他們選擇內聯執行是為了花費更少，而不是為了在每個任務之後回答「我應該繼續嗎？」。從計畫中執行所有任務，不要中斷。
做出裁決，而不是停滯不前。 衝突、歧義、計畫缺陷——決定它們。規格書是具約束力的權威，計畫是它的論證，你的判斷解決了兩者都沒有回答的問題。在帳簿中將每個決策記錄為 裁決：<你決定了什麼> — <為什麼> — <如果錯了會付出什麼代價>，然後繼續。偏離計畫而沒有在帳簿中記錄裁決，就是一個秘密做出的決定。
只有四件事會阻止你，而且只有這些：不可逆或破壞性的操作；安全敏感的行動；此工作樹之外的、常規要求你事先詢問的副作用（合併、推送到共享分支、發布）；以及一個糟糕到每一條前進路徑都只是猜測的計畫。對於這些情況，停下來詢問。
使用時機
- 你從 superpowers:writing-plans 得到了一個計畫，並且你的人類夥伴在交接時選擇了內聯執行。
- 你的工具鏈沒有子代理工具（請參閱
../using-superpowers/references/中各平台的參考資料）。切勿偽造分派；在此處執行計畫。 - 任務大部分是獨立的——與 superpowers:subagent-driven-development 的先決條件相同。
一個完全指定的計畫使得內聯執行等同於轉錄加測試：它在中階會話模型上運行良好，而最強大模型能體現其價值的地方是最終審查，這個技能會單獨分派它。當人類夥伴選擇內聯時，告訴他們這一點。
當你的人類夥伴希望每個任務都有審查關卡，或者當計畫很長以至於後面的任務會在壓縮過的上下文中運行時，優先選擇 superpowers:subagent-driven-development。在長計畫上進行內聯執行仍然有效——帳簿使其可恢復——但最後的任務獲得最少的關注。
流程
digraph process {
rankdir=TB;
subgraph cluster_per_task {
label="每個任務";
"task-start: brief + BASE; 閱讀簡報" [shape=box];
"按順序執行步驟：TDD，執行每個驗證，閱讀每個輸出" [shape=box];
"步驟輸出與計畫的 '預期' 相符？" [shape=diamond];
"計畫錯了？裁決並記錄。程式錯了？使用 systematic-debugging" [shape=box];
"按照計畫的提交步驟進行提交" [shape=box];
"完成合約已滿足？" [shape=diamond];
"task-done：執行測試，記錄結果；標記待辦事項為完成" [shape=box];
}
"設定：工作樹、工作區 + 帳簿、閱讀計畫 + 規格書、預先掃描" [shape=box];
"還有更多任務？" [shape=diamond];
"最終完整分支審查（如果有，使用新的審查者）" [shape=box];
"重新評級，然後：嚴重/重要 → 一輪修正，每個修正 RED→GREEN + 綠色測試套件；次要 → 記錄" [shape=box];
"最終審查通過：刪除本計畫的工作區" [shape=box];
"使用 superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
"設定：工作樹、工作區 + 帳簿、閱讀計畫 + 規格書、預先掃描" -> "task-start: brief + BASE; 閱讀簡報";
"task-start: brief + BASE; 閱讀簡報" -> "按順序執行步驟：TDD，執行每個驗證，閱讀每個輸出";
"按順序執行步驟：TDD，執行每個驗證，閱讀每個輸出" -> "步驟輸出與計畫的 '預期' 相符？";
"步驟輸出與計畫的 '預期' 相符？" -> "計畫錯了？裁決並記錄。程式錯了？使用 systematic-debugging" [label="否"];
"計畫錯了？裁決並記錄。程式錯了？使用 systematic-debugging" -> "按順序執行步驟：TDD，執行每個驗證，閱讀每個輸出";
"步驟輸出與計畫的 '預期' 相符？" -> "按照計畫的提交步驟進行提交" [label="是，最後一步"];
"按照計畫的提交步驟進行提交" -> "完成合約已滿足？";
"完成合約已滿足？" -> "按順序執行步驟：TDD，執行每個驗證，閱讀每個輸出" [label="否 - 完成任務"];
"完成合約已滿足？" -> "task-done：執行測試，記錄結果；標記待辦事項為完成" [label="是"];
"task-done：執行測試，記錄結果；標記待辦事項為完成" -> "還有更多任務？";
"還有更多任務？" -> "task-start: brief + BASE; 閱讀簡報" [label="是"];
"還有更多任務？" -> "最終完整分支審查（如果有，使用新的審查者）" [label="否"];
"最終完整分支審查（如果有，使用新的審查者）" -> "重新評級，然後：嚴重/重要 → 一輪修正，每個修正 RED→GREEN + 綠色測試套件；次要 → 記錄";
"重新評級，然後：嚴重/重要 → 一輪修正，每個修正 RED→GREEN + 綠色測試套件；次要 → 記錄" -> "最終審查通過：刪除本計畫的工作區";
"最終審查通過：刪除本計畫的工作區" -> "使用 superpowers:finishing-a-development-branch";
}
設定
確保工作在隔離的工作區中進行：使用 superpowers:using-git-worktrees 來建立一個或驗證現有的工作區。未經人類夥伴明確同意，切勿在 main/master 分支上開始實作。
對話記憶無法在壓縮後倖存。一個失去位置的內聯執行器會重新實作已經存在提交的任務——與控制器重新分派它們的失敗相同，但代價是你的上下文。在帳簿檔案中追蹤進度，而不僅僅是在待辦事項中。工具鏈的待辦事項是即時視圖；而帳簿是記錄。
工作區和帳簿與 superpowers:subagent-driven-development 共享——相同的目錄，相同的格式——因此一個計畫可以在中途更換執行器，而新的執行器從同一個帳簿繼續。
- 每個計畫擁有一個工作區：在技能啟動時，執行
../subagent-driven-development/scripts/sdd-workspace PLAN_FILE——它會輸出該計畫的 git-忽略目錄（<repo-root>/.superpowers/sdd/<plan-basename>/），此處存放此計畫的所有工件：帳簿、簡報、審查包。另一個計畫的目錄絕不是你可以讀取或寫入的。 - 在此計畫的工作區檢查帳簿檔案
<workspace>/progress.md。如果它的第一行命中了你的計畫檔案，那麼帶有Task <N>: complete行的任務就是「已完成」——不要重做它們；從第一個沒有此行標記的任務繼續。即使你的上下文不再記得建立它們，它們的提交也存在於 git 中：在壓縮之後，相信帳簿和git log，而不是你自己的回憶。一個第一行命中了不同計畫檔案的帳簿是另一個計畫的進度：不要理會它，並開始你自己的全新帳簿。 - 建立帳簿，其身份是第一行：
# SDD 帳簿 — 計畫：<計畫檔案路徑>。 git clean -fdx會銷毀工作區（它是 git-忽略的暫存區）；如果發生這種情況，從git log恢復。
閱讀計畫一次，記下它的上下文和全域限制，並為每個任務建立一個待辦事項。如果計畫指定了一個規格書，也閱讀它：規格書是計畫所論證的權威，計畫內部的衝突應以它為準來解決。一個沒有可達規格書的計畫需要在帳簿中記錄一筆——在沒有規格書的情況下做出的裁決是暫時性的。
要求的子技能： 立即載入 superpowers:test-driven-development，在任務 1 之前。它主導下面每個任務的每一步；一個已經說「先寫失敗測試」的計畫步驟並不能免除你閱讀它的義務。
在任務 1 之前，掃描計畫中任務之間的衝突。計畫的「介面」區塊告訴你要查看哪裡：對於每個消耗先前任務產出的任務，在帳簿中記錄一行——這兩個任務，一個產出什麼，另一個消耗什麼，以及你的發現。沒有共享任何東西的任務不需要記錄；一個任務之間沒有共享的計畫只需記錄一行 預先掃描：無共享介面。以規格書為具約束力的權威來裁決每一行所揭示的衝突，在該行旁邊記錄裁決，然後開始任務 1。每個任務本身的文字是在你閱讀其簡報時檢查的，而不是在這裡。
任務循環
你列印的所有內容，以及每個工具結果，都會在會話的剩餘時間內常駐在你的上下文中。將較長的測試輸出重定向到工作區中的一個檔案，並讀取其尾部；閱讀簡報，而不是整個計畫。
1. 領取任務
- 執行此技能的
scripts/task-start PLAN_FILE N。它會在一次呼叫中輸出簡報路徑和 BASE（任務範圍從中切出的提交）。閱讀每個任務的簡報，包括你在設定時記得的那些：你記得的是摘要，而簡報包含精確的值、簽名和測試案例。 - 將任務的待辦事項標記為進行中。
每次工具呼叫都會重新讀取你的整個上下文。簿記工作與工作並行進行——在與提交相同的呼叫中追加帳簿，永遠不要單獨為其進行一次呼叫。
2. 執行步驟
計畫的步驟已經是 RED-GREEN 順序；在設定時載入的 superpowers:test-driven-development 下按該順序執行它們。測試步驟的程式碼先寫入並先執行。看著它失敗是一個步驟，而不是一種形式——一個在實作存在之前就通過的測試，是關於該測試的一個發現。
每個執行指令的步驟都有一個 預期： 行。執行指令，讀取其輸出，然後進行比較。三種結果：
- 符合。 下一步。
- 程式碼錯了。 使用 superpowers:systematic-debugging。找出原因；切勿為了讓步驟的輸出相符而修補症狀。
- 計畫錯了——一個步驟與規格書矛盾、來自先前任務的介面與此任務消耗的不匹配、一個無法運行的指令。裁決能滿足規格書的最小變更，在帳簿中記錄為
Task <N>: 裁決：<發現> — <你決定了什麼以及為什麼>，然後繼續。裁決是被承載的，而不是被記住的：後來觸及相同介面的任務會從帳簿中讀取它。
按照計畫的提交步驟進行提交。一個跨越多次提交的任務是可以的；BASE 是審查範圍從中切出的提交，絕不是 HEAD~1。
3. 完成合約
在一個任務的帳簿行之前，以下所有條件都成立，並在此會話中有證據——而不是從差異看起來正確來推斷：
- 簡報中提到的每個測試都存在並在此任務中執行過，並且你閱讀了輸出。
- 該任務的最終測試運行通過了——
task-done就是那次運行，它將指令和結果寫入帳簿行。 - 簡報中的每個
預期：行都與實際輸出進行了比較。 - 與簡報的每個偏差都在帳簿中有一個
裁決：行。
要求的子技能： superpowers:verification-before-completion 主導此聲明。如果缺少任何一項，則任務未完成：完成它。
4. 完成任務
使用簡報為整個任務命名的測試指令執行此技能的 scripts/task-done PLAN_FILE N BASE -- <test command>。它會執行測試，將完整輸出保留在工作區中，列印尾部，並且——僅當它們通過時——將完成行附加到帳簿：
Task <N>: complete (commits <base7>..<head7>, tests: <command> → <result>)
失敗的運行不會記錄任何內容；任務未完成。當它記錄時，將待辦事項標記為完成並領取下一個任務。
最終審查
執行 ../subagent-driven-development/scripts/review-package PLAN_FILE MERGE_BASE HEAD（MERGE_BASE = 分支開始的提交，例如 git merge-base main HEAD）並從它輸出的檔案進行審查。
使用子代理工具： 使用 superpowers:requesting-code-review 的 code-reviewer.md 在可用的最高能力模型上分派審查者——完整分支審查是一項判斷任務——提供包路徑、計畫和規格書路徑、計畫的「審查重點」部分原文（如果有的話，即計畫測試未涵蓋的輸入類別和失敗模式——審查者會刻意檢查每一個），以及指向帳簿中 裁決： 行的指標，以便它可以權衡你所做的決策。明確指定模型；省略模型會繼承會話的模型，而會話模型可能不是最高能力的。這是整個運行所購買的一個全新上下文。不要跳過它，也不要用你自己對差異的閱讀來取代它。
沒有子代理工具： 閱讀 code-reviewer.md 並針對審查包自行執行該審查，作為最後一個任務的帳簿行之後的單獨步驟。將 最終審查：自我審查（無子代理工具） 寫入帳簿，並在你的最終訊息中說明：由作者進行的自我審查弱於新的審查者，你的人类夥伴在合併前決定這是否足夠。
在你對任何發現採取行動之前，先對它們進行分類。審查者的嚴重性標籤是建議；關卡是你的。它的「拒絕判斷」列表也是你的：列表中的每一行都是一個你需要做出並記錄的裁決，就像計畫衝突一樣——最終：裁決：<審查者擱置的行為> — <一個合理的使用者使用此軟體會得到什麼，以及為什麼這成立或者為什麼它現在成為一個發現> — <如果錯了會付出什麼代價>。先根據效果重新評級：規格書是一份願景文件，一個發現的等級取決於如果它被發布，一個合理的使用者使用此軟體會得到什麼。
...