用途：按批次执行已制定好的实施计划，通过检查点保证进度可见与质量可控。
主要能力：
- 批次执行：每批 3 个任务，执行完一批后设检查点再进入下一批。批次大小 3 的理由是形成自然的检查节奏（约每 6-10 分钟一次）、问题早发现、进度百分比易跟踪（33%、66%、100%）。
- 检查点验证：每批后核对测试、构建、Lint、类型检查与代码质量（DRY、安全、健壮性、YAGNI）。示例命令：npm test、npm run build、npm run lint、tsc --noEmit。检查点同时作为质量门、进度标记、评审机会与回滚点。
- 进度跟踪：记录已完成批次/任务、当前批次、剩余批次、状态、阻塞与风险，并对比实际耗时与估算。
- 架构师评审：在复杂架构决策、安全关键改动、API 契约破坏性变更、数据库模式变更、性能关键代码、新增外部依赖或偏离原计划时升级评审，等待决策后再继续。
使用方式：把计划中的任务按 3 个一组分批，顺序执行；每批结束写检查点，逐项验证；判断是否需要架构师评审，需要则升级并记录问题，不需要则进入下一批；重复直至全部批次完成。
适用场景：执行实施计划、运行多任务工作流、通过检查点跟踪进度、与架构师/负责人评审协作。
限制与不适用：不用于创建计划（应使用 writing-plans 技能），不用于调试（应使用 systematic-debugging 技能）。检查点发现质量问题时应停止执行、定位根因、在当前批次修复并重新验证；安全违规（硬编码密钥、输入未参数化）视为阻塞，须立即修复。检查点严重失败（大量测试失败、构建失败）时应停止并回滚到上一个已知良好状态。任务被阻塞时记录阻塞、可跳过到下一个未阻塞任务，稍后返回。批次内任务依赖可接受，跨批次依赖需在检查点中体现。若批次很快完成（总时长少于 5 分钟）可合并下一批。
相关资源：writing-plans、verification-protocol、code-conventions、code-review、systematic-debugging。