代理团队选择器

在项目执行前，先设计一个聚焦的多代理方案。只选择那些能实质提升结果的角色，以此兼顾速度、正确性和低缺陷率。

模式

• 默认使用 recommend 模式：只返回团队方案。
• 只有当用户明确要求委派或运行代理，并且当前运行时确实提供了子代理工具时，才使用 execute 模式。否则，要明确说明这只是推荐方案。

工作流

1. 提取目标结果、可持续交付物、现有代码库背景、涉及领域、具体风险、验证需求，以及用户优先级（速度、成本或把握度）。对未给出的约束一律视为未知，不要自行补造。
2. 评估推荐置信度：当目标、范围和风险面都清楚时为 high；当缺少一个关键细节但仍能给出安全的临时团队时为 medium；当目标、系统边界或风险面不清楚时为 low。
3. 选择模式，并将工作归类为 tiny、small、medium、large 或 high-risk。若置信度低，应选择探索型团队，并给出有边界的最佳猜测，而不是假装已经知道最终实现团队。
4. 对清晰、低风险的请求走 Fast Path。否则，阅读 references/selection-rules.md。只有当某个预设与请求高度匹配时才读取 references/team-presets.md，并把它视作起点而不是固定答案。只有在需要解释陌生或自定义角色时才读取 references/subagent-library.md。
5. 先从该任务规模对应的最小基线团队开始。只有在某个已命名的失败模式没有被当前角色覆盖时，才加入专家角色。若两个角色职责高度重叠，优先保留一个。
6. 对每个入选角色，都要定义不重叠的职责、具体产出物，以及交接接收方。缺少其中任意一项的角色应移除。
7. 将有依赖关系的工作拆成若干波次。在 execute 模式下，遵守运行时并发上限，只有前置产物存在后才分配后续工作。
8. 明确最终验证和集成的归属。main 只能作为协调者，不计入执行工人。

只有在校准或修订这个 skill 时才读取 references/evaluation-cases.md；日常推荐不要加载它。

Fast Path

• 如果请求只想获得团队建议，并不要求委派交付，就推荐不启用任何 worker。
• 如果是已知范围内的微小本地修改，选择 coder、reviewer。
• 如果是已知行为变更且存在回归风险，选择 coder、tester、reviewer；只有当执行顺序或验收标准不明确时，才额外加入 planner。
• 遇到陌生领域、跨模块工作、信任或数据边界、发布、迁移、约束冲突，或任何 medium/low 置信度请求时，退出 Fast Path。

默认倾向

• 对微小本地修改，优先使用 coder 和 reviewer；只有当任务拆解会改变结果时才加入 planner。
• 当正确性依赖可观察行为、边界情况、集成、UI、数据或回归风险时，加入 tester。
• 只有在涉及跨模块边界、迁移、新系统、多消费方契约或长期结构决策时，才加入 architect。
• 只有存在具体风险面时才加入专家角色，并说明它覆盖的失败模式。
• 若用户给出团队人数上限，应视为硬约束；否则，小型任务目标为 2–3 个 worker，中型任务 3–5 个，大型或高风险任务 4–6 个。

输出格式

返回以下分区。当第 4 和第 5 部分没有实际价值时，可以省略。

1. 模式、置信度与假设：说明是 recommend 还是 execute；置信度是 high、medium 还是 low；只列出关键假设。
2. 推荐代理团队：列出角色、职责、交付物，以及覆盖的失败模式。
3. 为什么是这个团队：用简洁的决策路径说明，从请求信号如何映射到所选角色，并与用户优先级对应起来。
4. 输入诊断与最佳安全猜测：在 medium 或 low 置信度下，最多指出三个缺失事实，标明是哪段请求表述导致了这个缺口，解释它会如何影响角色选择，再给出最小安全的临时团队和条件式的后续角色。这里要包含一句可直接粘贴补全的信息模板，而不是泛泛地要求“请补充更多信息”。
5. 执行顺序：给出考虑依赖关系的波次安排、交接关系、协调者以及最终验证。
6. 未选择的代理：只列出值得一提的未选角色及其排除原因。
7. 建议提示词：使用用户语言给出一段可直接粘贴的 prompt，要求写明范围、角色、交付物、文件所有权边界、交接方式、验收检查和冲突升级规则。

护栏规则

• tiny 任务要控制在 0–2 个 worker；如果委派带来的额外开销大于价值，就直接推荐不组团队。
• 不要仅因为某个预设里有某角色就选它。除非交付物明确不同，否则不要同时选择泛化角色和其专家角色。
• 除非运行时确实暴露了子代理工具，且用户明确要求执行，否则不要暗示子代理已经可用或正在运行。
• 如果置信度低，不要强行套预设，也不要声称已经知道确定的实现团队。应推荐最小探索团队，通常是 requirements-analyst 加 researcher 或 codebase-explorer；同时给出带明确条件的、有边界的最佳猜测，例如“如果这是一个已有的浏览器应用，则加入 frontend 和 tester。”
• 如果置信度是 medium，要明确假设、选择一个临时小团队，并指出最可能改变团队构成的那一个不确定因素。
• 面对不完整输入时，不要只回复“请补充更多信息”。要诊断缺失字段、说明它对选择的影响，并给出一种简洁的补充方式。
• 不要创造当前运行时或当前请求并不支持的角色名、交付物或执行承诺。

快速解答

• 为什么一个常见角色没有被选中？ 说明它负责的失败模式已经被哪个已选角色覆盖，或者直接指出当前请求并没有暴露与它相关的风险面。
• 为什么不用预设？ 当请求和预设不够贴合时就不要用。要说明不匹配点，并改用选择算法来推导。
• 什么时候应该要求更多信息？ 当缺失的目标、系统边界或风险信息会实质改变团队构成时，再要求补充；否则给出带标签的临时推荐。
• 请求太模糊时会怎样？ 给出探索型团队、条件式最佳猜测，以及一句可直接填写的补全模板；不要虚构项目事实。
• 给出推荐后会直接启动代理吗？ 不会。只有在 execute 模式下、用户明确要求且运行时支持时，才启动代理。