Plan Review — 裁決者 + 審查者的計畫審查

計畫做好後不直接交出去，先交給一個腦袋全新的裁決者。裁決者平行派審查者去證明計畫有重大缺失， 收回之後反過來查證每一條批評，只把站得住的交回來。主對話照著改，改到沒有站得住的重大缺失為止。

設計來源：docs/designs/2026-10-23-裁決審查-design.md（claude-dd repo）。

什麼時候跑

步驟

1. 準備交給裁決者的東西

• 審查範圍：這次要審的是什麼（整份計畫，或某份文件的某一段）。只審一段時寫明「其他段落是背景，不在範圍內」， 這句同時寫進「事實」開頭（「審查範圍」那一欄審查者看不到）
• 計畫全文：照要交給使用者的版本，一字不改。計畫引用或依賴別處的段落（「見設計決策」、上層的設計決策表、 它依賴的段落），把那幾段一起附上，標「附錄：<出處>」；整份大文件放不下時，附路徑讓審查者自己讀
• 已查到的事實：讀過哪些檔（路徑）、實跑過的指令與輸出、使用者在對話裡講定的決定（逐條，標「使用者決定」）
• 只交事實，不交「我判斷 X 是原因」。要寫推測就標明是推測 —— 裁決者與審查者會跟著錯的框架走
• 第 2 輪以後：再附上前幾輪的裁決報告全文、「這輪改了哪裡」的清單、前幾輪外部查證的結果、前幾輪還沒問使用者的「需使用者決定」
• 輪次：這是第幾輪（從 1 開始）
• 專案根目錄的絕對路徑（審查者要自己 grep）

2. 派裁決者

用 Agent 工具：subagent_type: "general-purpose"、model: "opus"，prompt 用下面的「裁決者範本」。 主對話只填 {…}（範圍、計畫、事實、輪次、根目錄）；範本裡的 《…》 是留給裁決者填的，原樣保留。 計畫與事實放在 <<<…開始>>> / <<<…結束>>> 標記之間，不要用 Markdown 圍欄包（計畫裡有三個反引號會把圍欄提早關掉）。

裁決者在背景跑，要等它自己派的審查者，通常要好幾分鐘。等它的完成通知回來，不要自己先審、也不要先往下做。 沒有逾時機制：使用者問進度就照實說「還在跑」；使用者說不等了，就當成沒跑成（第 5 步）。

3. 照報告的「結論」走

結論只有三種值，照字面判，不要從別節推：

報告缺「結論」、或自相矛盾（寫 通過 但「採納（重大）」不是空的，或「需要外部查證」裡有標重大的）→ 當成沒跑成，走第 5 步。

不通過時：

1. 「需使用者決定」裡有標了「卡住哪條重大」的題目 → 先用 AskUserQuestion 問這幾題；其他題留到下一輪的事實裡
2. 照「採納（重大）」逐條改計畫；「需要外部查證」裡標重大的，主對話自己查（自己有工具就查，查不了就問使用者）， 結果寫進下一輪的事實
3. 「採納（小事）」順手改掉，不必為它再送一輪
4. 改好的全文回到第 1 步，輪次加 1，再送一次

最多 3 輪。第 3 輪還是 不通過：重大與小事一樣照上面 1–3 改進計畫，然後停下來回報，不要自己送第 4 輪、也不要自己開工。 沒有下一輪了，所以 1 的「其他題」留到下面停下時一起問；2 的外部查證查到屬實就照改（未經審查），查到不屬實寫「不成立（查證結果）」，自己查不了、問了使用者也沒有結果的寫「沒改（外部查證還沒結果）」。 回報時每條重大寫明現況：「已改進計畫（未經審查）」或「沒改（原因）」——「沒改」只用在使用者決定不改、或外部查證還沒結果的那幾條（查證不屬實寫「不成立」）； 只寫「剩 N 條重大」會被讀成還沒修。所有還沒問的「需使用者決定」一起問，再問接下來怎麼做： 跑一次確認輪（建議：第 3 輪的改法動到計畫內容時）、照改好的計畫繼續、或停下。 選照改好的計畫繼續 → 照第 4 步第 2、3 項做，最終計畫標明哪些改法未經審查（第 3 輪與確認輪改的重大與小事、因使用者答案改的地方）。 選停下（這裡或下面確認輪那幾條）→ 貼出改好的計畫與每條重大的現況，然後結束，不開工；呼叫端另有寫法時照呼叫端。

確認輪只在使用者選它時跑、只跑一次，用來審「第 3 輪的改法改對了沒」，不是再全面攻擊一次：

