Plan review before implementation. Review four dimensions section by section; for each issue, give options and recommendations, and only proceed to the next section after confirmation.
Positioning: Review the plan itself (task breakdown, direction, risks), not code review. For code-level review, use /code-review。
Step 0: Locate the plan + Choose depth
Locate the plan
Search in order of priority:
- Path specified by ARGUMENTS → read directly
codex-plan.md(current directory) → codex-plan output.claude/plans/→ take the latest.mdfile- If none found → use AskUserQuestion to ask the user to specify
After reading the plan, summarize the core objective (1-2 sentences) and confirm the review target is correct.
Read related code
Target Files / modified files mentioned in the plan → read all. Without looking at the existing code, you cannot judge whether the plan is reasonable.
Choose review depth
Use AskUserQuestion to ask:
- Deep review: Up to 4 issues per section, suitable for large features or architectural changes
- Quick review: Up to 1 issue per section, suitable for small changes or limited time
Step 1-4: Four-section review
Execute in order. After each section is completed, use AskUserQuestion to confirm the decision, then proceed to the next section.
Section 1: Completeness
Is anything missing from the plan?
- Is the task breakdown detailed enough—can each task be completed within a single commit?
- Are the dependencies between tasks correct? Are there circular dependencies or ordering errors?
- Are necessary steps missing (DB migration, config changes, environment variables, documentation updates)?
- Does the Mermaid dependency diagram (if any) reflect the actual dependencies?
Section 2: Direction
Is the direction correct? Is there a better approach?
- Can the existing code already solve the problem? When the plan proposes creating a new service / new module / new migration, check whether the existing code already has the required functionality—so it only needs to be wired up or extracted. This is the highest-priority check: one insight can compress 4 phases into an 80-line change.
- Is the chosen architectural pattern suitable for the scale of the problem? Is there a simpler alternative?
- Is the technology choice reasonable? Does it conflict with the conventions of the existing codebase?
- Is the list of modified files correct? Are any files that should be changed missing, or are files being changed that should not be?
- Is the proposed API / interface design clear and consistent?
Section 3: Risks
Where might things go wrong?
- Which steps carry the highest risk? What are the consequences of failure?
- Is there a rollback strategy? Can it be deployed gradually (feature flag, canary)?
- Has backward compatibility been considered? Will it break existing users or API consumers?
- Does the test strategy cover the critical paths? Are there any missed edge cases?
Section 4: Scope
Is the scope reasonable?
- Does it exceed the original requirements? Has unnecessary refactoring or functionality been smuggled in?
- Is there insufficient engineering? Has work that should have been done been lazily skipped (error handling, input validation, testing)?
- Is the task granularity appropriate? Tasks that are too coarse should be split, and those that are too fragmented can be merged
- Is the estimated complexity reasonable? Are there parts that have been underestimated?
- Does the plan explicitly list "NOT in scope"? If not, proactively suggest adding it—list the related work that is excluded and the reasons for exclusion. This can prevent scope creep during implementation and is often more valuable than the plan itself.
Issue presentation format
Each issue must include:
- Problem description — Specifically point out which task/step in the plan, citing file paths (if relevant)
- Options — 2-3 options (including "do not address"), each labeled with:
- Impact on the plan (how many tasks need to change? Steps added or removed?)
- Risk change (increased or decreased?)
- Implementation cost change
- Recommendation — The recommended option and the reason
Output example
### 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 format
At the end of each section, use AskUserQuestion:
- Option labels indicate issue number + option letter
- Put the recommended option first
- Deep mode example:
1A + 2B + 3A - Quick mode directly uses option letters
Step 5: Revision suggestions
After the four-part review is complete, output:
## 計畫審查摘要
| # | 維度 | 議題 | 決策 |
|---|------|------|------|
| 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 版本淘汰** — 需協調下游消費者，不適合綁在一起
Review principles
- Complete but not verbose — Missing steps should be added, but do not make simple things complicated
- The simplest correct solution — If there is a simpler approach, propose it
- Risk awareness — High-risk steps must have a fallback
- Scope discipline — Scope creep is not allowed, nor is laziness
Now Execute
The user's review request is below ARGUMENTS:. Start from Step 0.