用途：把“书面计划文件”可靠地转化为实施结果，核心策略是分批执行加检查点，每批结束后暂停并等待人工反馈，避免一次性完成带来的偏移与风险累积。
输入输出：输入仅传路径，包括 plan_path（计划文件，通常在 run_dir/03-plans/）、repo_root、run_dir。输出持久化保存，计划执行状态写入 logs/state.json（或 03-plans/<plan>-status.md），每批验证证据追加到对应计划文件或 05-final/ 汇总。
执行流程：第一步读取并批判性审阅计划，检查是否缺少依赖（待安装包、环境变量、外部服务）、任务粒度过大无法验证或回滚、缺少验收标准或验证命令、任务顺序明显有误；发现关键问题先停下，用 1-3 条要点提出疑虑，等人确认后再执行，规则是不明处不要“边猜边做”。第二步分批执行，默认每批 3 个任务，每个任务标记 in_progress，严格按计划执行不扩大范围，按计划运行验证（测试、构建、类型检查、lint 或人工验证步骤），再标记 completed，状态记录用 logs/state.json 或计划文件中的清单（[ ]→[x]）并附带验证结果。第三步每批写报告，必须暂停等待反馈，报告三件事：改动内容（哪些文件、实现了什么）、验证情况（运行了什么、结果如何，只给关键信息）、下一批是哪些 3 个任务；可选但推荐使用 review-merge-readiness 对本批做结论性审查，尤其涉及跨模块、有风险或接近合并时。报告最后一行必须是“Ready for feedback.”，然后等待人工反馈，不自动继续。第四步按反馈决定：要求修改则先修复并重新验证再继续；反馈通过则进入下一批，仍默认 3 个任务。第五步全部完成并验证后，按项目惯例运行完整测试/构建，写 05-final/summary.md（做了什么、如何验证、风险与回滚、后续步骤），执行 skill-evolution 检查点（3 个问题），若用户选择优化则基于该 run_dir 运行 skill-improver 输出最小补丁建议；若存在 finishing-a-development-branch 技能，按其完成合并、PR 或清理选项。
硬性停止规则：遇到以下情况立即停止并报告——中途受阻（缺少依赖、环境错误、权限问题）、测试或验证失败且无法快速定位原因、计划步骤不清晰无法确定正确实现方式、出现可能造成数据丢失或大范围副作用但计划中没有确认点。
限制：所有具体命令、依赖项和验证方式均以计划文件为准；资料未提供默认批次大小以外的参数、支持平台或额外配置说明。