• 照第 1 步重送（事實照「第 2 輪以後」那條附），輪次寫 3C（審查者代號因此是「輪3C-R1」…）；第 4 步判「是不是已到第 3 輪」時，確認輪算第 3 輪
• 範圍句同時寫進「審查範圍」與「事實」開頭：「只審第 3 輪已改進計畫的這幾條〈逐條列出，重大與小事都列〉、以及因第 3 輪使用者答案（含改計畫時先問的）而改的地方， 改對了沒、改法有沒有帶出新問題；其他部分（含標「沒改」的那幾條）是背景。範圍外的新發現照列，但一律算小事、不擋結論」
• 結論 通過 → 走第 4 步；不通過 → 確認輪的報告也照上面 1–3 改進計畫（改法一樣未經審查），照上面的回報方式列給使用者， 先問還沒問的「需使用者決定」，再問照改好的計畫繼續或停下，不再送；回報列第 3 輪與確認輪的重大，確認輪的外部查證照第 3 輪那條處理。選繼續 → 照上面那條標明未經審查。 第 3 輪改進的重大同時符合三條 —— 列在確認輪範圍裡；確認輪報告的採納與需要外部查證都沒有指向它、需使用者決定沒有在問它；確認輪之後沒再改 —— 現況寫「已改進計畫（未經審查；在確認輪範圍內，確認輪沒指出問題）」。狀態仍算未經審查（其他規則照未經審查處理）；註記只表示它在範圍內、 報告沒指出它的問題，不表示有審查者逐條看過。貼最終計畫或寫進文件之前再判一次第三條，之後被改到的拿掉註記。確認輪沒跑成時不加這句註記；確認輪通過時，第 3 輪列在範圍內的改法算審過，不標未經審查
• 確認輪沒跑成 → 照第 5 步告知原因、先問還沒問的「需使用者決定」，再問重跑（仍算同一次確認輪）、照改好的計畫繼續、或停下 —— 不給「不審直接交」：計畫已經審過 3 輪，選照改好的計畫繼續就照上面標明哪些改法未經審查；第 4 步貼摘要時 3C 寫「沒跑成（原因）」

4. 通過之後

1. 先照「採納（小事）」改計畫（不再送審）。所有輪次還沒問的「需使用者決定」→ 用 AskUserQuestion 問（每題附裁決者給的選項與建議答案）。通過時，這是唯一要問使用者的審查結果。 呼叫端自己的題（例如 task-planner 的決策題、測試清單題）跟這些一起問，分批照下面「問使用者的分批」。 使用者選了非建議答案、而且會改到計畫：照答案改；還沒到第 3 輪就回第 1 步再送一輪，已經是第 3 輪（含確認輪）就不再送， 把「因為你的答案改了哪裡」列給使用者，最終計畫標明這些改法未經審查
2. 在訊息裡貼出：最終計畫、所有輪次的駁回清單（每條一句話）、審了幾輪（確認輪另列為 3C）、每輪派了幾個審查者； 前幾輪標「沒改」的重大連同現況一起貼，最終計畫也標明（確認輪通過時它們是背景，沒有被處理）
3. 接著做，不再問使用者「這個計畫可以嗎」：
   • 在 plan mode 裡 → 呼叫 ExitPlanMode（那是 harness 的批准，拿不掉，使用者按一次）
   • 不在 plan mode → 直接開工；呼叫端有自己的下一步時（例如 task-planner 的步驟 5 寫文件），「開工」指走那一步
   • 仍然要停下來問的：§4.2 破壞性操作、使用者說了停等語（「先告訴我」「等我確認」這類）
   • ⚠️ 使用者的 CLAUDE.md、或呼叫本 skill 的那個 skill 仍寫著要使用者批准時，照那邊問 —— 那是使用者自己寫的規則，本 skill 不覆蓋它

問使用者的分批

第 3 步（不通過）、第 4 步（通過）、第 5 步（沒跑成）要問使用者時都照這條，依序：

1. 會改到計畫的題
2. 「接下來怎麼做」（例如「確認輪／照改好的計畫繼續／停下」「重跑／不審直接交」）
3. 呼叫端寫明要等「接下來怎麼做」選完才問的題（例如 task-planner 在第 3 輪不通過與沒跑成兩條路上的決策題；確認輪通過時改照第 4 步，算第 1 項）
4. 呼叫端標明要對著最終計畫問的題（例如 task-planner 的測試清單題）

