plan-review

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

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

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

什麼時候跑

情境	跑不跑
全域 §4.1 的複雜任務（N = 1；N ≥ 2 等 task-planner 出草稿時再跑），計畫寫好、要交出去之前	跑
task-planner 步驟 4，草稿（進度表、小任務、測試清單）出好之後	跑
design-brainstorm 設計逐段整理好、離開 plan mode 之前	跑
使用者說「審計畫」「審查這個計畫」	跑
簡單、中等任務	不跑（但走 design-brainstorm 的設計不論大小都跑）
審程式碼 diff	不跑（那是步驟 4 的 code-review）

步驟

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

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

2. 派裁決者

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

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

3. 照報告的「結論」走

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

結論	主對話做什麼
通過	走第 4 步
不通過（N 條重大）	見下方
無法判定（<原因>）	當成沒跑成，走第 5 步

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

不通過時：

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

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