| name | coordinator-dispatching-work |
| description | Use when starting an epic, dispatching to an implementer, creating a worktree for an agent, or spawning a sub-agent. Loads coordinator-specific discipline for kicking off implementation work. |
Coordinator: Dispatching Work
Use thrum tmux launch — not raw send-keys
Why: Manual tmux send-keys 'claude' followed by $thrum-prime skips
identity registration and produces silent CWD drift. The
thrum tmux launch <name> flow registers the agent against the worktree path
correctly and gives the daemon a real PID to track. (Source:
findings_coordinator.md — "Use thrum tmux launch — not send-keys — to start a
runtime".)
How to apply: Whenever you need to start a runtime in an existing tmux pane,
use thrum tmux launch <session_name> even if you've already typed the runtime
command yourself. If you've already started one wrong, kill the pane and
re-launch via the daemon. If the pane doesn't exist yet, use
thrum tmux start <name> (creates, launches, primes, attaches in one command).
Recycling an agent: destroy then teardown
Why: The inverse of dispatch is removal, and it has the same "two-step
ritual or things break silently" property as dispatch via tmux launch + thrum
send. See coordinator-managing-state-and-lifecycle § "Destroy an agent before
tearing down its worktree" for the canonical sequence (thrum tmux kill BEFORE
thrum worktree teardown). The dispatching skill mentions it here so you find
the cross-reference when planning a wave recycle, not just when reading the
lifecycle skill end-to-end.
Never spawn sub-agents into worktrees where Thrum agents are running
Why: Sub-agents (Agent tool) and Thrum agents (thrum send) are different
coordination mechanisms. A sub-agent spawned into a worktree where a Thrum agent
already sits competes for files, identity, and tmux state — the result is
identity drift, broken nudges, and silent message loss. (Source:
findings_coordinator.md — "No sub-agents into live worktrees".)
How to apply: Run thrum team before spawning any Agent tool call. If a
worktree shows a registered agent, communicate with it via
thrum send "<message>" --to @<agent_name> instead. Sub-agents are for
research/explore, code review, and message listeners running in the main repo —
never for implementation work in another agent's worktree.
Dispatch via thrum send after launch — not via tmux send-keys
Why: After thrum tmux launch, all coordination flows through the inbox +
daemon nudge: thrum send enters the message in the daemon's state, the daemon
nudges the pane, the agent reads the inbox and starts work. Injecting the prompt
with thrum tmux send or tmux send-keys bypasses the inbox entirely, breaks
the nudge for future messages, and strands the agent without a recorded message.
(Source: findings_coordinator.md — "Dispatch via thrum send after tmux launch,
not via tmux send-keys".)
How to apply: Correct flow: thrum tmux launch <name> → agent auto-primes →
thrum send "work prompt" --to @agent_name → daemon nudges the pane → agent
reads inbox and begins work. Never inject the prompt as raw keystrokes.
Prompt construction for implementers
Why: Implementer agents work better with a structured handoff than a
free-form request. Inconsistent dispatch produces inconsistent reports and
re-dispatch overhead.
How to apply: Every dispatch prompt should include:
- The epic/task title and bead ID
- One-paragraph scope (what to build, what NOT to build)
- Acceptance criteria as bullets
- The worktree path the work happens in
- An explicit reminder to pass
model: on any sub-agents the implementer
spawns (haiku for mechanical, sonnet for judgment)
- Spec/plan paths to read before starting
Never rename an agent tied to a worktree
Why: Agent identity is bound to the worktree, not the epic. Re-registering
@implementer_api as @implementer_billing mid-flight creates two identity
files in the same worktree, causing persistent stop-hook misfires and routing
failures. (Source: findings_coordinator.md — "Never rename an agent tied to a
worktree".)
How to apply: Run thrum team before assigning new work to confirm the
existing identity name. Send work to that name. Do not use thrum quickstart
with a new name in a worktree that already has an identity. If you absolutely
need a fresh identity, kill the existing tmux session and register a new one
with a different name — do not rename in place.
Propagate model-selection discipline downward
Why: Sub-agents inherit the parent model by default. A coordinator on Opus
that spawns an unspecified sub-agent gets Opus-cost work for tasks that need
Haiku. The same trap repeats inside an implementer's worktree: if the
implementer doesn't propagate the discipline, their own sub-agents silently
inherit too. Cost compounds across a session. (Source: findings_coordinator.md —
"Always pass explicit model on sub-agent spawns".)
How to apply: Every dispatch prompt should include the model-selection rule
explicitly: "When you spawn your own sub-agents, pass explicit model: —
haiku for mechanical work (lint, tests, find/replace), sonnet for judgment
work (review, complex implementation), opus only when justified. Default to
sonnet over opus." Audit the dispatch prompt before sending.
The impl-prompt review stamp satisfies pre-dispatch review
Why: When the planning-skill review loop runs, its final gate reviews the
implementation prompt against the plan — which IS the pre-dispatch review.
Re-running a pre-dispatch prose review on a prompt that already passed the loop
double-reviews the same artifact and wastes a cycle.
How to apply: At dispatch, grep the impl-prompt for the loop's verdict stamp
(case-sensitive, literal):
grep -F 'THRUM-REVIEW: stage=prompt verdict=Ready:Yes' "$PROMPT_FILE" \
|| grep -F 'THRUM-REVIEW: stage=prompt verdict=OVERRIDE' "$PROMPT_FILE"
- Stamp present → the pre-dispatch review is already satisfied; SKIP
re-running it and dispatch.
- Stamp absent → fall through to the normal pre-dispatch dual review. Do NOT
block dispatch on the stamp — it is a shortcut that lets you skip a redundant
review, not a new hard requirement (pre-feature prompts and prompts from other
flows won't carry it).
This is the prose side of the boundary; the post-DONE dual-review (which reviews
the implementer's CODE, a different artifact) always runs separately. The prompt
is never reviewed twice. (See coordinator-running-review-cycles for the
post-DONE side.)
Project-specific rules (already loaded)
Project-local rules under bd memories coordinator-rule- were loaded at session
start by your preamble. If a project-local rule conflicts with a universal rule
above, the project-local rule wins; surface the conflict in your reply so the
user can decide whether to graduate or remove the override.
If you accumulate a new rule mid-session (the user corrects you), capture it via
bd remember --key coordinator-rule-<slug> "<rule + Why + How to apply>".