第 3 項一律等第 2 項答完才另外問；第 4 項在前面有第 1–3 項的題時，等那些都答完、計畫改好才另外問。其餘照順序併成一次 AskUserQuestion， 超過 4 題再分批（一次最多 4 題）。同一件事只問一次。 第 3 步不通過時，卡住重大的題（第 3 步第 1 項）與查不了、要問使用者的外部查證（第 2 項）在改計畫時就先問（兩類併成同一次，超過 4 題再分批），不併進停下回報之後那一次。

5. 沒跑成

裁決者回錯誤、報告缺「結論」或自相矛盾、結論是 無法判定、或使用者說不等了：照實告訴使用者「計畫審查沒跑成」， 附原因（錯誤訊息原文或報告裡的原因），先問所有輪次還沒問的「需使用者決定」，再問要重跑還是不審直接交（確認輪沒跑成時的選項照第 3 步確認輪那條）。重跑用同一個輪次重送，不算多一輪。 選不審直接交 → 先照剛問到的「需使用者決定」答案改計畫（不再送審），再照第 4 步第 2、3 項做，最終計畫開頭標「未經審查（使用者選不審直接交）」，審了幾輪寫實際完成的輪數、沒跑成的輪次寫「沒跑成（原因）」、審查者數寫「不明」；呼叫端另有寫法時照呼叫端。 不可以當成通過、靜默往下走。

裁決者範本

你是計畫審查的裁決者，這是第 {輪次} 輪。你的工作分兩半：先派審查者去攻擊這份計畫，再反過來查證他們的每一條批評。
全程唯讀：只能讀檔、grep、看 git 紀錄；不改檔、不 commit、不跑測試、不為了查證另外派 agent。

審查範圍：{範圍}

<<<計畫開始>>>
{計畫全文，含附錄}
<<<計畫結束>>>

<<<事實開始>>>
{已查到的事實；第 2 輪以後含前幾輪的裁決報告、「這輪改了哪裡」、還沒問的「需使用者決定」}
<<<事實結束>>>

專案根目錄：{絕對路徑}。專案規則在根目錄與各層的 CLAUDE.md。

【第一步：派審查者】
用 Agent 工具平行派審查者（同一則訊息裡一次派完）：subagent_type "general-purpose"、model "haiku"。
- 數量你決定，**最少 3 個、沒有上限**。計畫越大、牽涉越廣就派越多
- 每個審查者給代號「輪{輪次}-R1」「輪{輪次}-R2」…，並給一個方向：可以分工（例如「前提成不成立」「漏掉的同步點」「範圍與驗證」），
  也可以派幾個都做「全面」
- 每個審查者的 prompt 用下面的「審查者範本」：填入《代號》《方向》，《計畫與事實》貼上面兩組標記之間的內容（連標記一起），
  《根目錄》貼專案根目錄
- 審查者互相看不到對方

**每次派出審查者（含之後的重派、補派）就結束這一輪。** 審查者完成時，它們的報告會以訊息送回給你，你會被喚醒；
**這一批全部回報之前不要寫最終報告、不要開始判**。

【審查者範本】
你是計畫審查者《代號》。你唯一的職責：找漏洞、猛烈批評，證明這份計畫有重大缺失。
不寫優點、不寫「整體不錯」、不客套。

《計畫與事實》
專案根目錄：《根目錄》（規則在根目錄與各層 CLAUDE.md）
你的方向：《方向》
審查範圍以事實開頭寫的為準（沒寫就是整份計畫）；範圍外的段落只是背景，不要把它們沒做的事算成這份計畫做少了。

要查的：
1. 計畫的前提成不成立 —— 它說某檔有某段、某函式這樣運作、某數字是多少，你自己 grep / 讀檔確認
2. 有沒有漏掉專案文件規定要一起改的地方 —— 在**各層** CLAUDE.md 搜「新增」「同時改」「同批」「要一起」「同步」「手動同步」，
   讀到的規則逐條對計畫
3. 範圍對不對：做多了、做少了、順序錯了
4. 驗證方式抓不抓得到錯：計畫說的驗證，在它該抓的錯真的發生時會不會變紅

規則：
- 只能讀檔、grep、看 git 紀錄。測試、build、安裝、上網、開容器都不要跑，需要的寫進「需要外部查證」交回
- **每條批評都要附證據**：`路徑:行號範圍`，需要原文就在下一行縮排貼出來；或 grep 指令與結果。沒證據的批評不要寫
- 計畫已經安排好要處理的事（寫在開工前提、驗證步驟、後面的段落裡），不算缺失
- 每條標嚴重度。**三個都符合才是重大**：
  ①常走的路：照這份計畫做時大多數情況會經過（「沒跑成」「第 3 輪還不過」這種例外流程不算）；金額、權限、刪資料不管多少見都算
  ②照做會壞、會錯，或會跳過使用者的決定
  ③錯了不會報錯，後面的關卡（code-review、測試、gate；之後再跑的 plan-review 不算）也抓不到。那些關卡是照計畫檢查的，
  所以「計畫要求做錯的事」通常符合 ③；「計畫漏寫、但做的時候一定會撞到而報錯」不符合。③ 寫理由即可，不必附行號
  其他都是小事
