用途：为给定任务组建合适的智能体团队。它不会询问用户偏好或范围，而是从任务描述与代码库上下文中推断。
主要能力与流程： 一、分析任务：判断任务类型（如 feature、bugfix、refactor、review、migration、investigation）、涉及范围（借助 git status、git diff、文件读取与 grep 判断影响面）、可并行部分与依赖关系、风险级别（是否触及关键路径、共享状态或公开 API）以及知识盲区。若已有计划、ADR 或任务列表，则以其为主要输入。必要时探索代码库，陌生模块、约定待确认或依赖不清时尤其需要，独立区域可并发探索。此分析为静默进行，不作为独立步骤展示给用户。 二、提出团队组成：以表格形式向用户展示团队名称、角色、名称、职责与隔离方式（worktree / shared），并用一两句话说明理由。团队规模按最小可行原则：简单单文件改动或显而易见的小修复用单个 agent（可改用 subagent 后退出）；两个明确独立的工作流用 2 个 agent；需要构建/评审分离或跨层工作用 3 个；大型迁移、多模块重构或并行调查竞争假设可用 4 个以上，且每个额外 agent 必须有明确不同的职责。角色示例包括 implementer、reviewer、test-writer、investigator、architect、migrator，这些只是示例而非固定菜单。当 agent 会编辑重叠文件或同一模块时使用 worktree 隔离，文件集合完全独立时使用 shared。 三、确认：通过 AskUserQuestion 呈现方案，用户可批准、调整（改角色、增减 agent、改职责后重新呈现）或取消。 四、创建团队：确认后用 TeamCreate 创建团队，用 TaskCreate 为每个 agent 创建任务，再用 Agent 工具启动每个 agent，参数包括符合 DoR/DoD 结构的提示词、与角色名一致的 name、使其加入同一团队的 team_name、方案中指定的 isolation: "worktree"，以及可并行时的 run_in_background: true。最后简要告知用户团队已运行。
每个 agent 的提示词必须包含 Definition of Ready（收到的具体输入，如变更文件 diff、待评审文件、架构决策）与 Definition of Done（明确无歧义的完成标准，如测试全部通过、以要点列表报告评审发现）。DoR 可为具体制品，也可为范围明确的调查指令；完成前需逐项核对 DoD。
限制与注意事项：团队规模保持最小可行，宁少而多做，不多而少做；每个提示词都必须有 DoR/DoD；不要自行关闭团队，agent 会保留以供后续跟进，任何关闭前需先询问用户；执行中如发现可并行的子任务，可向用户建议增派 agent。
其他：官方文本与收费、价格、平台要求等信息暂未提供。