plan-execute

计划执行技能

用途

当用户运行 /plan-execute {plan-file-path} 时，启动“编排式计划执行”工作流：

1. 我（Claude Code）让 Codex 按照计划实现代码。
2. Codex 完成后，我审查生成的代码。
3. 我将审查结果写入 reviews/ 目录，然后让 Codex 检查并修复问题。
4. 重复以上步骤，直到代码质量达到要求。

核心原则：我不会亲自编写或编辑代码。我只做两件事：审查代码和编排 Codex。所有代码更改，包括实现和修复，均由 Codex 完成。

用法

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

会话复用

每次调用 Codex 后，从脚本输出中提取 session_id=xxx，并将其保存为当前任务的会话 ID。之后为同一任务调用 Codex 时，传入 --session <id> 以复用上下文，让 Codex 记住之前的实现和修复记录，而不必每次都重新读取整个代码库。

我的工作流（Claude Code）

步骤 1：阅读计划并拆分执行步骤

阅读指定的计划文件并了解：

• 计划的整体目标和范围
• 要创建或修改的文件列表
• 实现步骤的顺序
• 相关的项目约定，尤其是 CLAUDE.md 中的约定

如果计划中已有检查清单（- [ ] / - [x]），就将清单项用作执行单元。 如果没有明确的步骤，则将工作拆分为合理的批次，每批更改的文件不超过 5 个。

步骤 2：让 Codex 实现代码

使用 /codex 技能，并向 Codex 发出以下指令：

Implement the code according to the plan in {plan-file-path}.

Current execution scope: {specific step or batch description}

Requirements:
- Follow the design in the plan exactly. Do not improvise beyond it.
- Obey the Code Quality Hard Limits defined in `CLAUDE.md`.
- Single file <= 800 lines, single function <= 50 lines, nesting <= 3 levels
- Run `pnpm build` after implementation to confirm compilation succeeds
- If the plan includes a checklist, mark completed steps as `[x]`

After implementation, list all changed files and provide a summary of each change.

步骤 3：审查 Codex 的输出（我的核心职责）

Codex 完成后，我会进行代码审查。重要：我只阅读代码并撰写审查意见，绝不直接修改源文件。

1. 阅读每个更改过的文件，并逐一审查。
2. 对照计划，确认实现符合预期设计。
3. 检查代码质量，包括：
   • 是否违反了代码质量硬性限制
   • 是否引入安全风险
   • 是否缺少错误处理
   • 命名和组织是否清晰
   • 是否遵循现有项目模式
4. 运行 pnpm build，确认编译状态。

步骤 4：撰写审查意见并将修复工作交回 Codex

将审查意见追加到 reviews/{topic}-review.md（与 plan-review 共享）：

---

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

**Scope**: {code scope covered in this review}
**Build Status**: PASS / FAIL

### Issues

#### Issue 1 ({severity}): {title}
**File**: {file-path:line}
{issue description}
**Fix**: {specific fix recommendation}

...

### Verdict: NEEDS_FIX / APPROVED

如果 Verdict: NEEDS_FIX，则调用 /codex，让 Codex 修复问题，而不是由我亲自编辑：

Read the latest Code Review round in {review-file-path}.
Check each issue one by one. Fix the valid issues, and explain why any disputed item is not actually a problem.
After making fixes, run `pnpm build` to confirm compilation succeeds.
List the issues that were fixed and the corresponding code changes.

如果 Verdict: APPROVED，则跳到步骤 6。

步骤 5：验证修复并迭代

Codex 应用修复后，我会再次审查，仍然不会直接编辑代码：

• 检查每个问题是否确实已修复
• 检查修复是否引入了新问题
• 如果仍有问题，则撰写新一轮审查意见，并交给 Codex 再次修复（重复步骤 4）
• 如果全部通过，则将审查标记为 Verdict: APPROVED

步骤 6：更新计划进度

每批工作完成后，让 Codex 更新计划文件中的检查清单（- [ ] -> - [x]）。 如果还有未完成的步骤，则返回步骤 2，处理下一批。 所有工作完成后，进入收尾阶段。

步骤 7：收尾

向用户报告以下内容：

• 已完成的步骤
• 代码审查进行了多少轮
• 修复的主要问题
• 最终构建状态
• 更改的文件列表
• 审查日志文件的路径

评审严重级别

级别	含义	必须修复
严重	导致运行时故障或安全漏洞	是
高	违反项目约定或存在明显的设计缺陷	是
中	应当改进的代码质量问题	建议
低	风格或偏好问题	可选
建议	优化建议	可选

结论规则：

• 如果存在任何严重或高级别问题 -> NEEDS_FIX
• 如果所有问题均为中级或以下 -> APPROVED，并附上可选的改进说明

文件约定

• 与 plan-review 共用同一个评审文件：reviews/{topic}-review.md
• {topic} 是去掉 .md 的计划文件名
• 计划评审轮次和代码评审轮次都追加到同一个文件中
• 使用标题区分：计划评审使用 ## Round {N}，代码评审使用 ## Code Review Round {N}