用途：编排一次大型、可并行的代码库改动。用户指令通过 $ARGUMENTS 传入。
主要能力与使用方式分为三阶段。第一阶段（研究规划）：调用 EnterPlanMode 进入计划模式，先派出前台子智能体深度调研指令涉及的代码范围、约定和调用点，再拆分为 5–30 个自包含工作单元。每个单元需可在隔离 git worktree 中独立实现、可单独合并、体量大致均匀；单元数量按实际工作量缩放（少量文件接近 5，数百文件接近 30），优先按目录或模块切分。同时确定端到端验证方案，可选用浏览器自动化、tmux/CLI 验证、dev-server + curl 或现有 e2e 测试套件；若找不到具体 e2e 路径，需用 AskUserQuestion 询问用户并给出 2–3 个选项。计划文件应包含调研摘要、编号工作单元列表、e2e 配方和共享 worker 指令模板，最后 ExitPlanMode 提交审批。
第二阶段（派发 worker）：计划获批后，为每个单元用 Agent 工具启动后台智能体，全部使用 isolation: "worktree" 和 run_in_background: true，并在同一条消息中并行启动。每个提示需完全自包含，包含总目标、单元任务、代码约定、e2e 配方，以及固定的 worker 指令：完成实现后依次做代码审查（调用 Skill 工具 skill: "code-review" 并修复发现的问题）、运行单元测试、端到端测试、提交推送并用 gh pr create 创建 PR，最后以 PR: <url> 单行报告；无 PR 则输出 PR: none — <原因>。除非有更具体类型，subagent_type 使用 "general-purpose"。
第三阶段（跟踪进度）：启动后渲染初始状态表（#、Unit、Status、PR），随后台完成通知解析 PR 行并更新表格状态与链接，记录失败原因；全部完成后输出最终表格与一行总结。
限制：worker 无法自行询问用户，需由协调者提前确认验证方式；若 gh 不可用或推送失败，仅能在报告中注明。资料未提供定价、平台或更多配置细节。