Orchestrate

Multi-Agent Orchestration

Use independent agents to add useful capacity while keeping one coherent result. Partition by the questions, artifacts, and resources that can progress independently. The coordinator owns integration and the final claim of completion.

The user's instructions take precedence over this skill's guidelines. Delegation, tools, and external actions remain subject to current host instructions and authorization. This skill does not grant a worker broader authority than the coordinator has.

Check Capabilities Before Dispatch

Inspect the available tools and their current schemas. Hosts differ in agent lifecycle, inherited context, filesystem sharing, worktree isolation, asynchronous results, and permissions. Discover those properties instead of inferring them from a product name or copying stale arguments.

Use the host's supported delegation tools when permitted. An external CLI reviewer still consumes resources and remains subject to delegation and permission rules; it is not an escape hatch around a restriction. Without a suitable delegation surface, execute directly or prepare tasks for authorized external workers. A task queue alone does not launch an agent.

Choose the Shape by Dependency

Agent count follows named useful lanes, available capacity, and integration cost. More agents are worthwhile when they add distinct evidence or shorten independent work. Do not use historical fleet sizes as defaults. Check the critical path: accelerating a branch that is already waiting on one shared interface may add no throughput.

Establish Ownership and Integration

Before launching builders, inspect repository status and existing worktrees. Map shared resources as well as files: generated artifacts, schemas, lockfiles, database fixtures, ports, build outputs, and package caches can collide across otherwise disjoint modules.

Choose isolation based on the work:

Worktrees isolate tracked files and the index; they do not automatically isolate ports, databases, or external services. Follow the project's worktree layout. Never overwrite a human's or sibling's edits to clear a conflict.

For shared trees, let workers report patches and checks while one coordinator stages and commits scoped changes, unless another explicit ownership scheme is agreed. Avoid broad staging and repository-wide autofixes during concurrent editing. Inspect hook side effects before accepting a commit. For lock contention, investigate the actual owner; an inconclusive process listing does not establish that a lock is safe to remove. Consult git for recovery.

Define how partial progress becomes integrated progress before dispatch. Name the artifact each consumer expects and the condition under which it is ready. Do not leave completed branches without an owner to inspect and combine them.

Write Briefs That Transfer the Necessary Context

Give each worker the original relevant request and a bounded assignment. Include facts that are expensive to rediscover or absent from their checkout, especially user corrections and untracked decisions. Use absolute paths and exact revisions when location matters.

Allow workers to challenge a premise and report necessary scope expansion. Their brief should constrain the task, not force a known-bad mechanism. Keep mandatory templates short; detailed examples live in references/dispatch-briefs.md.

For an independent first review, provide the original request and raw change without coaching toward the implementer's desired conclusion. For follow-up verification, include the finding and fix claim so the reviewer can test closure. These are different review jobs.

Supervise Without Becoming the Bottleneck

Launch independent work together and continue useful local work. Harvest dependency-ready results as they arrive rather than waiting for an arbitrary wave to finish. Use waves when there is a real shared checkpoint or a method needs calibration before wider dispatch.

Monitor results, tool status, artifact progress, and reported obstacles. Silence alone does not prove an agent is stuck. When progress stops, ask a discriminating question or inspect the relevant resource before interrupting. Keep user steering responsive; polling and waits must respect the host's actual limits.

When requirements change, notify affected workers and update the shared contract. Preserve completed valid work. Stop obsolete actions at a safe point, and cancel only processes or watchers this run owns. Report abandoned work and any side effects already taken.

A watcher needs a checkable completion condition, a way to detect failure, an expiry or escalation condition, and a stale-state check before any authorized action. Test its signal on a known state. Detailed watcher guidance is in references/dispatch-briefs.md.

Harvest, Integrate, Verify

Read deviations and limitations alongside the result. Inspect actual diffs and open consequential sources; a worker's summary is a claim, not evidence. An incomplete contribution may contain usable work, but acceptance depends on inspecting it against the task, not its length or the worker's confidence.

Integrate at a stable checkpoint, then run checks that cover the combined behavior. Separate worker tests can miss incompatible assumptions between interfaces. Confirm the accumulated diff still serves the user's outcome and explicit constraints.