orchestrator（编排器）

Orchestration: Subagents, Agent Teams & Parallel Execution

These rules govern ALL parallelization decisions. Apply them on every task.

Not for single-action requests, simple file edits, or sequential-only workflows.

Dispatch

Canonical Vocabulary

Gating Logic

Use this gate before loading the full orchestration doctrine:

1. If the request has exactly one action, stay in a single session and do not invoke this skill.
2. If the work has multiple steps but they all edit the same file or depend on strict sequencing, do not force parallelism; keep the sequential constraint explicit.
3. If decomposition is unclear, run an explore-first pass and then re-enter the gate instead of guessing the topology.
4. If another active skill has a stricter phase order or dispatch precondition, preserve that skill's control flow and parallelize only inside its allowed boundaries.
5. If the user explicitly requests a specific execution approach, honor it unless it conflicts with a hard safety constraint.

Operator Contract

Empty / Help

1. Show the public entry paths: empty/help, pattern <A-F>, tier, and recovery.
2. Run the Classification Gate before applying the Decomposition Gate.
3. Explain the near-miss cases where this skill should not take over: single-action work, same-file sequential work, and phase-gated skills with stricter ordering.
4. Point to the specific references needed for pattern selection, progress accounting, runtime limits, and misroute examples instead of pasting the entire doctrine.

pattern <A-F>

1. Load references/patterns.md.
2. Present the named pattern, when to use it, when not to use it, and the recovery implications.
3. Keep Pattern E as the default unless the named pattern is the clear better fit for the actual request.

tier

1. Load references/runtime-capability-boundaries.md before discussing mechanism limits or environment-specific tooling constraints.
2. Show the Tier Selection table and explain why the highest applicable tier wins.
3. Name the near-miss cases where a lower tier is still correct, such as exactly one action or a single-domain, no-coordination task.

recovery

1. Load references/progress-accounting.md.
2. Present the Accounting Rule, recovery ladder, and reporting contract.
3. Explain how to handle missing agents, re-spawns, and explicit skips before advancing to the next wave.

0. Decomposition Gate (MANDATORY before any work)

Before executing any request that involves tool-mediated work:

1. DECOMPOSE: List the actions needed (file reads, edits, searches, commands, analyses).
2. CLASSIFY: Which actions are independent (no data dependency)? Which are dependent?
3. MAXIMIZE: Actively split actions further — find every opportunity to parallelize. Each independent action = its own subagent. Challenge: can any action be split into two?
4. CONFLICT CHECK: Two independent actions editing the same file → make those sequential; all others remain parallel.
5. DISPATCH: Default is Pattern E — TeamCreate with nested subagent waves per teammate. Pre-approve permissions before spawning. Use bare subagent waves only when single domain, no coordination, no context pressure. Single session only when there is literally 1 action.
6. TRACK: For orchestrated work, create TaskCreate entries before dispatch (see Section 7).

Fast path: Single-action requests skip directly to single session.

Explore-first path: Cannot decompose without exploration → spawn parallel exploration team first (Pattern F Wave 1), then re-enter this gate.

Transition heuristic: Subagent waves hitting context limits or agents need to share findings → upgrade to Pattern E (teams + nested waves).

User override: Explicit user requests for a specific execution approach take precedence.

Common rationalizations (all invalid)

• "It's faster to do it myself" — Parallel subagents complete N tasks in time of the slowest 1.
• "The task is too simple" — If it has 2+ independent actions, parallelize them.
• "I'll just do this one thing first" — Decompose BEFORE doing anything.

Mode constraints

• Plan mode: Read-only subagents only. No teams, no write-capable agents.
• Implementation mode: All tiers available. Default to highest applicable tier.
• Delegate mode: Lead orchestrates only. All implementation via teammates/subagents.

Skill integration

When a superpowers skill is active, the gate operates WITHIN the skill's execution structure:

• Phase-gated skills: Parallelize within each phase. Do not parallelize across phase boundaries.
• Per-task review loop skills: The skill's sequential structure takes precedence. Parallelize exploration within each task, not across tasks.
• Dispatch-precondition skills: The skill's "Don't use when" conditions remain valid. The gate does not override skill-level safety guards.

See references/misroute-examples.md for concrete near-miss cases such as same-file sequential edits, phase-gated review loops, and single-action requests.

1. Tier Selection (mandatory — highest applicable tier wins)

Select the highest tier whose criteria are met. Never select a lower tier to reduce cost. A count of 2 is not enough on its own; the actions must be independent.

Scaling Strategy

2. Subagent Best Practices

Spawning

• One response, multiple Task calls. All independent subagents MUST be dispatched in the same message.
• Use run_in_background: true for subagents whose results are not needed immediately.
• N independent actions = N parallel subagents. Merge only when they share file/directory scope.

Prompt-tuning

• Give every subagent a detailed, self-contained prompt with exact file paths, expected output format, and domain context.
• Do NOT rely on the subagent inheriting conversation history — it does not.

Model selection

