plan-review

计划评审技能

目的

当用户运行 /plan-review {plan-file-path} 时，启动“对抗式计划迭代”工作流：

1. 我（Claude Code）请 Codex 对指定计划进行严格评审。
2. 我阅读 Codex 给出的评审结果，并判断其中的建议是否合理。
3. 我根据有效建议修订计划，并将更改写回原计划文件。
4. 如果评审状态为 NEEDS_REVISION，我会自动请 Codex 再次评审。
5. 重复以上流程，直到达成 MOSTLY_GOOD 或 APPROVED 共识。

用法

/plan-review plans/my-feature-plan.md

会话复用

每次调用 Codex 后，从脚本输出中提取 session_id=xxx，并将其保存为当前任务的会话 ID。在之后针对同一任务调用 Codex 时，传入 --session <id> 以复用上下文，让 Codex 记住此前的评审历史，并在多轮评审中保持一致。

我的工作流（Claude Code）

步骤 1：确定评审文件

根据计划文件名推导评审文件路径：

• plans/auth-refactor.md → reviews/auth-refactor-review.md
• 规则：reviews/{plan-file-name-without-.md}-review.md

如果评审文件已存在，说明这不是第一轮，因此 Codex 必须跟踪上一轮问题的解决状态。

步骤 2：请 Codex 评审计划

使用 /codex 技能，并向 Codex 提供以下指令：

Read the contents of {plan-file-path} and review it critically as an independent third-party reviewer.

Requirements:
- Raise at least 10 concrete and actionable improvement points
- Each issue must include: issue description + exact location/reference in the plan + improvement suggestion
- Use severity levels: Critical > High > Medium > Low > Suggestion
- If {review-file-path} already exists, read it first and track the resolution status of previous issues in the new round

Analysis dimensions, choosing the relevant ones based on the plan type:
- Architectural soundness: overdesign vs underdesign, module boundaries, single responsibility
- Technology choices: rationale, alternatives, compatibility with the existing project stack
- Completeness: missing scenarios, overlooked edge cases, dependency and impact scope
- Feasibility: implementation complexity, performance risks, migration and compatibility concerns
- Engineering quality: whether it follows the Code Quality Hard Limits in `CLAUDE.md`
- User experience: interaction flow, error/loading states, i18n when relevant
- Security: authentication, authorization, data validation when relevant

Append the current review round to {review-file-path}, creating the file if it does not exist.
Separate rounds with `---` and append new rounds at the end of the file. Use this format:

---

## Round {N} — {YYYY-MM-DD}

### Overall Assessment
{2-3 sentence overall assessment}
**Rating**: {X}/10

### Previous Round Tracking (R2+ only)
| # | Issue | Status | Notes |
|---|-------|--------|-------|

### Issues
#### Issue 1 ({severity}): {title}
**Location**: {location in the plan}
{issue description}
**Suggestion**: {improvement suggestion}
... (at least 10 issues)

### Positive Aspects
- ...

### Summary
{Top 3 key issues}
**Consensus Status**: NEEDS_REVISION / MOSTLY_GOOD / APPROVED

Key principle: be a critical reviewer, not a yes-man. Every issue must be specific enough that someone knows how to revise the plan.

首次创建评审文件时，在文件顶部添加以下标题：

# Plan Review: {plan title}

**Plan File**: {plan-file-path}
**Reviewer**: Codex

步骤 3：阅读评审并修订计划

Codex 完成后，我会阅读评审文件中最新一轮的内容：

1. 逐一评估 Codex 提出的问题。
2. 采纳有效建议并修订计划文件。
3. 如果拒绝不合理的建议，可在计划中简要说明原因。
4. 直接更新原计划文件，不要创建新文件。

步骤 4：决定是否继续迭代

根据 Codex 给出的 Consensus Status 决定：

状态	我的操作
NEEDS_REVISION	修订计划，然后自动请 Codex 再次评审，并返回步骤 2
MOSTLY_GOOD	修订计划，然后告知用户计划已基本成熟，并询问是否需要再进行一轮评审
APPROVED	告知用户计划已通过评审，可以开始实施

步骤 5：收尾

迭代完成后，向用户报告以下内容：

• 完成了几轮评审
• 哪些主要方面得到了改进
• 最终计划文件路径
• 评审日志文件路径

文件约定

• 每个计划对应一个评审文件：reviews/{topic}-review.md
• {topic} 是去掉 .md 的计划文件名
• 将所有轮次追加到同一文件，并用 --- 分隔
• 示例：plans/auth-refactor.md -> reviews/auth-refactor-review.md