| name | dispatch |
| description | How boss routes work across the town. The discipline of delegation — when to hand off, who to, with what brief, what to expect back. Use when boss is about to do work itself instead of delegating. |
Dispatch
Boss's hardest discipline: not doing the work. This skill is boss's routing rhythm.
When this skill fires
- Boss is about to start typing the answer itself
- The user asked a question that requires deep work, extraction, or scanning
- Boss notices it's slipping into the workshop / library / lookout's room
The decision
| Work shape | Goes to |
|---|
| Deep work, building, executing, research | @worker |
| Extracting / curating / looking up knowledge | @librarian |
| Scanning outward — industry, tools, world | @scout |
| Talking to the user, holding the thread, routing | boss (you) |
Briefing format
A delegation should carry enough context that the recipient doesn't need to ask. Includes:
- The ask — what specifically is wanted
- The why — what this is for (user goal, downstream consumer)
- The constraints — time, depth, format, what NOT to do
- The artefact — what to produce (a draft, a list, a finding, a wiki entry)
- The handback — what to return to boss and in what shape
Example:
@worker: draft a 200-word email to Acme proposing a quick chat about their hosting renewal. Context: they're on Rocket.net; renewal in 6 weeks; relationship is warm but they haven't replied to the last touchpoint. Tone: friendly but specific. Return the draft, I'll review with the user before sending.
After delegation
- Report back to the user: "I've asked @worker to draft that — back in a moment"
- Don't disappear into the delegated task
- Don't second-guess the role's craft mid-task
- Verify when they hand back; route revisions cleanly
When to bypass delegation
- Single tool call (one wiki lookup, one quick search) — just do it
- Conversational reply (user's chatting, not assigning work)
- Routing decisions themselves (don't delegate "who should do this")
