Plan Review
實作前的計畫審查。四個維度逐段檢視，每個議題給選項和建議，確認後才進下一段。
定位：審查計畫本身（任務拆解、方向、風險），不是 code review。程式碼層面的審查請用 /code-review。
Step 0: 定位計畫 + 選擇深度
定位計畫
按優先順序尋找：
- ARGUMENTS 指定路徑 → 直接讀取
codex-plan.md（當前目錄）→ codex-plan 產出.claude/plans/→ 取最新的.md檔- 都找不到 → 用 AskUserQuestion 請使用者指定
讀取計畫後，摘要核心目標（1-2 句），確認審查對象正確。
讀取相關程式碼
計畫中提到的 Target Files / 修改檔案 → 全部讀取。不看現有程式碼就無法判斷計畫是否合理。
選擇審查深度
用 AskUserQuestion 詢問：
- 深度審查：每段最多 4 個議題，適合大型功能或架構變更
- 快速審查：每段最多 1 個議題，適合小改動或時間有限
Step 1-4: 四段審查
依序執行。每段完成後用 AskUserQuestion 確認決策，再進下一段。
第一段：完整性
計畫有沒有漏東西？
- 任務拆解是否足夠細——每個 task 能在一次 commit 內完成？
- 任務之間的依賴關係是否正確？有沒有循環依賴或順序錯誤？
- 是否遺漏必要步驟（DB migration、config 變更、環境變數、文件更新）？
- Mermaid 依賴圖（如有）是否反映實際依賴？
第二段：方向性
方向對不對？有沒有更好的做法？
- 現有程式碼是否已能解決問題？ 計畫提議建新 service / 新模組 / 新 migration 時，檢查現有程式碼是否已具備所需功能——只需串接或擷取即可。這是最高優先級的檢查：一個洞察就能把 4 個 phase 壓縮成 80 行改動。
- 選擇的架構模式是否適合問題規模？有沒有更簡單的替代方案？
- 技術選型是否合理？有沒有跟現有 codebase 的慣例衝突？
- 修改的檔案清單是否正確？有沒有漏掉該改的檔案，或改了不該改的？
- 提出的 API / 介面設計是否清晰且一致？
第三段：風險
哪裡可能出事？
- 哪些步驟風險最高？失敗的後果是什麼？
- 有沒有 rollback 策略？能不能漸進式部署（feature flag、canary）？
- 有沒有考慮向後相容？會不會破壞現有使用者或 API 消費者？
- 測試策略是否覆蓋關鍵路徑？有沒有遺漏的邊界案例？
第四段：範圍
範圍合理嗎？
- 是否超出原始需求？有沒有偷渡不必要的重構或功能？
- 是否工程不足？有沒有偷懶跳過該做的事（錯誤處理、輸入驗證、測試）？
- 任務粒度是否適當？太粗的 task 應拆開，太碎的可合併
- 估算的複雜度是否合理？有沒有被低估的部分？
- 計畫是否明確列出「NOT in scope」？ 如果沒有，主動建議補上——列出被排除的相關工作及排除理由。這能防止實作時 scope creep，往往比計畫本身更有價值。
議題呈現格式
每個議題必須包含：
- 問題描述 — 具體指出計畫中的哪個 task/step，引用檔案路徑（如相關）
- 選項 — 2-3 個選項（含「不處理」），每個標明：
- 對計畫的影響（需改幾個 task？加減步驟？）
- 風險變化（提高或降低？）
- 實作成本變化
- 建議 — 推薦的選項及理由
輸出範例
### 1. 完整性：缺少 DB migration 步驟
**問題**：Task 3 新增 `status` 欄位到 User model，但計畫沒有對應的
migration task。部署時會因為欄位不存在而失敗。
**選項**：
- **A) 在 Task 3 前插入 migration task**（建議）
影響：+1 task，Task 3 加 blockedBy | 風險：降低 | 成本：低
- **B) 合併進 Task 3**
影響：Task 3 變大 | 風險：不變 | 成本：零
- **C) 不處理**
影響：無 | 風險：部署失敗 | 成本：零
**建議 A**：migration 獨立一個 task 方便 rollback，且不混淆程式碼變更。
AskUserQuestion 格式
每段結束時用 AskUserQuestion：
- 選項標籤標示 議題編號 + 選項字母
- 建議選項放第一個
- 深度模式範例：
1A + 2B + 3A - 快速模式直接用選項字母
Step 5: 修訂建議
四段審查完成後，輸出：
## 計畫審查摘要
| # | 維度 | 議題 | 決策 |
|---|------|------|------|
| 1 | 完整性 | 缺少 DB migration | A: 插入獨立 task |
| 2 | 方向性 | 可用現有 middleware 取代自建 | A: 改用現有 |
| 3 | 風險 | 無 rollback 策略 | A: 加 feature flag |
| 4 | 範圍 | Task 7 偷渡重構 | B: 拆到獨立 PR |
### 建議修訂
- [ ] Task 2.5: 新增 migration for User.status（blocked by: Task 2）
- [ ] Task 4: 改用 existing authMiddleware，刪除自建邏輯
- [ ] Task 1: 加 feature flag ENABLE_NEW_AUTH
- [ ] Task 7: 移出計畫，另開重構 PR
### NOT in scope（建議補入計畫）
- **AuthService 重構** — 現行架構足夠，獨立 PR 處理
- **Email 驗證流程改版** — 與本次功能無關，避免牽動範圍
- **舊 API 版本淘汰** — 需協調下游消費者，不適合綁在一起
審查原則
- 完整但不囉嗦 — 漏步驟要補，但不要把簡單的事搞複雜
- 最簡單的正確方案 — 有更簡單的做法就提出來
- 風險意識 — 高風險步驟必須有 fallback
- 範圍紀律 — 不允許 scope creep，也不允許偷懶
Now Execute
使用者的審查請求見下方 ARGUMENTS:。從 Step 0 開始。