用途：按规划文档中的阶段顺序，逐阶段驱动实施与验证，直到全部阶段完成并产出最终 PR。它先读仓库配置文件，将工具链命令映射到当前仓库。
主要能力：每个阶段内执行实现、三层强制验证、提交、代码简化、再验证和设计评审。三层验证包括构建与类型检查与测试；启动服务并发送真实请求，将原始输出写入日志作为硬性门槛；以及对抗性验证。设计评审由父会话另行派发独立评审者，需达到设定分数。
使用方式：推荐带看门狗的调用为 /loop /agentloop:build-phases <planning-dir> [--start-phase <N>] [--review-target <score>]；直接调用为 /agentloop:build-phases <planning-dir> […] 。规划目录需含 tasks.md，可选 design.md。若计划放在 GitHub issue 中，可渲染临时 tasks.md 到临时目录运行，进度与日志不提交。
运行机制：父会话读写 .build-progress.json 作为持久状态，负责守门、评审派发与推进；每个阶段由一个背景子代理执行，完成后通过通知唤醒父会话，另有 30 分钟兜底唤醒。遇到真实设计分叉、不可解决失败、需外部凭据或不可逆架构决策时会升级停止；同一阶段连续重启 3 次也会停止。
限制：资料未提供收费、价格与具体平台支持细节；执行依赖对应仓库工具链与规划文档格式。