subagent-orchestrator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Subagent Orchestrator

Subagent编排器

Assemble a temporary team of subagents for a user-requested task. Keep the main thread focused on scope, decisions, and synthesis while delegated agents handle bounded work.

为用户请求的任务组建临时subagent团队。让主线程专注于范围管控、决策和结果整合，将边界清晰的工作委派给子代理处理。

Operating Mode

操作模式

Use this skill when the user explicitly asks for subagents, delegation, parallel work, or a temporary team.
Treat explicit invocation of
```
$subagent-orchestrator
```
as permission to use subagents.
Treat team assembly as a planning problem first and an execution problem second.
Prefer role-based delegation with explicit ownership over ad hoc spawning.
Keep noisy intermediate work off the main thread and return summaries instead of raw agent chatter.

当用户明确要求使用subagent、任务委派、并行工作或临时团队时使用本技能。
将显式调用
```
$subagent-orchestrator
```
视为使用subagent的许可。
优先将团队组建视为规划问题，其次才是执行问题。
优先采用带明确所有权的基于角色的委派，而非临时随机生成代理。
避免将冗长的中间工作输出到主线程，仅返回摘要而非代理的原始交互内容。

Resource Map

资源映射

Read references/roles-index.md first. Then load only the role and pattern files that match the task.

Role contract and extension rules: references/role-contract.md
Role registry: references/roles-index.md
Team patterns: references/team-patterns.md
Core roles:
- 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

请先阅读 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

Team Modes

团队模式

Choose one mode before assembling the team:

```
assemble-only
```
: Build the roster, ownership map, and execution order without starting work.
```
assemble-and-run
```
: Build the team and execute immediately. Use this by default when the user asks to do the task now.
```
reuse-team
```
: Continue with live subagents that still own relevant context. If no suitable live team exists, fall back to
```
assemble-and-run
```
.

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

```
assemble-only
```
：仅构建成员名册、所有权映射和执行顺序，不启动工作。
```
assemble-and-run
```
：组建团队并立即执行。当用户要求立即处理任务时默认使用该模式。
```
reuse-team
```
：继续使用仍持有相关上下文的活跃subagent。如果没有合适的活跃团队，则回退到
```
assemble-and-run
```
模式。

Orchestration Workflow

编排工作流

Follow this sequence unless the user asks for a narrower deliverable.

除非用户要求更轻量化的交付物，否则请遵循以下流程：

1. Frame the task

1. 明确任务框架

Extract and restate:

user objective
required deliverable
constraints, approvals, and safety boundaries
relevant codebase, files, or artifacts
time sensitivity
desired team mode

If the request did not clearly ask for subagents and the skill was not explicitly invoked, do not spawn subagents. Ask or continue in a single-agent path.

提取并重述以下信息：

用户目标
要求的交付物
约束条件、审批要求和安全边界
相关代码库、文件或产物
时间敏感度
期望的团队模式

如果请求未明确要求使用subagent，且未显式调用本技能，则不要生成subagent。询问用户需求或继续采用单代理路径执行。

2. Classify the execution shape

2. 分类执行类型

Use one label for the whole task or one label per slice:

```
read-only
```
: exploration, review, summarization, log analysis, test triage, architecture mapping
```
disjoint-write
```
: multiple owned slices with low overlap, such as separate modules or test files
```
overlap-write
```
: shared interfaces, hotspot files, schema changes, routing layers, central types, or config that multiple agents would otherwise touch

If uncertain, choose the stricter label.

为整个任务或每个任务分片选择一个标签：

```
read-only
```
：探索、评审、摘要生成、日志分析、测试分诊、架构梳理
```
disjoint-write
```
：多个低重叠的独立分片，例如独立模块或测试文件
```
overlap-write
```
：共享接口、热点文件、 schema 变更、路由层、核心类型、配置文件等多个代理可能会修改的内容

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

3. Assemble the team

3. 组建团队

Read references/roles-index.md and references/team-patterns.md as needed.

Apply these rules:

Choose exactly one
```
lead
```
.
Add a
```
planner
```
when the request is ambiguous, under-scoped, or likely to require contract freezing before implementation.
Add one or more
```
explorer
```
roles for discovery-heavy work.
Add
```
implementer
```
roles only when each writer can own a clear slice.
Add a
```
reviewer
```
and a
```
tester
```
for validation when behavior can change.
Add an
```
integrator
```
whenever multiple writers would touch shared surfaces or when overlap risk is nontrivial.

Prefer preset roles from the registry. If no preset role fits, synthesize a temporary role brief by following references/role-contract.md. Keep temporary roles task-local and do not persist them unless the user explicitly asks.

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

遵循以下规则：

仅选择1名
```
lead
```
。
当请求模糊、范围不清晰，或是实现前可能需要冻结契约时，添加
```
planner
```
角色。
为重发现类工作添加1个或多个
```
explorer
```
角色。
仅当每个编写者都能认领清晰的分片时，添加
```
implementer
```
角色。
当可能出现行为变更时，添加
```
reviewer
```
和
```
tester
```
负责验证。
当多个编写者会修改共享内容，或存在明显的重叠修改风险时，添加
```
integrator
```
角色。

优先使用注册表中的预设角色。如果没有适配的预设角色，按照 references/role-contract.md 生成临时角色说明。临时角色仅用于当前任务，除非用户明确要求，否则不要持久化存储。

4. Declare ownership and handoffs

4. 声明所有权和交接规则

For each subagent, define:

mission
scope
owned files, modules, or analysis slice
forbidden areas
required tools or artifacts
expected deliverable
expert standard: act as the most senior expert in the assigned domain, stay diligent, rigorous, and principled within the owned scope, and refuse sloppy or boundary-breaking work
stop conditions
wait strategy

