workflow-execute-plans

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

目标

可靠地将“书面计划文件”转化为实施结果，避免一次性完成所有工作所带来的偏差或风险累积。

核心策略：批量执行 + 每批完成后暂停并征求反馈。

输入/输出（推荐用于串联）

输入（仅传递路径）：

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

输出（持久化）：

• 计划执行状态：logs/state.json（或 03-plans/<plan>-status.md）
• 每批的验证证据：追加到相应计划文件或 05-final/ 摘要中

执行流程

步骤 1）阅读并审查计划（先进行关键审查）

1. 阅读 plan_path
2. 检查计划是否存在以下问题：
   • 缺少依赖项（待安装的软件包/环境变量/外部服务）
   • 任务粒度过大（无法验证、难以回滚）
   • 缺少验收标准或验证命令
   • 任务顺序明显不合理
3. 如果发现关键问题：先停止，用 1–3 条要点说明问题，并让人工确认后再开始执行。

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

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

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

对于每个任务：

1. 标记为 in_progress
2. 严格按照计划执行（不要扩大范围）
3. 按计划运行验证（测试/构建/类型检查/代码检查/手动验证步骤）
4. 标记为 completed

状态记录（任选其一，优先使用结构化方式）：

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

步骤 3）批次报告（必须暂停并征求反馈）

每批完成后，报告以下三项：

• 变更内容：更改了哪些文件/实现了什么（简要说明）
• 验证：运行了哪些验证、结果如何（仅提供关键信息，不要贴出冗长日志）
• 下一批：接下来的 3 个任务

可选但推荐：

• 使用 review-merge-readiness 对本批次进行最终审查（尤其是在涉及跨模块更改、高风险更改或即将合并时）

最后一行必须是：

等待反馈。

然后等待人工反馈，不要自动继续下一批。

步骤 4）根据反馈继续

• 如果反馈要求修改：先修复并重新验证，然后继续下一批
• 如果反馈确认无误：继续下一批（仍默认每批 3 个任务）

步骤 5）收尾（全部完成后）

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

• 运行完整测试/构建（遵循项目惯例）
• 编写 05-final/summary.md（完成内容/验证方式/风险与回滚/后续步骤）
• 执行 skill-evolution 的 Evolution checkpoint（3 个问题）；如果用户选择“想要优化”，则基于此 run_dir 运行 skill-improver，生成最小化的补丁建议
• 如果存在 finishing-a-development-branch skill：遵循该 skill 完成合并/PR/清理选项

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

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

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

请牢记

• 开始前先严格审查计划
• 小批量执行（默认每批 3 个任务）
• 每批都必须验证并报告，然后等待反馈
• 遇到阻碍时停止，不要猜测