plan-review git:20261023.c5464d4A

Immutable. This exact content never changes and is served at /api/v1/blob/6cf625b796895afc.

---
name: plan-review
description: 計畫的對抗式審查：派一個裁決者（Opus），由它平行派至少 3 個審查者（haiku）猛攻計畫，再逐條查證哪些批評站得住，交回主對話修正迭代。複雜任務的計畫、task-planner 的段落草稿、design-brainstorm 的設計做好之後、交出去之前自動啟用；使用者說「審計畫」「審查這個計畫」「plan review」時也啟用。不適用於程式碼 diff 的審查（用 8 步迴圈步驟 4 的 code-review）、簡單或中等任務的計畫（design-brainstorm 的設計除外）。
allowed-tools: Agent, Read, Grep, Glob, Bash
---

# 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 輪還是 `不通過`：停下來，把剩下的重大缺失照實列給使用者，所有還沒問的「需使用者決定」一起問，
小事照改；**不要送第 4 輪，也不要自己開工**，接下來怎麼做由使用者決定。

### 4. 通過之後

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

### 問使用者的分批

第 3 步（不通過）、第 4 步（通過）、第 5 步（沒跑成）要問使用者時都照這條：呼叫端的題與「需使用者決定」加起來超過 4 題就分批
（AskUserQuestion 一次最多 4 題）。順序：會改到計畫的題 →「接下來怎麼做」（例如「照現稿繼續／停下」「重跑／不審直接交」）
→ 呼叫端寫明要等「接下來怎麼做」選完才問的題（例如 task-planner 在「沒跑成」那條路上的決策題）
→ 呼叫端標明要對著最終計畫問的題（例如 task-planner 的測試清單題）最後。同一件事只問一次。

### 5. 沒跑成

裁決者回錯誤、報告缺「結論」或自相矛盾、結論是 `無法判定`、或使用者說不等了：照實告訴使用者「計畫審查沒跑成」，
附原因（錯誤訊息原文或報告裡的原因），先問所有輪次還沒問的「需使用者決定」，再問要重跑還是不審直接交。重跑用同一個輪次重送，不算多一輪。
**不可以當成通過、靜默往下走。**

## 裁決者範本

````
你是計畫審查的裁決者，這是第 {輪次} 輪。你的工作分兩半：先派審查者去攻擊這份計畫，再反過來查證他們的每一條批評。
全程唯讀：只能讀檔、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 = 採納的重大缺失 + 需要外部查證裡重大的條數
- `無法判定（<原因>）`：有效審查者不足 3 個

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

## 常見錯誤

| 錯誤 | 正確做法 |
|---|---|
| 裁決者還沒回來就自己先審、先往下做 | 等完成通知 |
| 把「我判斷元凶是 X」寫進事實 | 只交事實；推測標明是推測 |
| 主對話把範本裡的 `《…》` 也填掉 | 那是裁決者填的，原樣保留 |
| 第 2 輪只送改好的計畫 | 附上前幾輪的裁決報告、「這輪改了哪裡」、還沒問的題 |
| 第 3 輪還不通過，繼續送第 4 輪 | 停下來列給使用者 |
| 通過後又問使用者「計畫可以嗎」 | 只問「需使用者決定」的題，然後接著做（使用者自己的規則要求批准時例外，見第 4 步） |
| 裁決者沒回來或結論是「無法判定」，當成通過往下走 | 照實說「計畫審查沒跑成」 |