• Default policy: opus for every subagent, teammate, and wave.
• GitHub Copilot CLI override: all plans should be /fleet-optimized per /orchestrator. For /fleet, use Claude Opus 4.6 with max thinking for every non-trivial subagent, teammate, wave, and /fleet member.
• Use Claude Sonnet 4.6 with max thinking only for incredibly/extremely trivial /fleet subagents. If there is any ambiguity, escalate to Opus.
• When both policies are present, apply the environment-specific override for the active runtime.

Context management

• Delegate verbose operations (test suites, log parsing, doc fetching) to subagents.
• Use subagent resumption (agent ID) for multi-phase work rather than spawning fresh.
• After a wave completes, apply the Accounting Rule (Section 4) before synthesizing or dispatching the next wave.

3. Agent Team Best Practices

• Scale teammates to match the work — no artificial cap. Use as many as needed for maximum parallelism (up to ~50 agents total including nested subagents). Token budget is not a constraint.
• Pre-approve common permissions before spawning teammates to reduce friction.
• Assign each teammate a distinct domain and non-overlapping file ownership.
• Assign as many tasks per teammate as the domain requires — no artificial limit.
• Include all task-specific context in spawn prompts: file paths, architecture decisions, acceptance criteria. Teammates do not inherit conversation history.
• Use delegate mode to prevent the lead from implementing work itself.
• Task claiming uses file locking — no race conditions when multiple teammates claim simultaneously.
• Never assign two teammates overlapping file ownership.
• The lead must not proceed to synthesis until all teammate tasks are accounted for (Section 4).

4. Quality Gates & Failure Recovery

The Accounting Rule (MANDATORY after every parallel dispatch)

When N agents are dispatched, all N must be accounted for before proceeding:

1. COLLECT: Wait for all N agents to return. Poll with TaskOutput block=false for timeout detection.
2. TALLY: Results received vs dispatched. Missing = unresolved.
3. RESOLVE all non-successes via the Recovery Ladder (see references/patterns.md).
4. GATE: Do NOT advance until every agent has SUCCESS or explicit SKIP.
5. REPORT: Summarize all agent outcomes via TaskUpdate before proceeding.

Hooks for automated enforcement

• TeammateIdle hook: prevent teammates from idling before work is verified.
• TaskCompleted hook: prevent tasks from closing before tests pass.
• Both use exit code 2 to send feedback and keep the teammate/task active.

Plan approval workflow

• For risky changes, include "Require plan approval before making changes" in the spawn prompt.
• Teammate enters read-only plan mode, sends plan_approval_request to lead when ready.
• Lead approves or rejects with feedback. Teammate revises if rejected.
• Influence approval criteria in spawn prompt: "only approve plans that include test coverage."

5. Orchestration Patterns

6. Limitations

• No session resumption for teammates (/resume and /rewind won't restore them).
• No nested teams (teammates can use subagents but cannot spawn teams).
• One team per session. Clean up before starting a new one.
• Lead is fixed — cannot transfer leadership.
• All teammates inherit the lead's permission mode at spawn.
• Subagent resumption may not recover from all failure modes (re-spawn instead).
• No built-in timeout detection — orchestrator must poll with TaskOutput manually.
• Recovery re-spawns count toward the session's agent budget.
• Display modes: in-process (Shift+Down to cycle) is default; split panes require tmux or iTerm2.
• Teammate interaction: Enter to view session, Escape to interrupt, Ctrl+T for task list.

Progressive Disclosure

• Do not load every orchestration detail by default.
• Read references/classification-gate.md when deciding whether this skill should own the task at all.
• Read references/patterns.md only when the user requests a specific pattern or the topology choice is the main question.
• Read references/progress-accounting.md when discussing reporting, accounting, or recovery behavior.
• Read references/runtime-capability-boundaries.md when tool/runtime limits or environment-specific constraints affect the topology.
• Read references/misroute-examples.md when a request is close to the trigger boundary.

Critical Rules

1. Never dispatch independent actions sequentially — all independent Task calls MUST appear in one response.
2. Always run the Decomposition Gate before any tool-mediated work; skipping it is never acceptable.
3. Never reduce parallelism or tier when the higher tier criteria are met; follow the documented environment-specific model policy.
4. Never silently drop a failed subagent — N dispatched = N accounted for; apply the Accounting Rule after every wave.
5. Never advance to Wave N+1 with unresolved agents — resolve all agents in Wave N first.
6. Always create TaskCreate entries before dispatching subagent waves or agent teams — silent orchestration is forbidden.
7. Never assign two teammates overlapping file ownership — overlapping edits cause lost work.
8. Always include full context in subagent and teammate prompts — they do not inherit conversation history.

Reference File Index

7. Progress Visibility (MANDATORY for orchestrated work)

All orchestrated work must produce structured progress indicators via TaskCreate/TaskUpdate.

Rules

• Create tasks before execution begins, not retroactively.
• Each task MUST have a descriptive activeForm in present continuous tense naming the specific action and target.
• Update tasks to in_progress before starting, completed immediately after.
• After wave completion + accounting, summarize all agent outcomes before dispatching the next wave.

Scope Boundaries

IS for: decomposition, orchestration topology, pattern selection, progress accounting, recovery/reporting, and multi-agent execution rules.

NOT for: single-action requests, same-file sequential work that should stay serialized, or overriding stricter phase-gated skill contracts.