用途：把已写好的计划文件稳定地转化为实施结果，核心策略为“批量执行 + 每批暂停反馈”，防止一次性做完导致的偏离或风险累积。
主要能力：先读取并批判性审查计划，检查是否缺少依赖（安装包、环境变量、外部服务）、任务粒度是否过大、是否缺少验收标准或验证命令、任务顺序是否明显错误；发现问题时先停下，用 1-3 条要点提出疑虑，等人确认后再执行。随后按批次执行，默认每批 3 个任务，每个任务标记 in_progress、严格按计划执行不扩大范围、按计划运行验证（测试/构建/类型检查/lint/人工验证步骤）、再标记 completed。状态写入 logs/state.json，或在计划文件中维护 [ ]→[x] 清单并记录验证结果。每批结束后报告三件事：改动了什么、运行了哪些验证及结果、下一批是哪 3 个任务，最后一行必须为 Ready for feedback. 然后等待人工反馈，不自动继续。收到反馈后，需修改则先修复并重新验证再继续；反馈通过则进入下一批。全部完成后运行完整测试/构建，写 05-final/summary.md（做了什么、如何验证、风险与回滚、后续步骤），并做技能演化检查点，必要时运行 skill-improver 生成最小补丁建议；若存在 finishing-a-development-branch 技能则按其实施合并/PR/清理。
推荐输入为路径：plan_path（通常位于 run_dir/03-plans/）、repo_root、run_dir；输出为计划执行状态（logs/state.json 或 03-plans/<plan>-status.md）及每批验证证据（追加到计划文件或 05-final/ 总结）。
适用场景：需要按已写计划分步落地、每步可验证可回滚的开发任务，尤其跨模块或风险较高的改动。
限制与硬性规则：遇到中途阻塞（缺依赖、环境错误、权限问题）、测试失败且无法快速定位原因、计划步骤不清晰、出现可能导致数据丢失或大范围副作用的操作而计划未包含确认点时，必须立即停止执行并报告；不要“边猜边做”，计划不清晰时应先澄清。