用途：按功能计划文件逐阶段实现功能。计划文件被拆分为多个阶段，每个阶段带任务复选框；技能一次只构建一个阶段，每阶段一个分支、一个 PR，先合入功能级集成分支，最后再合并到 main。
主要能力：从计划文件（而非记忆）出发，路径取自参数，否则在 plans/ 下查找；每阶段重新阅读计划。若存在未决决策则停止并让用户回到规划。阶段 1 前先读所有 Verify 行与 ## Demo。每个功能一个集成分支 integrate/<plan-name>，从最新的 main 切出并推送；每阶段从它切分支并以其为 PR 目标，main 不会出现半成品功能。单阶段计划则直接从 main 切 feat/<plan-name>，目标为 main。
使用方式：阶段 1 前通过 AskUserQuestion 询问构建模式。Solo（推荐）：自己写每个阶段，每轮用新的评审子代理。Orchestrator：每阶段用新的 worker 子代理，各自在独立 git worktree 中并行，仅勾选自己的复选框。随后按子代理角色询问模型，评审者始终询问，worker 仅在 Orchestrator 时询问。运行时无子代理工具则停止并让用户安装。worker 负责切分支、编写、验证、开 PR 并应用评审修复；你负责集成分支、评审、合并、报告与演示。评审每轮都在子代理中进行，每轮新子代理，不复用、不用写作者；共最多三轮，第 2 轮即使第 1 轮干净也要跑，第 3 轮仅在第 2 轮产生修复时跑。
验证与合并：PR 前本地验证，证明其兑现承诺并跑仓库检查（Makefile 有则 make build / make test / make lint，否则用项目原生命令）。需要部署主机、共享数据库或管理员登录时停止并询问。PR 目标为集成分支：gh pr create --base integrate/<plan-name>，绝不指向 main。合并需满足四项：最后一次修复提交后验证通过、已跑两轮（第 2 轮有修复则加第 3 轮）、无必须修复项、CI 通过（gh pr checks --watch）。用合并提交而非 squash，删除阶段分支。
适用场景：需要按计划分阶段、可评审地交付较大功能的开发流程。
限制：资料未提供具体安装命令、收费、价格与平台支持信息；无 gh 或 GitHub 远程时停在已推送分支，不伪造评审循环。