From world-builder
Assemble and validate the eight-field dispatch payload for a world-builder task, check the dispatch log for an open record on the same task fingerprint, and on success have the navigator spawn the right agents and append a dispatch record. Mirrors the approval-watch command vocabulary.
How this skill is triggered — by the user, by Claude, or both
Slash command
/world-builder:dispatch-workerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Bridges "founder approved" and "agents start working." The single highest-value skill in the plugin — the eight required payload fields are easy to miss when assembled by hand, and the dispatch log idempotency check is the load-bearing protection against re-dispatching the same task twice.
Bridges "founder approved" and "agents start working." The single highest-value skill in the plugin — the eight required payload fields are easy to miss when assembled by hand, and the dispatch log idempotency check is the load-bearing protection against re-dispatching the same task twice.
This skill is invoked by the navigator when the operator picks an option that would launch builder work. It is also invocable directly when the operator wants to construct a dispatch packet without the full navigator turn.
/dispatch-worker <command>
The command vocabulary mirrors the existing world-builder-approval-watch Codex Automation so that the Phase 2 retarget hands off cleanly. Supported commands:
approve item N — dispatch the Nth approval-queue item with the standard payloadapprove item N with conditions: <text> — dispatch with the additional conditions constraint appended to the payload's Constraints fielddefer all — record a deferral line in the dispatch log; do not dispatch anythingreject item N — record a rejection line in the dispatch log; do not dispatch anythingIf the user invokes without a command, ask which command before proceeding.
The skill operates against process.cwd() and assumes the operator invoked Claude Code from a world-builder checkout root. It does not resolve ${CLAUDE_PROJECT_DIR} or ${PWD} — those do not expand reliably across Claude Code hosts.
Confirm the working tree is a world-builder checkout before any state read:
docs/board/founder-approval-queue.md existsdocs/board/approval-dispatch-log.md existsdocs/board/worker-dispatch-contract.md existsIf any of these is missing, stop and report — the operator invoked from the wrong directory.
Every dispatch payload contains all eight, in this order:
M<N> from the approval-queue itemM<N> / S<N>: <title>canon-memory, continuity-governance, storytelling-workflow, or publishing-proof)api-engineer, app-engineer, ai-engineer, publishing-engineer, or some combination)M<N> / S<N>: <subject>with conditions: <text>A payload with any field empty or marked tbd is invalid and must not be dispatched.
The dispatch payload may carry a model hint that overrides the agent's default model:
model: opus
or, equivalently:
task_complexity: deep
When present, the navigator passes the override into its Agent({subagent_type: ..., model: ...}) call. This is the natural override surface — the dispatch payload already carries Owning Specialist and Constraints; a model hint sits in the same spirit.
In Phase 1 the only Sonnet-default agent is canon-memory. Adding model: opus to a canon-memory invocation is the canonical reason to use the override. The other Phase 1 agent (api-engineer) defaults to Opus already.
Before dispatching:
Read docs/board/founder-approval-queue.md. Find item N from the command. If N is out of range or the item is not in approved status, stop and report.
The approval-queue item must declare a milestone slice (M<N> / S<N>). If it does not, the queue is malformed — surface this back to the operator rather than guess.
Pull each field from the approval-queue item plus the dispatch contract template at docs/board/worker-dispatch-contract.md. For approve item N with conditions: <text>, append <text> to the Constraints field with a ; plus space as separator after the existing constraints.
Read the approval-queue item for an existing Assignment Artifact reference. If one is named (a path to docs/board/...-assignment-packet.md), use that path verbatim — the operator already curated it.
If no packet is referenced, generate a minimal one at docs/board/<YYYY-MM-DD>-<fingerprint>-assignment-packet.md. The generated packet should contain:
## Dispatch Payload section## Required First Output section reflecting the payload's Required First Checkpoint## Constraints section reflecting the payload's ConstraintsThe generated packet is the operator's to refine — the skill writes a workable starting shape, not a final document. Existing assignment packets in docs/board/ (for example 2026-04-22-slice-1-assignment-packet.md) are the reference for tone and depth when refining.
The dispatch record's Assignment Artifact field will link to whichever path resolves here.
The task fingerprint is the canonical hyphenated form of the Approved Task slice descriptor (e.g., m1-s1-inventory-contract-checkpoint, m1-s1-provenance-wiring). Read docs/board/approval-dispatch-log.md and grep for the fingerprint.
If a record exists with Worker Status in any active state (proposed, approved, dispatched, in progress, checkpoint returned), stop and report. Idempotency is non-negotiable. The operator must explicitly mark the prior record blocked, closed (operator extension), or superseded (operator extension) before a new dispatch can land on the same fingerprint.
If a record exists with Worker Status: blocked, surface it to the operator and ask whether to supersede or pick a different task — do not silently re-dispatch.
If any of the eight payload fields is empty, ambiguous, or tbd, stop and ask the operator to clarify. Do not silently fill defaults.
Print the assembled payload back to the operator before invoking any agents:
---
Milestone: M1
Approved Task: M1 / S1: provenance wiring for inventory output
Owning Specialist: canon-memory
Execution Team: api-engineer
Proof Artifact: PR titled "M1 / S1: provenance wiring for inventory output"
Constraints: do not change inventory output schema; preserve existing route paths; no migration this slice
Acceptance Gate: navigator verifies the PR diff matches the sharpened contract before the operator merges
Required First Checkpoint: canon-memory delivers the provenance contract sharpening (fields, source attribution, confidence shape) before api-engineer starts
---
Ask: "Dispatch this payload? (yes / edit / cancel)"
Do not proceed without an affirmative.
On yes:
Agent({subagent_type: "<specialist>"}) with the payload as input. If the payload carries a model override, pass it to the call.integration-engineer.docs/board/approval-dispatch-log.md. On gate failure, the navigator surfaces the failure and presents the operator with options.The shape matches the existing world-builder convention in docs/board/approval-dispatch-log.md. Append-only. One record per dispatch. The next record number (Record N) is one greater than the highest existing record number in the log.
### Record N
Task Fingerprint:
- `<canonical-fingerprint>`
Approved At:
- `<YYYY-MM-DD HH:MM:SS TZ>`
Task:
- `<approved task title>`
Source Automation:
- `world-builder:navigator (manual via /dispatch-worker)`
Assignment Artifact:
- [`<filename>.md`](./<filename>.md)
Dispatch Target:
- `<owning-specialist>`
- `<execution-engineer>`
Worker Thread:
- `<thread-id or human-readable description of the dispatch context>`
Worker Status:
- `dispatched`
Conditions:
- `<condition 1 from payload Constraints>`
- `<condition 2>`
The values match the existing world-builder convention. The navigator updates Worker Status as the dispatch progresses:
proposed — task surfaced but not yet approvedapproved — operator approved, dispatch pendingdispatched — agents launched (the navigator writes this when the record is appended)in progress — engineer is implementingcheckpoint returned — first checkpoint delivered (e.g., specialist returned the sharpened contract)blocked — work stalled; operator must clear the block before re-dispatchdeferred — extension for /dispatch-worker defer all pathsrejected — extension for /dispatch-worker reject item N pathsThe operator may also extend with closed (work fully landed and dispatch is done) or superseded (a later record replaces this one) when curating the log by hand. The navigator does not write those values automatically.
world-builder:navigator (manual via /dispatch-worker) — operator-driven dispatch through the navigator and this skillworld-builder:navigator (via <automation-name>) — Phase 2 retargeted Codex Automation invoking the navigator (e.g., world-builder:navigator (via world-builder-approval-watch))world-builder-approval-watchworld-builder-boardworld-builder-chief-of-staffworld-builder-work-activity-watchA re-dispatch attempt against an existing record is blocked when Worker Status is in any active state (proposed, approved, dispatched, in progress, checkpoint returned). It is also blocked when Worker Status: blocked — the operator must clear the block first.
Re-dispatch is allowed when no record exists for the fingerprint, or when the existing record's Worker Status is a terminal state the operator has set (closed, superseded, deferred, rejected).
This is the load-bearing protection. Phase 1 success criteria explicitly call for at least one verified idempotency catch.
defer allAppend a deferral record in the same shape, with Worker Status: deferred:
### Record N
Task Fingerprint:
- `defer-all-<YYYY-MM-DD-HHMM>`
Approved At:
- `<YYYY-MM-DD HH:MM:SS TZ>`
Task:
- `Operator deferred all current approval-queue items`
Source Automation:
- `world-builder:navigator (manual via /dispatch-worker)`
Assignment Artifact:
- `none`
Dispatch Target:
- `none`
Worker Thread:
- `none`
Worker Status:
- `deferred`
Conditions:
- `<reason if operator gave one, otherwise "no reason given">`
Do not dispatch anything. Do not modify docs/board/founder-approval-queue.md — that edit is the operator's.
reject item NAppend a rejection record in the same shape, with Worker Status: rejected:
### Record N
Task Fingerprint:
- `reject:<canonical-fingerprint>`
Approved At:
- `<YYYY-MM-DD HH:MM:SS TZ>`
Task:
- `<approved task title>`
Source Automation:
- `world-builder:navigator (manual via /dispatch-worker)`
Assignment Artifact:
- `none`
Dispatch Target:
- `none`
Worker Thread:
- `none`
Worker Status:
- `rejected`
Conditions:
- `<reason if operator gave one, otherwise "no reason given">`
Do not dispatch anything. The approval-queue item should be moved out of approved by a separate edit to docs/board/founder-approval-queue.md — that edit is the operator's, not the skill's.
acceptance-gate: failed in the notes, the operator decides whether to re-invoke or re-scope.docs/board/founder-approval-queue.md. The queue is the operator's surface; status changes are the operator's edits.Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub studio-symmetries/world-builder-plugin --plugin world-builder