/dispatch

name: dispatch
description: Use when the orchestrator is about to dispatch a specialist turn that writes to a repository, runs alongside other turns, or carries acceptance the specialist must meet

Dispatch

Dispatch is the technique for turning a route already decided into specialist turns that can run, prove themselves and land without stepping on each other. It runs mid-flow. Upstream, the orchestrator has cleared the intent and composed the route. Downstream, the kernel renders the goal into a specialist's context, the specialist works and closes a contract, a verifier judges it, and an integration puts it on the shared branch. All three consume what this skill produces -- a goal, a wave, an integration order -- so a defect here is paid downstream, where it is harder to see.

The orchestrator's identity lists what every goal carries at the moment of dispatch; this skill holds the reasons behind the writing, parallel and integration parts. Commands, sequences and numbers are in `reference.md`; one two-writer wave, end to end, is in `examples.md`.

The eight principles

1. **A goal completes the kernel; it never repeats it.** The kernel is data only: it carries the turn's identity, the project and its declared workflow, the read menu, a bound task's gates and the user's standing rows. The contract rules reach the specialist through the `agent-protocol` skill, not the kernel. The goal carries what neither can: the references already opened, the premise as a claim the specialist may refute, and the acceptance. What the goal repeats costs attention twice and drifts from the kernel the first time either one changes; what it omits that the kernel does not supply does not exist for the turn.

2. **Acceptance is an assertion the specialist can run and loop on; what only judgment settles is named as a rubric.** The split decides who loops and who seals: the specialist re-runs a command gate until it holds, the verifier grades a rubric it did not write. A check travels as the command to run directly and the result it must produce -- never as an instruction to capture its exit code, filter its output or chain it to another, because a goal that invites shell composition is a defect: the guards refuse the composed form or classify it above what it is, and the check never runs as written. A rubric dressed as a command gets retried instead of judged; a command dressed as a rubric reaches a reader who cannot re-run it.

3. **Isolation by checkout, serialization by branch.** A writing turn owns a worktree cut from the accumulating branch's current tip, so no two writers share a tree or an index. What still serializes is the shared branch: integrations queue one at a time, each composed against the branch as it stands when it runs, because a base fixed at dispatch is stale the moment a sibling lands.

4. **Parallelism is bounded by shared files and integration cost, never by the count of tasks.** A wave groups turns whose blast radii do not overlap; two turns touching one file become one turn or two waves, since their conflict is otherwise paid at integration by whoever lands second. The project's own rule caps how many writers run at once, and that cap is the user's standing rule, not a default to reason around.

5. **A writing task closes through an independent verifier bound to the producer, and the shared branch's CI is the last gate before "done".** The producer cannot seal its own work, so its turn closes needing verification, and the verifier's dispatch names the producer's row -- without that binding nobody can later tell which contract verified which. A green verdict on a branch whose CI is red is not done; it has happened, and the red was found by the next turn to touch the branch.

6. **The specialist creates and releases its own worktree, with its born identity.** The worktree is stamped with the contract and agent ids that exist only once the turn is born, so the orchestrator cannot create it on the specialist's behalf, and it never enters it. The goal names the repository, the project and the base; the specialist does the rest and releases the tree at close, where a dirty one is captured as evidence rather than removed.

7. **A turn is sized before it starts, and is fresh or resumed by what it must know.** A tool-call ceiling fixed in advance, with permission to close partially, is what lets a turn report that it ran out; a turn that exhausts its context mid-work cannot. When the previous turn was cut near its close, implementing and integrating split into two turns. A turn is fresh when it must not know something -- a review, a blind check -- and resumed when it executes what it already knows, because rebuilding known state is pure cost.

8. **Steering in flight is a channel, not a return.** A turn heading the wrong way can be messaged mid-flight, continued once it closes, or replaced by a fresh dispatch. Waiting for its return is only one of the three, and usually the dearest, because the work done the wrong way meanwhile is paid for either way.

Anti-patterns

• **The goal that re-narrates.** Retelling a sibling's findings or the kernel's

contents: lossy where it is new, redundant where it is not, and the retelling is what the specialist trusts.

• **The composed check.** A gate written as a pipeline or an exit-code capture

is refused or reclassified before it runs, and the turn reports on a check nobody asked for.

• **The base fixed at dispatch.** Writers cut from the tip as it stood when the

wave began and integrated in any order: every integration after the first lands on a branch it never saw.

• **Counting tasks instead of files.** A wave sized by how many tasks are ready

rather than by what they touch pays its conflicts at integration.

• **Done on the verdict alone.** A verified task on a branch whose CI is red