subagent-orchestrator

子 Agent 编排器

为用户请求的任务组建一支临时子 Agent 团队。让主线程专注于范围、决策和综合整理，同时由委派的 Agent 处理边界明确的工作。

运行模式

• 仅当用户明确要求使用子 Agent、委派任务、并行工作或组建临时团队时，才使用此技能。
• 将对 $subagent-orchestrator 的明确调用视为使用子 Agent 的许可。
• 将团队组建首先视为规划问题，其次才是执行问题。
• 优先采用职责明确、归属清晰的角色式委派，而非临时随意生成 Agent。
• 避免让嘈杂的中间工作占用主线程，改为返回摘要，而非原始 Agent 讨论记录。

资源索引

先阅读 references/roles-index.md。然后仅加载与任务匹配的角色文件和模式文件。

• 角色约定和扩展规则：references/role-contract.md
• 角色注册表：references/roles-index.md
• 团队模式：references/team-patterns.md
• 核心角色：
  • references/role-lead.md
  • references/role-planner.md
  • references/role-explorer.md
  • references/role-implementer.md
  • references/role-reviewer.md
  • references/role-tester.md
  • references/role-integrator.md

团队模式

组建团队前，先选择一种模式：

• assemble-only：构建成员名单、职责归属图和执行顺序，不启动工作。
• assemble-and-run：组建团队并立即执行。用户要求现在完成任务时，默认使用此模式。
• reuse-team：继续使用仍保有相关上下文的活跃子 Agent。如果没有合适的活跃团队，则改用 assemble-and-run。

编排工作流

除非用户要求更窄的交付内容，否则按以下顺序执行。

1. 明确任务

提取并重述：

• 用户目标
• 所需交付内容
• 限制、审批要求和安全边界
• 相关代码库、文件或工件
• 时间要求
• 期望的团队模式

如果请求未明确要求使用子 Agent，且未明确调用此技能，则不要生成子 Agent。应先询问，或采用单 Agent 流程继续处理。

2. 分类执行形态

为整个任务或各个切片选择一个标签：

• read-only：探索、审查、摘要整理、日志分析、测试问题分类、架构映射
• disjoint-write：多个归属清晰且相互交集较少的切片，例如不同模块或测试文件
• overlap-write：共享接口、热点文件、架构变更、路由层、核心类型或多个 Agent 可能会同时修改的配置

如果无法确定，选择限制更严格的标签。

3. 组建团队

按需阅读 references/roles-index.md 和 references/team-patterns.md。

遵循以下规则：

• 恰好选择一名 lead。
• 如果请求含糊、范围不明确，或可能需要在实现前冻结约定，则加入一名 planner。
• 对探索工作量较大的任务，加入一名或多名 explorer。
• 仅当每位写入者都能负责清晰界定的切片时，才加入 implementer。
• 如果行为可能发生变化，则加入一名 reviewer 和一名 tester 进行验证。
• 如果多位写入者会修改共享部分，或重叠风险并非微不足道，则加入一名 integrator。

优先采用注册表中的预设角色。如果没有合适的预设角色，则遵循 references/role-contract.md 编写临时角色说明。临时角色仅限当前任务使用，除非用户明确要求，否则不要保留。

4. 声明职责归属和交接

为每个子 Agent 定义：

• 任务
• 范围
• 负责的文件、模块或分析部分
• 禁止涉及的领域
• 所需工具或产物
• 预期交付成果
• 专家标准：在指定领域以最资深专家的标准行事，在负责范围内保持勤勉、严谨、恪守原则，并拒绝粗制滥造或越界的工作
• 停止条件
• 等待策略

对于写入工作：

• 每个热点或共享契约只指定一名写入负责人。
• 尽可能在并行实现前冻结共享接口。
• 将高风险的重叠工作改为两阶段流程：先并行提出方案，再进行实现。

5. 选择执行模式

使用第 2 步的分类：

• read-only：并行开展探索、审查或总结，然后进行综合。
• disjoint-write：按负责部分并行开展工作，然后集成并验证。
• overlap-write：先提出方案，再将共享实现交由一名指定写入负责人或 integrator 处理。

实现后，只要安全，就重新开放并行验证：

• reviewer 检查错误和回归问题
• tester 检查命令和边缘情况覆盖
• explorer 查找遗漏的调用点或依赖影响

6. 使用范围受限的提示词执行

为每个子 Agent 提供完成任务所需的最少任务上下文。

包括：

• 任务部分
• 负责范围
• 预期输出
• 约束和禁止涉及的领域
• 专家标准：像该任务部分最资深的专家一样行事，并在职责边界内保持勤勉、严谨、恪守原则
• 是等待还是独立继续

除非任务明确要求，否则不要泄露预期答案或隐藏的诊断信息。

7. 在主线程上综合

保持主线程简洁。

返回：

• 最终人员配置
• 执行类别和所选模式
• 职责归属图
• 关键发现或实现结果
• 未解决的风险和后续步骤

使用子 Agent 的摘要，而不是将原始日志复制到主线程。

写入安全规则

涉及代码更改时，始终遵循以下规则：

• 绝不让多个写入者同时编辑同一热点文件。
• 存在实际冲突风险时，将方案工作与写入工作分开。
• 架构变更、共享类型、公共 API 契约、迁移、中央配置和路由，都由一名指定写入负责人处理。
• 多个补丁必须协调落地时，使用 integrator。
• 只有在共享写入风险降低后，才重新并行处理。
• 优先采用较慢但可控的合并流程，而不是快速进行相互冲突的编辑。

输出结构

当用户要求团队计划，或需要总结编排过程时，请使用以下结构：

# Team Plan

## Objective
- <goal>

## Team Mode
- <assemble-only | assemble-and-run | reuse-team>

## Execution Class
- <read-only | disjoint-write | overlap-write>

## Roster
- <role>: <mission and owned scope>

## Handoffs
- <who waits on whom and why>

## Risks
- <conflict, ambiguity, or approval risks>

报告已完成的工作时，将 Handoffs 替换为 Results。

扩展角色库

将角色注册表用作插件系统。

添加新的永久角色：

1. 按照 references/role-contract.md 创建新的 references/role-<name>.md 文件。
2. 在 references/roles-index.md 中注册该角色。
3. 仅当新角色引入可复用的团队岗位或新的常见模式时，才更新 references/team-patterns.md。
4. 保持能力标签稳定，以便旧的选择逻辑继续有效。

优先根据能力标签和写入策略选择角色，而不要在主工作流中硬编码确切的角色名称。