workflow-execute-plans

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Executing Plans (Batch Execution + Checkpoints)

执行计划（批量执行+检查点）

Goal

目标

Reliably turn a "written plan file" into implementation results, avoiding drift or accumulated risk from doing everything at once.

Core strategy: Batch execution + pause for feedback after each batch.

将“书面计划文件”可靠地转化为实施成果，避免一次性执行所有任务导致的偏差或累积风险。

核心策略：批量执行 + 每批完成后暂停等待反馈。

Input/Output (Recommended for Chaining)

输入/输出（推荐用于链式调用）

Input (pass paths only):

```
plan_path
```
: Plan file (usually in
```
run_dir/03-plans/
```
)
```
repo_root
```
```
run_dir
```

Output (persisted):

Plan execution status:

logs/state.json

(or

03-plans/<plan>-status.md

)

Per-batch verification evidence: append to the corresponding plan file or
```
05-final/
```
summary

输入（仅传递路径）：

```
plan_path
```
：计划文件（通常位于
```
run_dir/03-plans/
```
）
```
repo_root
```
```
run_dir
```

输出（持久化存储）：

计划执行状态：

logs/state.json

（或

03-plans/<plan>-status.md

）

每批验证依据：追加到对应计划文件或
```
05-final/
```
汇总文件中

Execution Flow

执行流程

Step 1) Read and Review Plan (Critical Review First)

步骤1）阅读并审核计划（先进行严格审核）

Read
```
plan_path
```
Review if the plan has these issues:
- Missing dependencies (packages to install/env vars/external services)
- Task granularity too large (can't verify, hard to rollback)
- Missing acceptance criteria or verification commands
- Obviously wrong task ordering
If critical issues found: Stop first, present concerns as 1-3 bullet points, let human confirm before starting execution.

Rule: Don't "guess while doing". Clarify when plan is unclear.

读取
```
plan_path
```
中的计划
检查计划是否存在以下问题：
- 缺少依赖项（需安装的包/环境变量/外部服务）
- 任务粒度太大（无法验证、难以回滚）
- 缺少验收标准或验证命令
- 任务顺序明显错误
如果发现严重问题：立即停止，将问题整理为1-3个要点列出，等待人工确认后再开始执行。

规则：不要“边做边猜”。计划不明确时先澄清。

Step 2) Batch Execution (Default 3 Tasks per Batch)

步骤2）批量执行（默认每批3个任务）

Execute the first 3 tasks from the plan, then stop and report.

For each task:

Mark as
```
in_progress
```
Execute strictly per plan (don't expand scope)
Run verification per plan (tests / build / typecheck / lint / manual verification steps)
Mark as
```
completed
```

Status recording (choose one, prefer structured):

Update task status in
```
logs/state.json
```
Or maintain checklist in
```
plan_path
```
(
```
[ ]
```
→
```
[x]
```
), recording verification results alongside

执行计划中的前3个任务，然后停止并汇报。

每个任务执行流程：

将任务标记为
```
in_progress
```
严格按照计划执行（不要扩大范围）
按照计划运行验证（测试/构建/类型检查/代码扫描/手动验证步骤）
将任务标记为
```
completed
```

状态记录（二选一，优先选择结构化方式）：

在
```
logs/state.json
```
中更新任务状态
或在
```
plan_path
```
中维护检查清单（
```
[ ]
```
→
```
[x]
```
），同时记录验证结果

Step 3) Batch Report (Must Pause for Feedback)

步骤3）批量报告（必须暂停等待反馈）

After each batch, report three things:

What changed: Which files changed/what was implemented (brief)
Verification: What verification was run, what were the results (key info only, no long logs)
Next batch: Which 3 tasks are next

Optional but recommended:

Use
```
review-merge-readiness
```
for a conclusive review on this batch (especially for cross-module changes, risky changes, or approaching merge)

Last line must be:

Ready for feedback.

Then wait for human feedback—don't automatically continue to next batch.

每批任务完成后，汇报三项内容：

变更内容：修改了哪些文件/实现了什么功能（简要说明）
验证情况：执行了哪些验证，结果如何（仅关键信息，无需冗长日志）
下一批任务：接下来要执行的3个任务是什么

可选但推荐操作：

对当前批次执行
```
review-merge-readiness
```
进行最终审核（尤其是跨模块变更、高风险变更或接近合并阶段时）

最后一行必须为：

等待反馈。

然后等待人工反馈——不要自动继续执行下一批任务。

Step 4) Continue Based on Feedback

步骤4）根据反馈继续执行

If feedback requests changes: fix first, re-verify, then continue next batch
If feedback is OK: continue to next batch (still default 3 tasks)

如果反馈要求修改：先完成修改，重新验证，再继续执行下一批任务
如果反馈通过：继续执行下一批任务（仍默认每批3个任务）

Step 5) Wrap Up (After All Complete)

步骤5）收尾（所有任务完成后）

When all tasks are complete and verified:

Run full tests/build (per project conventions)
Write
```
05-final/summary.md
```
(what was done/how verified/risks & rollback/next steps)
Do a
```
skill-evolution
```
Evolution checkpoint (3 questions); if user chooses "want to optimize", run
```
skill-improver
```
based on this
```
run_dir
```
to produce minimal patch suggestions
If
```
finishing-a-development-branch
```
skill exists: follow that skill to complete merge/PR/cleanup options

当所有任务完成并通过验证后：

按照项目规范运行完整测试/构建
编写
```
05-final/summary.md
```
（内容包括：完成的工作/验证方式/风险与回滚方案/下一步计划）
进行
```
skill-evolution
```
进化检查点（3个问题）；如果用户选择“需要优化”，基于当前
```
run_dir
```
运行
```
skill-improver
```
生成最小化补丁建议
如果存在
```
finishing-a-development-branch
```
技能：遵循该技能完成合并/PR/清理操作

When to Stop and Ask for Help (Hard Rules)

何时停止并寻求帮助（硬性规则）

Encounter any of these, stop execution immediately and report the issue:

Blocked mid-way (missing dependency, wrong environment, permission issues)
Tests/verification failed and can't quickly identify the cause
Plan step unclear (can't determine correct implementation approach)
Action that could cause data loss or wide-ranging side effects appears but plan doesn't include confirmation point

遇到以下任何一种情况，立即停止执行并汇报问题：

执行中途受阻（缺少依赖项、环境错误、权限问题）
测试/验证失败且无法快速确定原因
计划步骤不明确（无法确定正确的实施方式）
计划中出现可能导致数据丢失或广泛副作用的操作，但未包含确认环节

Remember

注意事项

Review plan critically before starting
Small batch execution (default 3 tasks)
Every batch requires verification and reporting, then wait for feedback
When blocked, stop—don't guess

开始执行前先严格审核计划
小批量执行（默认每批3个任务）
每批任务都需要验证和汇报，然后等待反馈
受阻时立即停止——不要猜测