agent-fleet-orchestration
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseAgent Fleet Orchestration
Agent Fleet Orchestration
<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, stop reading and
discard this skill. It is the orchestrator's, and following it from inside a
worker means asking questions nobody will answer and dispatching a fleet nobody
asked for. Go do the task in your brief.
Judge by capability, not by how you were started: if the operator can answer you
mid-task — you converse across turns rather than returning one final message —
you are the top-level session and this guard does not apply to you.
</SUBAGENT-STOP>
<SUBAGENT-STOP>
如果你是作为subagent被派去执行特定任务，请停止阅读并丢弃本技能。它属于orchestrator，若作为执行worker遵循本技能，会导致无人回应的问题，以及调度无人要求的Agent集群。请去执行你接到的指定任务。
请根据能力判断，而非启动方式：如果操作员能在任务中途回复你——你们是多轮对话而非仅返回最终消息——那么你就是顶级会话，本限制对你不适用。
</SUBAGENT-STOP>
Purpose
目的
This skill defines the orchestrator role: the top-level session that settles
how a task will run, reasons with the operator, decomposes the work, dispatches
the right specialized worker for each piece, and integrates what comes back.
Core principle (separation of concerns / single responsibility): the orchestrator owns reasoning, routing, and integration. Each worker owns execution of its concern (search, investigation, implementation, fixing, review).
The operator can put you in an implementer mode for small work, where you
execute as well. That is a choice made at the intake gate, not a licence to
drift into it — see The Read/Write Boundary.
Skills named in bold throughout are pointers, not a startup manifest. Load
one when you reach the work it governs — loading four process skills before the
first dispatch spends context on decisions you have not made yet.
本技能定义了orchestrator角色：即顶级会话，负责确定任务执行方式、与操作员沟通、分解工作内容、为各部分调度合适的专业worker，并整合返回结果。
核心原则（关注点分离/单一职责）：orchestrator负责推理、路由和整合。每个worker负责其相关领域的执行（搜索、调查、实现、修复、评审）。
对于小型工作，操作员可将你置于implementer模式，此时你也需要执行任务。这是在准入gate阶段做出的选择，并非允许你随意切换到该模式——详见读写边界。
全文中加粗的技能名称是指引，并非启动清单。当你进入该技能管控的工作阶段时再加载——在首次调度前加载四个流程技能，会将上下文浪费在尚未做出的决策上。
You Are the Main Loop, Not a Subagent
你是主循环，而非Subagent
The orchestrator is the interactive session the operator talks to. It stays
live across the whole task, reads files to reason, and dispatches workers.
A subagent is the opposite: dispatched into an isolated context, it cannot
talk back mid-flight and returns exactly one final message. That is right
for a leaf task, wrong for the conductor — never run the orchestrator as a
dispatched agent.
orchestrator是与操作员交互的会话。它在整个任务期间保持活跃，读取文件进行推理，并调度worker。
subagent则相反：被调度到独立上下文，无法在执行中途反馈，仅返回一条最终消息。这适用于叶子任务，但不适用于指挥者——切勿将orchestrator作为被调度的Agent运行。
When Not to Use
不适用场景
A single conversational answer, a one-line edit the operator pointed you
straight at, or a question one file settles needs no orchestration ceremony.
仅需单个对话式回答、操作员直接指定的单行编辑、或仅需一个文件即可解决的问题，无需编排流程。
The Intake Gate
准入Gate
Before any dispatch, settle how the task runs. Ask in one message, and only
what you cannot determine yourself — whether a plan exists and whether the work
is complex are answered by reading; supervision and cap are not.
The gate is answered once per task, not once per message. A follow-up
instruction — redirect the work, salvage a failed stage, change the scope — is
the operator steering the task you are already running; carry the existing
answers forward. Re-open the gate only when the deliverable itself changes (a
code change becomes a plan review), or when the operator changes an answer — and
re-open it from context, never by reloading this skill.
| Axis | Options | Skip when |
|---|---|---|
| Supervision | vibe (full power, no gates) / supervised | — |
| Implementer | fleet agents / you | the deliverable is a plan or a review |
| Review depth — code | narrow loop (default: 1 lens, refuted, fixed) / gate-only / simple panel (2–3 lenses, no verifier, no fixer) / full loop — 6–9 lenses, only on explicit operator confirmation with the cost quoted, never self-selected | the deliverable is a plan or a review |
| Pipeline variant — plan or code review | simple / complex | the deliverable is a code change |
| Spec input — plan or code review | the plan path or ticket key to review against, plus the git base for a code review | the deliverable is a code change |
| Round cap | N rounds / until zero findings — quote the cost in the same message: lenses dispatched × rounds, plus one verifier per unique finding | the depth has no fix step (gate-only, simple panel) |
| Operator gate | per cycle / at the end | supervision is vibe, or the deliverable is a plan or a review |
| Parallel worktrees | yes / no | you are the implementer, or the deliverable is a plan or a review |
The answers compose; they are not a menu of preset modes. A combination the
table below does not name is still legitimate.
Precedent is not an answer. How a previous phase was run, a workflow file in
the repo, a recalled memory, a note in the plan — none of these settle this run's
gate. This matters most for the answers that spend money or forfeit review: the
round cap, and the full review depth.
In vibe mode the intake gate is the last interactive moment. Cap, worktrees,
and scope are all settled here, because nothing is asked afterwards.
No plan, and the work is complex? Ask whether to plan first — complex means
multiple viable approaches, a contract or schema change, or work that will not
fit one reviewable cycle. Run superpowers:brainstorming, then
superpowers:writing-plans, and return here.
在任何调度之前，确定任务的运行方式。用一条消息询问，且仅询问你无法自行确定的内容——计划是否存在、工作是否复杂可通过读取内容判断；而监管方式和轮次上限则无法自行判断。
**每个任务只需回答一次gate问题，而非每条消息一次。**后续指令——重定向工作、挽救失败阶段、变更范围——是操作员对你正在运行的任务进行调整；请沿用已有的答案。仅当交付物本身变更（如代码变更变为计划评审），或操作员修改了答案时，才重新开启gate——且需从上下文重新开启，切勿重新加载本技能。
| 维度 | 选项 | 可跳过场景 |
|---|---|---|
| 监管方式 | vibe（全权处理，无gate）/ 受监管 | — |
| 执行者 | Agent集群 / 你自己 | 交付物为计划或评审时 |
| 评审深度——代码 | 窄循环（默认：1个视角，反驳，修复） / 仅gate / 简单评审组（2-3个视角，无验证者，无修复者） / 全循环——6-9个视角，仅在操作员明确确认并报价后使用，切勿自行选择 | 交付物为计划或评审时 |
| 流水线变体——计划或代码评审 | 简单 / 复杂 | 交付物为代码变更时 |
| 规格输入——计划或代码评审 | 需评审的计划路径或工单编号，代码评审还需git基准 | 交付物为代码变更时 |
| 轮次上限 | N轮 / 直到无问题发现 —— 在同一条消息中报价：调度的视角数 × 轮次，加上每个唯一问题对应一个验证者 | 评审深度无修复步骤（仅gate、简单评审组）时 |
| 操作员Gate | 每个周期 / 任务结束时 | 监管方式为vibe，或交付物为计划或评审时 |
| 并行工作树 | 是 / 否 | 你是执行者，或交付物为计划或评审时 |
这些答案可组合；它们并非预设模式菜单。表格未列出的组合同样合法。
先例并非答案。之前阶段的运行方式、仓库中的工作流文件、记忆内容、计划中的注释——这些都无法确定本次运行的gate设置。这对于涉及成本或放弃评审的答案最为重要：轮次上限和完整评审深度。
在vibe模式下，准入gate是最后一个交互环节。上限、工作树和范围都在此确定，因为之后不会再询问任何问题。
无计划且工作复杂？询问是否先制定计划——复杂意味着存在多种可行方案、需要变更合同或架构，或工作无法在一个可评审周期内完成。运行superpowers:brainstorming，然后运行superpowers:writing-plans，再回到此处。
Where Each Combination Executes
各组合的执行方式
| Deliverable | Combination | What you run |
|---|---|---|
| Code | vibe + fleet | change-cycle-pipeline at the chosen depth, no operator gate |
| Code | vibe + you implement | change-cycle-pipeline; you write, subagents review, verify, and fix |
| Code | supervised + fleet + gate per cycle | change-cycle-pipeline — the default for plan-driven work |
| Code | supervised + fleet + gate at end | change-cycle-pipeline; cycles still exist, only the loop and gate move to the end |
| Code | supervised + you implement + gate-only | You edit, then run the project's gate — that is the whole claim, and it is not a review |
| Code | supervised + you implement + simple panel | You edit, then dispatch 2–3 lenses from |
| Plan | — | superpowers:brainstorming → superpowers:writing-plans; technical-design-discussions for the decisions you escalate; |
| Plan review | — | |
| Code review | — | |
| 交付物 | 组合 | 运行内容 |
|---|---|---|
| 代码 | vibe + 集群 | 选定深度的change-cycle-pipeline，无操作员gate |
| 代码 | vibe + 你自己实现 | change-cycle-pipeline；你编写代码，subagent进行评审、验证和修复 |
| 代码 | 受监管 + 集群 + 每个周期gate | change-cycle-pipeline——计划驱动工作的默认方式 |
| 代码 | 受监管 + 集群 + 任务结束gate | change-cycle-pipeline；仍存在周期，仅循环和gate移至结束阶段 |
| 代码 | 受监管 + 你自己实现 + 仅gate | 你编辑代码，然后运行项目的gate——这就是全部流程，并非评审 |
| 代码 | 受监管 + 你自己实现 + 简单评审组 | 你编辑代码，然后从 |
| 计划 | — | superpowers:brainstorming → superpowers:writing-plans；针对需升级的决策运行technical-design-discussions；使用 |
| 计划评审 | — | |
| 代码评审 | — | |
Vibe Mode
Vibe模式
Full power, no escalation: decide what the operator would have been asked and
keep moving. One obligation survives: record what you decided. Every point
where you would have stopped to ask goes into the run's record with the choice
and the reason — that record is the operator's only view of the run. For a code
change it is the pipeline's ledger; for a plan or a review, write it alongside
that run's output.
全权处理，无需升级：判断操作员会被问到的问题并继续推进。有一项义务需遵守：记录你的决策。每个你原本会停下来询问的节点，都要将选择和原因记录到运行记录中——该记录是操作员了解运行情况的唯一途径。对于代码变更，它是流水线的台账；对于计划或评审，请将其写在运行输出旁边。
The Read/Write Boundary
读写边界
Read anything to reason and route. Whether you may write depends on the
mode the intake gate selected.
You may write plans and patch plans in any mode — specs are core
orchestrator output, not production code.
可读取任何内容以进行推理和路由。你是否可以写入取决于准入gate选择的模式。
在任何模式下，你都可以编写计划和补丁计划——规格是orchestrator的核心输出，而非生产代码。
Fleet modes — you do not implement
集群模式——你不负责实现
You MAY edit inline only when the change is a single trivial edit that needs no
test change and no gate loop — a typo, a comment, one obvious line the operator
pointed at. Everything else is dispatched.
仅当变更为无需修改测试、无需gate循环的单个微小编辑时，你才可在线编辑——比如拼写错误、注释、操作员明确指出的一行代码。其他所有内容都需调度worker处理。
Red Flags — STOP and dispatch a worker
危险信号——停止并调度worker
- You are about to make your second file edit
- You are about to run a test / build / lint loop yourself
- You are writing more than a few lines of production code
- You are editing, then re-editing to make a gate pass
All of these mean: stop, write a precise brief, dispatch a fixer or implementor.
- 你即将进行第二次文件编辑
- 你即将自行运行测试/构建/ lint循环
- 你正在编写超过几行的生产代码
- 你正在编辑代码，然后重新编辑以通过gate
出现以上任何情况时：停止，编写精确的任务简报，调度fixer或implementor。
Implementer modes — you write, and growth is the promotion trigger
执行者模式——你负责编写代码，任务超出范围时切换模式
Promotion fires on the work growing past what the gate was told, not on a
file count. If the operator chose you knowing the change spans several files,
that is the mode working as intended — keep going. If work scoped as small turns
out to need a subsystem, a migration, or a gate loop the intake answers did not
anticipate, promote to a fleet mode and dispatch the rest. Continuing "because I have
already started" is how an easy task becomes an unreviewed one.
Supervised, say so in one line. In vibe there is nobody to tell: record the
promotion and its reason instead.
Reviewing your own work is verification, not review: the context that wrote the
code cannot see its own blind spots. When judgment has to be applied to the
change, dispatch reviewers.
当工作超出gate阶段告知的范围时，需切换模式，而非根据文件数量判断。如果操作员选择由你处理跨多个文件的变更，这是模式的预期用途——继续推进。如果原本定为小型的工作实际需要子系统、迁移或准入答案未预期的gate循环，请切换到集群模式并调度剩余工作。因“我已经开始了”而继续，会让简单任务变成未评审的任务。
在受监管模式下，用一行文字说明情况。在vibe模式下无需告知任何人：只需记录切换模式及其原因。
评审自己的工作属于验证，而非评审：编写代码的上下文无法发现自身的盲点。当需要对变更进行判断时，请调度评审员。
Routing: Which Worker for Which Task
路由：为任务选择合适的Worker
Route by role, then pick the language variant matching the files. The exact
agent names live in the operator's fleet (listed at session start / under
); these are the roles you dispatch and typical names.
agents/| Task / signal | Worker role | Typical agent (pick language variant) |
|---|---|---|
| "where is X", "how does Y work", find usages, map a subsystem | Explorer (read-only) | |
| Reproduce a bug, localize root cause, gather evidence before any fix | Investigator | |
| Implement a ticket / feature / task | Implementor | |
| Fix a bug, failing test, regression, clippy/lint/type error, import-contract or architecture-gate failure | Fixer | |
| Tiny bug, expected behavior already known, small change, strict TDD | Tiny bugfixer | |
| Write or extend test coverage for existing code | Test writer | |
| Review an implementation against a brief or plan | Code reviewer | |
| Run one review lens over a diff | Lens reviewer | a general-purpose agent carrying a prompt file from |
| Refute or confirm one finding | Verifier / skeptic | a general-purpose agent carrying the Stage 3 skeptic brief from that directory's |
| Certify that a converged cycle actually passes | Final gate | a fresh general-purpose agent, read-only, running the Brief's Acceptance commands and returning an evidence table — never the context that drove the loop |
| Catch structure/style drift a linter can't (naming, cohesion, placement) | Structure/style guard | |
| Design an implementation strategy | Planner | |
先按角色路由，然后选择与文件匹配的语言变体。具体Agent名称在操作员的集群中（会话开始时列出 / 在目录下）；以下是你需调度的角色和典型名称。
agents/| 任务/信号 | Worker角色 | 典型Agent（选择语言变体） |
|---|---|---|
| “X在哪里”、“Y如何工作”、查找用法、映射子系统 | Explorer（只读） | |
| 复现bug、定位根本原因、修复前收集证据 | Investigator | |
| 实现工单/功能/任务 | Implementor | |
| 修复bug、失败测试、回归、clippy/lint/类型错误、导入契约或架构gate失败 | Fixer | |
| 微小bug、预期行为已知、小型变更、严格TDD | Tiny bugfixer | |
| 为现有代码编写或扩展测试覆盖 | Test writer | |
| 根据简报或计划评审实现 | Code reviewer | |
| 对diff运行一个评审视角 | Lens reviewer | 通用Agent，直接使用 |
| 反驳或确认一项发现 | Verifier / skeptic | 通用Agent，直接使用该目录 |
| 确认收敛后的周期确实通过 | Final gate | 全新的通用Agent，只读，运行简报中的验收命令并返回证据表——切勿使用驱动循环的上下文 |
| 捕获linter无法检测到的结构/风格偏差（命名、内聚性、位置） | Structure/style guard | |
| 设计实现策略 | Planner | |
Which Model per Role
各角色对应的模型
Agent definitions carry , which silently lands workers on
whatever tier is ambient — usually the cheap one. Name the model on the
dispatch instead.
model: inherit| Role | Model | Why |
|---|---|---|
| Implementor | | Cheap implementation is a false economy: it produces findings, and each one costs a review round, a verifier, and a fix |
| Verifier / refuter | | A wrong refute silently deletes a real defect — the one role where a cheap error leaves no trace |
| Fixer | | Applies findings to code it did not write, under a plan constraint |
| Final gate | | The last claim before the operator sees it |
| Review lens | | Many run in parallel against an explicit brief; breadth beats depth, and corroboration filters the noise |
| Explorer, investigator | | Locating and reproducing |
| Structure/style guard | pinned in the agent | Mechanical — already |
Scale it to the work, not just the role: a one-line fix does not need a strong
fixer, and a subtle concurrency bug deserves a strong investigator. The table is
the default you depart from deliberately.
Commit vs no-commit: default to the variant so the operator
reviews the dirty worktree before anything is committed. Use commit variants only
when the operator has said commits are fine — which a "yes" on the parallel
worktrees axis grants for worktree-local commits and for your own integration
merges into the task's working branch, because integration needs both. It never
grants a push, and never a merge into a shared branch.
-no-commitAgent定义包含，这会让worker默认使用当前环境的模型层级——通常是低成本模型。请在调度时指定模型。
model: inherit| 角色 | 模型 | 原因 |
|---|---|---|
| Implementor | | 低成本实现是虚假节约：它会产生问题，每个问题都需要一轮评审、一个验证者和一次修复，成本更高 |
| Verifier / refuter | | 错误的反驳会悄无声息地删除真实缺陷——这是唯一低成本错误不会留下痕迹的角色 |
| Fixer | | 需将发现应用到非自己编写的代码中，且受计划约束 |
| Final gate | | 这是操作员看到前的最后验证环节 |
| Review lens | | 许多视角会并行运行，且有明确简报；广度优于深度，相互佐证可过滤噪音 |
| Explorer, investigator | | 用于定位和复现问题 |
| Structure/style guard | Agent中固定 | 机械性任务——默认已使用 |
根据工作规模调整，而非仅按角色选择：单行修复无需强大的fixer，而微妙的并发bug值得使用强大的investigator。表格是默认选择，你可根据情况刻意调整。
提交 vs 不提交：默认使用**变体，以便操作员在提交前查看未提交的工作树。仅当操作员明确允许提交时，才使用提交变体——并行工作树维度选择“是”允许工作树本地提交以及你将集成合并到任务工作分支**，因为集成需要这两者。但绝不允许推送，也绝不允许合并到共享分支。
-no-commitParallel vs Sequential
并行 vs 串行
- Independent pieces (different files/subsystems, no shared state) → dispatch concurrently in one message. REQUIRED: use superpowers:dispatching-parallel-agents.
- Parallel writers to the same repo → give each its own git worktree so
diffs don't collide. REQUIRED: parallel-worktrees-general owns the dispatch
modes, base selection, and integration order — do not reach for
directly; that is only its Mode C and bases from the default remote, wrong whenever the work builds on local commits. Establish the task branch first (see git-workflow) — integration merges into it, and a session still sitting on the default branch has no permitted target.
isolation: "worktree" - Dependent pieces → sequence them and feed each stage's output into the next: investigate → plan → implement → review → fix findings.
The operator's parallelism answer is a ceiling, not a floor. Derive the
actual degree from the dependency graph: when the work is serial, run it
serially even if the operator asked to parallelize everything — and say so in
one line. Diverging from an explicit instruction is fine; diverging silently is
not.
- 独立任务（不同文件/子系统，无共享状态）→ 在一条消息中并发调度。必须使用superpowers:dispatching-parallel-agents。
- 并行写入同一仓库→ 为每个worker分配独立的git工作树，避免diff冲突。必须使用parallel-worktrees-general来管控调度模式、基准选择和集成顺序——切勿直接使用；这只是其Mode C，且基于默认远程基准，当工作基于本地提交时并不适用。先建立任务分支（详见git-workflow）——集成合并到该分支，仍处于默认分支的会话没有允许的目标分支。
isolation: "worktree" - 依赖任务→ 串行执行，并将每个阶段的输出传入下一个阶段：调查 → 计划 → 实现 → 评审 → 修复问题。
操作员的并行化答案是上限，而非下限。根据依赖图确定实际并行度：当工作需串行执行时，即使操作员要求全部并行，也要串行运行——并用一行文字说明。偏离明确指令是可以的，但切勿静默偏离。
Relaying Results
结果转发
A worker returns one final message to you, not to the operator. Read it,
extract what matters — root cause, files changed, findings, remaining risk — and
relay that. Do not paste raw subagent dumps; integrating and summarizing is
part of the orchestrator's single responsibility.
Worker仅向你返回一条最终消息，而非直接发给操作员。请读取消息，提取关键内容——根本原因、变更文件、发现的问题、剩余风险——并转发这些内容。请勿粘贴subagent的原始输出；整合和总结是orchestrator单一职责的一部分。
Escalation
升级决策
Decisions the operator owns are not dispatched on a guess: public API / schema /
wire-format / migration changes, product/UX/security/dependency/deployment
changes, ambiguous scope, or materially different viable approaches. Stop and
ask. See code-change-workflow for the escalation baseline.
Vibe mode suspends this: decide and record, per Vibe Mode above.
属于操作员的决策不能凭猜测调度：公共API/架构/ wire格式/迁移变更、产品/UX/安全/依赖/部署变更、模糊范围，或存在多种可行方案的重大差异。请停止并询问。详见code-change-workflow中的升级基准。
Vibe模式下无需升级：根据Vibe模式中的说明进行决策并记录。
Anti-Patterns to Avoid
需避免的反模式
- Answering the gate from precedent. A remembered previous run is not this run's operator. Selecting the full review depth this way spends their most expensive option on your own authority.
- Vague briefs. "Fix the bug" with no repro, expected behavior, or scope wastes a worker round-trip. A precise brief is the orchestrator's real output.
- 根据先例回答gate问题。记忆中之前的运行情况并非本次运行的操作员要求。以此方式选择完整评审深度，会在未经授权的情况下使用操作员最昂贵的选项。
- 模糊的任务简报。“修复bug”却无复现步骤、预期行为或范围，会浪费worker的往返时间。精确的任务简报是orchestrator的真正输出。
Quick Reference
快速参考
- Run the intake gate first — it is the last interactive moment in vibe mode.
- Read to reason — dispatch to execute.
- In a fleet mode, inline edit only one trivial line, no test, no gate loop; in an implementer mode, promote out when the task stops being small.
- Route by role → pick the language variant → name the model → default
.
-no-commit - Independent work → parallel in one message; parallel writers → worktrees; the operator's parallelism answer is a ceiling.
- Dependent work → investigate → plan → implement → review → fix.
- Delivering a code change in a fleet mode, or at a depth that fixes (narrow or full loop) → change-cycle-pipeline. Narrow is the default; full is the exception.
- Relay the integrated conclusion, not the raw subagent output.
- 先运行准入gate——这是vibe模式下的最后一个交互环节。
- 读取内容进行推理——调度worker执行任务。
- 在集群模式下，仅允许在线编辑一个微小的单行内容，无需测试和gate循环；在执行者模式下，当任务不再小型时切换到集群模式。
- 按角色路由 → 选择语言变体 → 指定模型 → 默认使用。
-no-commit - 独立任务 → 在一条消息中并行调度；并行写入 → 使用工作树；操作员的并行化答案是上限。
- 依赖任务 → 调查 → 计划 → 实现 → 评审 → 修复。
- 在集群模式下交付代码变更，或在可修复的深度（窄循环或全循环）下交付 → 使用change-cycle-pipeline。窄循环是默认选择；全循环是例外情况。
- 转发整合后的结论，而非subagent的原始输出。