dispatch
A governed artifact in the stable bundle. Replacing this file on
your machine makes your next attestation come back Drifted, naming this path.
| Description | Fan work out to sub-agents — auto-briefed, parallel, governed, goal-coupled. DEFAULT POSTURE — when a task benefits from an extra set of eyes OR lands faster chunked across helpers, fan it out rather than hand-rolling it solo. Fires on TWO layers: (1) delegate phrasing — 'dispatch / spin up a security-reviewer / architect / code-reviewer / test-runner', 'have an agent look at X', 'delegate this', 'fan this out', 'spin up a team', 'get N takes / council this'; AND (2) value heuristics with NO delegate words — 'review this diff/change', 'scan for critical security issues', 'explore the codebase for X', 'is this correct before I commit?', any review/verify/audit/pre-commit step, a decision worth independent takes, or >=2 independent chunks that parallelize. Layer 2 fires BEFORE you start the work solo, not after. Three modes — SOLO (one Task), COUNCIL (N independent takes IN ONE MESSAGE -> synthesis), TEAM (persistent teammates, goal-forged). NOT for a genuinely trivial step you'd finish faster yourself (the only floor), NOT for routing a message to another live session (that is a separate mechanism). |
|---|---|
| Arguments | none |
| Tools it may use | [Task, Skill, Read, Grep, Glob] |
| Installs at | skills/dispatch/SKILL.md |
| Mode | 0644 — never executable |
| Size | 20754 bytes |
| SHA-256 | 0faa95bf57eb3dbbd3bace18f2664b6ebc8eb35948914a29cd2065788e79d11efetch the raw bytes |
The complete file, verbatim
This is the entire SKILL.md, including its YAML frontmatter:
byte-identical to what installs, not rendered and not reformatted. Hash exactly what is below
and you get the digest above. The table is only a reading aid; this block is the artifact.
---
name: dispatch
description: Fan work out to sub-agents — auto-briefed, parallel, governed, goal-coupled. DEFAULT POSTURE — when a task benefits from an extra set of eyes OR lands faster chunked across helpers, fan it out rather than hand-rolling it solo. Fires on TWO layers: (1) delegate phrasing — 'dispatch / spin up a security-reviewer / architect / code-reviewer / test-runner', 'have an agent look at X', 'delegate this', 'fan this out', 'spin up a team', 'get N takes / council this'; AND (2) value heuristics with NO delegate words — 'review this diff/change', 'scan for critical security issues', 'explore the codebase for X', 'is this correct before I commit?', any review/verify/audit/pre-commit step, a decision worth independent takes, or >=2 independent chunks that parallelize. Layer 2 fires BEFORE you start the work solo, not after. Three modes — SOLO (one Task), COUNCIL (N independent takes IN ONE MESSAGE -> synthesis), TEAM (persistent teammates, goal-forged). NOT for a genuinely trivial step you'd finish faster yourself (the only floor), NOT for routing a message to another live session (that is a separate mechanism).
allowed-tools: [Task, Skill, Read, Grep, Glob]
# TEAM mode additionally needs your harness's persistent-teammate tools — a
# team-create tool and a teammate-message tool — under whatever names your
# harness registers them. Add them here only if they exist in your environment;
# SOLO and COUNCIL run on the list above alone.
---
# /dispatch — fan-out, council & team orchestration (default-to-parallel)
*A mistwire skill, ported for public use. Harness assumptions are stated inline; where a step
depends on infrastructure you may not have, it is written as a pattern with its precondition
named rather than as a command that would fail for you.*
**Posture:** on a flat-rate subscription plan, parallel capacity is *already paid for* — use it.
The question is never "do I have permission to fan out," it's **"does fanning out make this land
better or faster?"** Default to **yes**. The cost that matters is latency + coherence, not dollars
(marginal spend on a fixed-capacity plan ≈ $0) — so the gate is **value**, not spend. If you bill
per token instead, keep the same two-layer trigger but move the spend gate (below) earlier.
This skill standardizes a heavy **assistant-labor** pattern. The measurement that produced it:
**≈992 raw sub-agent dispatches over 8 weeks, with 0 covering skill** — counted from our own
session-transcript corpus. That number says the assistant *already* fans out constantly and
hand-rolls the briefing / envelope-format / synthesis discipline every single time. This skill makes
it default, governed, and observable.
## When to fan out — the trigger has TWO layers
**Layer 1 — phrasing (explicit, always fires):** "dispatch / delegate / fan out / spin up a
\<agent\> / get N takes / council this / stand up a team."
**Layer 2 — value heuristics (fire even with NO delegate words — this is the default-on layer):**
before doing any non-trivial task solo, ask:
- **Extra set of eyes?** Touches security / architecture / correctness, or it's anything
pre-commit, or it's a "is this right?" question → fan a reviewer (**SOLO**) or independent
takes (**COUNCIL**).
- **Lands faster chunked?** ≥2 independent sub-tasks (files, modules, search angles, review
dimensions) with no inter-dependency → fan them to helpers **in parallel**.
- **Multi-step + persistent roles?** Work that spans many turns and needs roles to persist and
message each other → **TEAM**.
If either heuristic is **yes → fan out by default.** The **only floor**: a step you'd *genuinely*
finish faster yourself than the briefing + spawn + synthesis round-trip (a one-liner, a single
read) — and "faster yourself" must be *true*, not a reflex to avoid delegating.
## Modes
### SOLO — one specialist, one Task
Choose the agent type by domain. This routing matrix is the portable core of the skill — map the
left column to whatever specialist definitions your harness loads.
| Need | Agent type |
|---|---|
| design / architecture impact | `architect` |
| critical / high-severity security review | `security-reviewer` |
| function / nesting / dead-code review | `code-reviewer` |
| run tests, triage failures (TDD) | `test-runner` |
| CI / container / infra config | `devsecops-reviewer` |
| deploy readiness | `deployment-verifier` |
| compaction of prompts, role definitions, wire formats | `format-optimizer` |
| docs / changelog / API refs | `documentation-writer` |
| broad read-only search | `explore` / `general-purpose` |
Mechanism: in-session sub-agents spawn via the **Task / Agent** tool — one specialist = one Task,
with `subagent_type` naming an entry in your specialist registry.
*A note on out-of-band dispatch:* if your stack also has a bus or MCP server that can dispatch
work **across** sessions, verify it is actually exposed in the live tool registry before you plan
around it. We once shipped a cross-session dispatch call that lived in an MCP server's source but
was never exposed on the running server; sessions kept planning around a method they could not
call. **Do not conflate "not exposed" with "not built"** — and do not conflate "built" with
"callable right now." In-session sub-agents use Task/Agent; anything cross-session gets verified first.
### COUNCIL — N independent takes → synthesis (spend-aware)
Decision-class questions only. Layer 2 may *propose* a council when a decision
looks worth independent takes, but N parallel advisors is real spend, so it is
proposed and confirmed rather than fired automatically. Layer 1 phrasing
("council this", "get N takes") invokes it directly. The mechanics, inlined so this section stands on its own:
1. **N advisors, same question, zero cross-talk.** Each advisor gets the identical framing and
returns an independent take. They must not see each other's output on the first pass — shared
context collapses N takes into one take with N signatures.
2. **Anonymized peer review.** Strip attribution, hand each advisor the other takes, ask for
agreements / contradictions / anything the others missed. Anonymizing is load-bearing: named
takes get deferred to by role seniority instead of judged on merit.
3. **Chairman synthesis.** The main session — never an advisor — synthesizes, resolves
contradictions, and decides. **Agents produce findings; the main session decides.** An advisor
that decides has quietly become an unsupervised actor.
Spend-gated for large panels (see Spend gate).
### TEAM — persistent, multi-step, goal-coupled
For parallel multi-step work where teammates hold **role identity across turns**. *Precondition:
this assumes a harness that supports persistent teammates with their own inboxes — i.e. a
team-create tool and a teammate-message tool. Without those, degrade to repeated SOLO/COUNCIL
rounds; the briefing and synthesis discipline is unchanged.*
- **Role-named** teammates (`sec-audit`, `arch-review` — not personas). A teammate named for a
role is replaceable and auditable; a teammate named for a character is neither.
- **Pre-approve** common tool permissions before spawn (kills prompt storms). **Never spawn with
permission checks disabled** — that setting propagates to every teammate the lead spawns, so one
careless flag un-governs the whole team.
- **Lead = scheduler.** Teammates wake on lead-dispatched messages, not peer sends. A **quiet lead
is a dormant team.** This is the team failure mode we hit most often.
- **Active default, not idle default.** Teammates draft between inbounds and emit chunk-boundary
STATUS pings; idle-wait-for-inbound is the failure mode, not the resting state.
- **Lead owns cleanup** — shut teammates down FIRST, then tear down the team. Never delegate
cleanup to a teammate; a teammate cleaning up the team it lives in is a half-executed shutdown.
One team per lead; no nested teams.
## Goal coupling — give the team a stop condition it can actually evaluate
A team with no stop-condition either loops forever or goes dormant. So dispatch **forges a goal and
sets it as the lead's session goal** — turning a completion/stop hook into the **team's heartbeat**:
it keeps the lead scheduling the team across turns until the work is genuinely done. This is the
cure for "quiet lead = dormant team."
*Precondition: this assumes a harness with a session-level goal that some stop/completion hook
evaluates. If yours has none, steps 1–2 still pay for themselves — a binary-checkable DONE
condition is worth writing even when only a human reads it.*
1. **Forge it — never make the human write it.** Call the **`goal-forge`** skill to draft a short,
binary-checkable goal from the task *or* from the project plan. Shape: objective · phases ·
single DONE condition · non-goals · ownership. Satisfied by construction, zero cognitive load on
the operator.
2. **Fence the human-gated phases — the anti-loop rule.** Any phase depending on a human decision,
an external keystroke, or another party MUST be tagged `[HUMAN-GATE]` / `[DELEGATED:<who>]`, and
the DONE condition MUST be satisfiable **from the agent side.** So when the only thing left is
"awaiting the human," the stop hook reads *done-from-my-side* and **stands down** instead of
re-firing. This is exactly the loop that ran ~10× in one session: a fuzzy "stop when we're ready
to pivot" evaluated against human-gated residue that the agent could never clear.
3. **Poll sensitivity — blocked-on-human ≠ keep-hammering.** While blocked on a human in the loop,
the lead **holds**: no re-drive, no re-spawn, no repeated pings — it waits. Blocked on *agent*
work → keep driving. Blocked on *human* → wait quietly and surface the single decision.
*(Goal design delivers this today via the fence in step 2. A literal hook-level back-off cadence
is a deeper, separate lever — flagged honestly, not claimed here.)*
4. **Clear on done** — when the goal is met, clear it, so a stale goal can't re-fire later against
unrelated work.
## Auto-briefing — MANDATORY, no exceptions
Before spawning ANY agent or teammate, assemble a briefing with four parts:
1. **Role** — who this agent is and the one lens it reviews through.
2. **The relevant governance subset** — the specific rules from your role definition file that bind
this task. Not the whole file; the subset that applies. This is what makes a dispatched agent
*inherit* governance instead of guessing at it.
3. **The task boundary** — what's in scope, what is explicitly not, and what it must not modify.
4. **The expected return shape** — findings table, PASS/FAIL verdict, ranked list. Name it, or you
will get prose you then have to parse.
**No agent runs un-briefed.** A sub-agent inherits none of your session's context, none of your
constraints, and none of your standards unless you hand them over explicitly. The most expensive
failure mode in fan-out is not a wrong answer — it's a confident answer produced under rules the
agent never saw.
## Envelope framing — structured, not prose
The dispatch envelope and all inter-agent / inter-teammate messages use a **compact pipe-delimited
format**, not natural-language prose. A sub-agent's return is raw data for synthesis, not a
human-facing document. Pick a format and hold it; the shape matters more than the syntax:
```
SPAWN/1|role=security-reviewer|scope=<paths or diff>|task=<one line>
|rules=<governance subset>|return=FINDINGS_TABLE|out_of_scope=<...>
```
Why it matters: prose briefings drift, get partially followed, and cannot be diffed between spawns.
A delimited envelope makes "did every advisor get the same question?" a mechanical check.
## Parallel fan-out — ONE message, N calls
**Measured failure: 633 of 634 spawns in our corpus were serialized.** For N>1, spawn
**concurrently** — one assistant message containing multiple `Task` calls — never serially.
Wall-clock becomes the slowest agent instead of the sum, and serialized spawns additionally replay a
growing context into each successive spawn.
Concretely, a 3-advisor COUNCIL is ONE response containing THREE Task invocations:
```
<one assistant message>
Task(subagent_type=architect, prompt="SPAWN/1|…take A…")
Task(subagent_type=security-reviewer, prompt="SPAWN/1|…take B…")
Task(subagent_type=code-reviewer, prompt="SPAWN/1|…take C…")
</one>
```
If you notice you've emitted a lone Task and are about to await it before spawning the next
*independent* one — stop; batch the remainder into your next message.
## Spend gate — scoped, not removed
On a flat-rate subscription, dev-session fan-out is paid-for capacity → it gates on **value** (the
Layer-2 heuristics), not a dollar preflight. Keep a real cost preflight for where spend is real: a
large **COUNCIL (≥4 agents)**, anything touching **production or the deploy path**, or a **TEAM
expected to run long**. If the cost check FAILs there → refuse and report, don't spawn.
Cost governance on the product/deploy path is **untouched** by this skill — it is a one-way ratchet.
This only scopes the *dev-session* gate to where dollars actually accrue. If you are on
metered/per-token billing, invert the default: gate every fan-out ≥3 agents.
## Observability — know every time it fires
*Pattern (precondition: a harness with pre-tool-use hooks).* Record every dispatch firing with a
**PreToolUse hook on the spawn tools** (`Task`, plus your team-create tool if you have one) that
appends one JSONL line per spawn to a local log:
`{ts (spawn-time), session_id, event, tool, who (subagent_type or team), desc}`.
The design decisions that make it trustworthy:
- **Hook-enforced, not skill-instructed.** A skill is just instructions and can be skipped; a
pre-tool-use hook fires on the tool call regardless of whether the model remembered the skill.
- **Pure observability — always exits 0.** It can NEVER block a dispatch. An observability hook that
can fail closed is an outage generator.
- **Local-append only.** No network call, no round-trip to a remote bus. A flaky wire on every single
spawn would be unkind to the system it observes.
- **It logs only what the tool input carries.** So it is the reliable **spawn-time floor**, not the
skill's full semantic record. Richer fields (`mode`, `goal-ref`, `gate-result`) are
dispatch-internal and are a best-effort skill-side addition.
Honest claim boundary: the hook records *that a sub-agent was spawned, when, and of what type*.
No more. Don't let a spawn log get described as a results log.
## Reporting — honest, or it isn't reporting
Report each agent's result as **PASS / FAIL / NOT-RUN**. There is no fuzzy fourth state, and a check
that did not run is NOT-RUN — never a silent skip, never downgraded to a pass.
Synthesis distinguishes **CONFIRMED** (multiple agents agree, or independently verified) from
**UNVERIFIED** (a single take). Never present one agent's opinion as consensus.
## NOT this skill (negative boundaries)
- **Routing a message to another already-running session** (cross-session or cross-machine mention)
→ that's a separate mechanism, not a spawn.
- **A genuinely trivial step** you'd finish faster yourself than the spawn round-trip — the only
floor, and it must be *true*-faster, not delegation-avoidance dressed up as efficiency.
- Persistent role teammates are **not** excluded — TEAM mode owns them.
---
## DoD self-check (mistwire 9-gate, recorded honestly)
1. **Trigger description** — **MET.** Two-layer trigger (phrasing + value heuristics), explicit
default-to-fanout posture, three modes named, negative floor + cross-session boundary.
2. **allowed-tools scoped** — **MET, justified.** `Task` (SOLO/COUNCIL spawn) · `Skill` (calls
`goal-forge` and the cost check) · `Read/Grep/Glob` (assemble briefings); TEAM mode adds your
harness's team-create and teammate-message tools where they exist. **No `Bash`** — the spend
gate and goal-forge go through skills, not shell; observability is a *hook*, not skill-side
shelling.
3. **Cites reason-to-exist** — **MET.** ≈992 raw sub-agent dispatches with 0 covering skill;
633/634 spawns serialized; the ~10× stop-hook re-fire loop. Encodes the mandatory-briefing rule,
the council pattern, and the agent-team construction rules.
4. **Grounded facts** — **MET** for the routing matrix and the serialization measurement.
**OPEN/HONEST:** the exact syntax for *setting* a session goal is harness-specific and was
verified here only for the *clear* form — confirm it before the TEAM goal-set path ships in your
environment. The "≈$0 marginal" claim is a subscription-capacity assumption, not a metered
measurement.
5. **Honest reporting** — **MET.** PASS/FAIL/NOT-RUN per agent + CONFIRMED vs UNVERIFIED synthesis.
6. **Trigger-fire validation** — **NOT-RUN** (needs a fresh session). Prompts: ① "dispatch a
security-reviewer on this auth change" → SOLO ② "get three independent takes on framework A vs B"
→ COUNCIL ③ "stand up a team to port the federation module" → TEAM (forges + sets a goal)
④ value-layer, NO delegate words: "is this crypto change correct before I commit?" → SHOULD
auto-fan a `security-reviewer` (extra-eyes heuristic). Negatives that must NOT fire: routing a
message to a named live session; "what's 2+2 / read this one line" (trivial floor).
**Run before shipping.**
7. **Visual bar** — **N/A** as a standalone (dispatch emits a synthesis; a formal report defers to a
rendering skill) — but its *output* is still bound by Gate 9: a synthesis that is a wall of noise
is unkind.
8. **Cognitive-load fit for the human operator** — **MET.** Default-to-fanout *removes* the "should
I delegate?" decision from the human (the assistant does it by default); goal-forging *removes*
the goal-writing burden; human-gate fencing *removes* the anxiety loop of a task that keeps
re-firing; lead-as-scheduler means the assistant drives, not the human. Litmus: on a low-capacity
day the operator says "look into X" → the assistant auto-fans-out, self-goals, and drives to done,
surfacing only the human-gated decision. Helps, doesn't interrogate.
9. **Kindness — to the USER and the SYSTEMS they run on (NOT OPTIONAL).**
"Done" is not "it works." Done is **least-impactful, thoughtful, and usable** — kind in *effect*
and in *experience*. Effective-but-ugly, effective-but-burdensome, or effective-but-debt-laden is
**unkind, therefore not done.**
- **Kind to the user** — reduces cognitive load, never adds it; leads with one action, no
overwhelm; visuals meet the bar (**Gate 7 is a *subset* of this** — bad visuals fail kindness);
a pleasure to use, not a chore.
- **Kind to the systems** — least footprint; **incurs no tech debt** (debt is unkindness deferred
onto both user and system); leaves the host no worse; reversible and clean.
- **Rewrite, don't punt** — when work fails to meet expectations, we **redo it now**. We do not
pass shoddy or incomplete work downstream for future-us, a teammate, or our successors to
untangle. Deferring substandard work is tech debt by a kinder name; whoever catches the
shortfall owns the rewrite, in the moment they catch it.
- **This skill, honestly:** default-to-fanout is *kind* when it removes burden (auto-delegate,
auto-goal, pre-approved permissions so there's no prompt storm, lead synthesizes the noise
away). Named tension: **"fan out by default" and "least-impact" only reconcile because the gate
is *value*, not reflex** — fanning out work that genuinely parallelizes is *less* wasteful than
a slow solo grind, but spawning trivial work thrashes capacity, so the floor bites. If a
dispatch spams approvals, floods context, or leaves debt, it **FAILED this gate** regardless of
whether it "worked."
**Before you rely on this in your own project:** two gates stay open until *you* close them — Gate 6
(run the four fire-validation prompts in a fresh session) and Gate 4 (confirm the goal-set syntax
your harness actually accepts). If you build the companion dispatch-log hook, security-review it
like any other code that runs on every tool call, and budget for the deployment gotcha we hit:
**hook settings edited mid-session generally do not hot-reload**, so a freshly wired hook starts
firing from the *next* session, not the one that wrote it — verify it fires before you count on its
log. Recorded as open, not waved through.