- 真的找不到重大缺失就照實寫，**不要為了交差硬湊**；但「我查了什麼」一定要寫
- 你所在的環境若規定用某個工具交回報告（例如 SubagentHandback），就用那個工具交

輸出格式（照抄這些標題）：
【我查了什麼】讀過的檔、跑過的 grep（指令照貼），沒有批評時也要寫
【批評】每條：《代號》-<序號>｜嚴重度｜內容｜證據
【需要外部查證】每條：《代號》-<序號>｜嚴重度｜內容｜為什麼需要
（審查者範本到此結束）

【第二步：查證】
這一批全部回來之後，先做**讀檔檢查**：只看「有沒有真的讀檔」，不看找到的是大事還是小事。
每個審查者至少抽一處它引用的 `路徑:行`，自己讀那幾行，確認內容對得上。對得上就算過 —— 只找到小事、甚至沒找到問題，都算過。
對不上、或完全沒有引用任何檔案行，就是沒過。

每個代號的位置**最多重派一次**（回錯誤或沒過讀檔檢查都算這一次），重派的代號加「b」（例如輪1-R2b），
並在 prompt 開頭告訴它上次為什麼不算。重派還是不行，它不算有效審查者。
有效審查者少於 3 個：補派新代號補到 3 個（補派只做一次，補派的人沒過就不再派）；
補完還是少於 3 個，結論寫 `無法判定（有效審查者不足 3 個）`。重派、補派之後一樣結束這一輪等它們回來。

再對**每一條**批評做對抗驗證：預設「這條批評可能是錯的」，自己讀檔、grep 判定。不表決 ——
三個審查者都說對、讀檔證明是錯的，就是錯的。每條分到一類：
- **採納**：查證屬實。再分「重大」與「小事」—— 照審查者範本那條三個條件自己重判，不照審查者標的；小事照樣要改，但不擋通過
- **駁回**：查證不屬實、證據不支持、或計畫已經安排處理。一句話寫理由
  - 前幾輪已駁回的批評被重提：沒有新證據就駁回，理由寫「同輪N-…，無新證據」
  - 批評衝著標了「使用者決定」的事：駁回，理由寫「使用者決定」。只有在它拿出證據證明那個決定建立在錯的事實上時，
    改分到「需使用者決定」並附上證據
- **需使用者決定**：程式碼、測試、文件都沒寫明該怎樣，只有使用者能選（例如金額怎麼算、權限給誰）。
  寫出選項與你的建議答案；它擋住某條重大缺失的改法時，寫出是哪一條。**除了這類，其他都由你決定，不要推給使用者**
- 審查者交回的「需要外部查證」：你用讀檔、grep 能查就查完再分類；查不了的照列在「需要外部查證」，嚴重度一樣照三個條件自己重判（假設它查出來是真的）
- 審查範圍寫了「範圍外的新發現一律算小事」時，範圍外的採納與需要外部查證一律標小事、不計入結論的 N

**結論**（三選一，照這個字面寫）：
- `通過`：讀檔檢查過了，沒有採納的重大缺失，「需要外部查證」裡也沒有重大的
- `不通過（N 條重大）`：N = 採納的重大缺失 + 需要外部查證裡重大的條數
- `無法判定（<原因>）`：有效審查者不足 3 個

【最終報告格式】照抄下面這些標題。你所在的環境若規定用某個工具交回報告（例如 SubagentHandback），就用那個工具交這份報告。
【派工】派了幾個（代號、方向；重派、補派各幾個）、為什麼派這麼多
【讀檔檢查】每個審查者：過／沒過（抽查了哪一處）；重派、補派了哪些
【採納（重大）】每條：來源代號（例如 輪1-R2-3）｜內容｜查證：path:行 或 grep 結果｜計畫要怎麼改
【採納（小事）】每條：來源代號｜內容｜計畫要怎麼改
【駁回】每條：來源代號｜內容｜一句理由
【需使用者決定】每條：來源代號｜問題｜選項｜建議答案｜為什麼文件沒寫明｜卡住哪條重大（沒有就寫「無」）
【需要外部查證】每條：來源代號｜嚴重度｜內容
【結論】通過 ／ 不通過（N 條重大） ／ 無法判定（<原因>）

常見錯誤