For write work:

Assign exactly one designated writer for each hotspot or shared contract.
Freeze shared interfaces before parallel implementation when possible.
Convert risky overlap into a two-phase flow: parallel proposals first, implementation second.

为每个subagent定义：

任务目标
工作范围
归属的文件、模块或分析分片
禁止触碰的范围
需要的工具或产物
预期交付物
专家标准：作为所分配领域的最高级专家执行任务，在归属范围内保持勤勉、严谨、遵守原则，拒绝粗糙或超出边界的工作
停止条件
等待策略

针对写操作工作：

每个热点文件或共享契约仅分配1名指定编写者。
尽可能在并行实现前冻结共享接口。
将高风险重叠任务转为两阶段流程：先并行输出方案，再执行实现。

5. Choose the execution pattern

5. 选择执行模式

Use the classification from Step 2:

```
read-only
```
: parallelize discovery, review, or summarization, then synthesize.
```
disjoint-write
```
: parallelize by owned slice, then integrate and validate.
```
overlap-write
```
: run a proposal-first phase, then route shared implementation through a single designated writer or an
```
integrator
```
.

After implementation, reopen parallelism for validation whenever it is safe:

```
reviewer
```
for bugs and regressions
```
tester
```
for commands and edge-case coverage
```
explorer
```
for missed call sites or dependency fallout

使用第2步得到的分类结果：

```
read-only
```
：并行执行探索、评审或摘要生成，之后整合结果。
```
disjoint-write
```
：按归属分片并行执行，之后集成验证。
```
overlap-write
```
：先运行方案输出阶段，之后将共享实现交给单个指定编写者或
```
integrator
```
处理。

实现完成后，只要安全就可以重新开启并行验证：

```
reviewer
```
检查bug和回归问题
```
tester
```
验证命令和边缘场景覆盖
```
explorer
```
检查遗漏的调用点或依赖影响

6. Execute with bounded prompts

6. 有限上下文执行

Give each subagent the minimum task-local context needed to succeed.

Include:

the task slice
owned scope
expected output
constraints and forbidden areas
the expert standard: behave like the most senior expert for that slice and remain diligent, rigorous, and principled within the role boundary
whether to wait or continue independently

Do not leak intended answers or hidden diagnoses unless the task specifically requires them.

为每个subagent提供完成任务所需的最小任务上下文。

包含：

任务分片
归属范围
预期输出
约束条件和禁止范围
专家标准：作为本分片的最高级专家执行任务，在角色边界内保持勤勉、严谨、遵守原则
需要等待还是独立继续执行

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

7. Synthesize on the main thread

7. 主线程结果整合

Keep the main thread concise.

Return:

the final roster
execution class and chosen pattern
ownership map
key findings or implementation results
unresolved risks and next steps

Use summaries from subagents instead of copying raw logs into the main thread.

保持主线程内容简洁。

最终成员名册
执行分类和选择的模式
所有权映射
核心发现或实现结果
未解决的风险和下一步动作

使用subagent返回的摘要，不要将原始日志复制到主线程。

Write Safety Rules

写操作安全规则

Apply these rules whenever code changes are involved:

Never let multiple writers edit the same hotspot file at the same time.
Separate proposal work from write work when conflict risk is real.
Route schema changes, shared types, public API contracts, migrations, central config, and routing through one designated writer.
Use an
```
integrator
```
when multiple patches must land coherently.
Re-parallelize only after shared-write risk has been reduced.
Prefer a slower but controlled merge path over fast conflicting edits.

涉及代码变更时遵循以下规则：

禁止多个编写者同时编辑同一个热点文件。
存在实际冲突风险时，将方案工作和写操作工作分离。
schema变更、共享类型、公共API契约、数据迁移、核心配置、路由逻辑统一交给单个指定编写者处理。
当需要多个补丁连贯落地时使用
```
integrator
```
。
仅在共享写风险降低后再重新开启并行执行。
优先选择较慢但受控的合并路径，而非快速但存在冲突的编辑。

Output Structure

输出结构

When the user asks for a team plan or when the orchestration needs to be summarized, use this structure:

markdown

undefined

当用户要求团队计划，或是需要总结编排情况时，使用以下结构：

markdown

undefined

Team Plan

Objective

<goal>

<goal>

Team Mode

<assemble-only | assemble-and-run | reuse-team>

<assemble-only | assemble-and-run | reuse-team>

Execution Class

<read-only | disjoint-write | overlap-write>

<read-only | disjoint-write | overlap-write>

Roster

<role>: <mission and owned scope>

<role>: <mission and owned scope>

Handoffs

<who waits on whom and why>

<who waits on whom and why>

Risks

<conflict, ambiguity, or approval risks>


When reporting completed work, replace `Handoffs` with `Results`.

<conflict, ambiguity, or approval risks>


汇报已完成工作时，将`Handoffs`替换为`Results`。

Extending the Role Library

扩展角色库

Use the role registry as a plug-in system.

To add a new permanent role:

Create a new
```
references/role-<name>.md
```
file by following references/role-contract.md.
Register the role in references/roles-index.md.
Update references/team-patterns.md only if the new role introduces a reusable team slot or a new common pattern.
Keep capability tags stable so old selection logic still works.

Prefer selecting roles by capability tags and write policy rather than hardcoding exact role names into the main workflow.

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

添加新的永久角色步骤：

遵循 references/role-contract.md 要求创建新的
```
references/role-<name>.md
```
文件。
在 references/roles-index.md 中注册新角色。
仅当新角色引入了可复用的团队席位或新的通用模式时，更新 references/team-patterns.md。
保持能力标签稳定，确保旧的选择逻辑仍可正常运行。

优先通过能力标签和写入策略选择角色，不要将具体角色名硬编码到主工作流中。