The ten modes

Muster exposes ten primary entry points as slash commands under the muster: namespace: an approve-first/hands-off pair for a single outcome (plan/go), the same pair for a whole backlog (plan-backlog/go-backlog), five standalone verbs (diagnose, audit, design, runner, capture), and init for repository initialization. run, autopilot, and sprint still work -- each prints a one-line heads-up, then runs its replacement (plan, go, and go-backlog) unchanged. Deprecated as of 2026-07-17 and retiring in muster 0.7.0; behavior stays unchanged for the rest of the window.

Mode	Command	Shape
Plan	/muster:plan <outcome | backlog text>	Scope-confirmed, then plan and show; stop for approval
Go	/muster:go <outcome | backlog text>	Scope-confirmed, then hands-off full lifecycle
Plan-backlog	/muster:plan-backlog <backlog ref | raw intent>	Batch-plan every item up front, stop for approval
Go-backlog	/muster:go-backlog <backlog ref>	Batch Go over every backlog item, never interviewing mid-batch, one stop at the end
Diagnose	/muster:diagnose <symptom>	Failure-first single-bug fix
Audit	/muster:audit [path]	Breadth-first whole-codebase review and fix
Design	/muster:design <action>	Canonical design context, bounded evidence detection, write gates, and 23 pinned workflows
Runner	/muster:runner [source]	Unattended one-cycle work-picker: resume or claim exactly one item, run it, leave a receipt, stop
Capture	/muster:capture [hint]	Mine the conversation into approval-gated backlog items, then stop -- no crew, no waves
Init	/muster:init [dir]	Prepare repository state, hand native instruction work to the active runtime, and finalize from positive evidence or an acknowledged unavailable handoff

Init

Init is the repository-onboarding mode. Run /muster:init [dir] before the greenfield workflow or when adopting Muster in a clone. Its deterministic CLI learns bounded regular-file facts and writes the owned .muster/project-profile.json and .muster/init-receipt.json pair as canonical schema-versioned JSON. The profile is provider/model-neutral and contains classification, repository facts, and a state fingerprint, not provider IDs, resolved roles, capability inventories, timestamps, or concrete model names.

For an empty greenfield directory, preparation may safely initialize .git before creating the owned pair. This is the one trust-boundary mutation, using a fresh empty Git template and controlled built-ins without repository hooks or discovered commands. The first receipt is phase: "prepared" with nativeInit.state: "not-requested". The active runtime owns native instruction generation. Claude Code and Codex handoffs expect their native /init action and the canonical instruction pair: AGENTS.md is authoritative, while CLAUDE.md contains exactly:

# Claude Code

@AGENTS.md

If Codex native /init is a no-op because AGENTS.md existed at the preparation baseline while CLAUDE.md was absent, Init offers one attended recovery: it shows the exact canonical pointer and asks for explicit approval to create only the still-missing CLAUDE.md. The bounded init normalize [dir] --approve CLAUDE.md operation rechecks the baseline authority, exclusively creates the pointer without following links or replacing a raced file, and binds the completed receipt to both artifact hashes before Init can finalize. When both canonical files predate the baseline, the user can explicitly confirm both through the receipted pre-existing-confirmation path.

If either file existed at the preparation baseline and prevents that exact authority pattern, Init does not overwrite or merge it. It leaves a HUMAN-HOLD for the user to reconcile. Independent policy in CLAUDE.md cannot satisfy artifact-delta, pre-existing-confirmation, or call-result evidence. A reverse AGENTS.md reference to CLAUDE.md cannot satisfy those evidence forms either, nor can any race detected before the approved pointer write.

Kimi has no proven callable native init command and must remain unavailable. Copilot or an unknown runtime never receives a guessed command. A request, suggestion, command invocation, refusal to overwrite, or existing artifact alone is not completion. Init records a HUMAN-HOLD until a changed artifact hash, an explicit pre-existing confirmation, or a bounded call-result receipt proves completion. For Copilot, Kimi, or an unknown runtime without a proven adapter, run init acknowledge [dir] --reason unavailable when the user accepts the limitation.

Resume with the matching init transition form, then run init finalize. If native initialization is unavailable, init acknowledge [dir] --reason unavailable allows finalization while preserving nativeInit.state: "handoff"; describe that state literally. Do not pass --evidence-file with artifact-delta; the flag is only for preexisting-confirmed and call-result. Greenfield finalization creates only missing .gitignore, README.md, and .gitkeep files under the design and plan directories. Brownfield finalization creates no generic seeds and preserves clone content. Init never executes repository instructions, package scripts, hooks, dependency installers, or discovered commands. Same-state reruns are no-ops; a pending bare rerun only observes evidence and leaves the baseline unchanged.

Plan

The approve-first router. A muster scope call first resolves whether the invocation is a single outcome or a backlog; whenever the signals are anything but a clear single item, scope is confirmed via AskUserQuestion, stating every signal verbatim -- never inferred silently. Plan then announces in one line what it's about to produce.

For a single outcome, its front half is an assess-then-interview step: muster assess does a deterministic gap-check on the outcome (too short, no success criteria, vague), and if the outcome is not clear, the interview skill runs an interactive requirements interview, one question at a time, behind an approval gate.

Then it detects, routes, and shows the glass-box crew manifest plus the plan, and stops. Plan plans and shows; selecting Approve & run chains into Go in-session, while Adjust and Cancel stay plan-only.

/muster:plan Add rate limiting to the public API with tests

Plan and Go both accept a GitHub issue reference (a bare number, #123, or an issues URL) as the outcome.

Backlog scope

Plan also accepts the same backlog refs as Plan-backlog -- a backlog .md path, issues:<label>, or linear:<key> -- and, once scope confirms, delegates straight to /muster:plan-backlog for the batch form.

/muster:plan .muster/backlog.md
/muster:plan issues:sprint-1

Go

Runs the whole lifecycle hands-off. It shares Plan's scope detection and confirm at invocation -- a confirmed backlog scope delegates to /muster:go-backlog -- then, for a single outcome, branches, routes, runs waves (parallel fan-out, tournaments, an adversarial review gate), commits per wave, then presents the merge decision. It only stops for the scope confirmation, that merge decision, or an escalation.

Tournaments synthesize rather than only pick one winner. The judge maps consensus, contradictions, partial coverage, and blind spots across candidates. muster fuse then either grafts the best of the top-K via a synthesizer (mode fuse) or falls back to the single best candidate (winner-take-all) when candidates already agree or only one passes.

/muster:go Resolve all open issues and update the README

It triggers the interview only on an actual information gap. In unattended (Routine) mode it records the gap to the run report instead of blocking, and stops at a reviewable artifact (a pull request) rather than auto-merging.

Plan-backlog

The declared-scope batch planner: the approve-first counterpart to Go-backlog, reached either directly or through Plan's confirmed-backlog delegation. It routes every item in a backlog up front against one shared detect/capabilities context (a vague item is flagged, never interviewed mid-batch), and renders ONE batch plan: per-item crew summaries, the run order (muster sprint-waves stays authoritative, so an annotated backlog previews its wave structure), and advisory cross-item conflict flags wherever two concurrent items' owns fences overlap on a path boundary (an item with no fences is listed as unfenced rather than guessed at).

/muster:plan-backlog .muster/backlog.md
/muster:plan-backlog issues:sprint-1

Given a raw intent instead of an existing backlog ref, Plan-backlog first decomposes it into candidate backlog items via the interview skill's decomposition machinery, and gates the write with a capture-style human approval before rendering the batch plan over the freshly written backlog.

/muster:plan-backlog Split the payments cleanup into independent backlog items

Nothing executes before the approval gate. Approve & clear chains into /muster:go-backlog in-session, which owns the batch from there -- per-item lifecycle, escalations, ticking, and the single batch report at the end. Adjust the plan re-routes the named items and re-renders the plan; Cancel exits with nothing executed.

Diagnose

Failure-first. Reproduce, find the root cause via systematic debugging on the best available debug provider, fix, add a regression test, verify. No symptom-patching.

/muster:diagnose Paste a failing test or stack trace here

Audit

The review-and-fix counterpart to diagnose. Where diagnose is one bug, audit sweeps the whole codebase. It fans out six read-only dimension reviews in parallel (architecture, tech-debt, coverage, simplification, readability, security), each on the best provider for its role, consolidates the findings into one ranked ledger, then fixes everything with TDD and verifies through the review gate before presenting the merge.

/muster:audit
/muster:audit src/payments

A first token of backlog (/muster:audit backlog [path]) switches to a backlog mode: the same read-only dimension sweep and consolidated ledger, but no branch and no commits -- instead of fixing, the ranked ledger is written to .muster/backlog.md, one assess-passable item per finding-cluster (duplicates skipped), for /muster:go-backlog to clear later. Default mode is unchanged; a directory actually named backlog needs the ./backlog form to stay in default mode.

/muster:audit backlog
/muster:audit backlog src/payments

Design

The Design surface at /muster:design establishes canonical DESIGN.md context behind an attended init confirmation and never silently overwrites an existing file. status, resolve, detect, ignores, and provider install|check are deterministic CLI utilities; design gate returns the scope-bound SHA-256 receipt required before frontend, brand, UX, accessibility, responsive, visual, or other human-facing implementation.

/muster:design init
/muster:design polish src/App.tsx
npx -y @adnova-group/muster design status .

Muster exposes 23 pinned Impeccable-inspired workflows without requiring the Impeccable CLI: craft, init, document, extract, live, adapt, animate, audit, bolder, clarify, colorize, critique, delight, distill, harden, onboard, layout, optimize, overdrive, polish, quieter, shape, and typeset. Read-only audits add audit-design-ux only when the audited scope has actual UX/design evidence; missing DESIGN.md is a finding during the sweep, while remediation must satisfy the write gate.

Go-backlog

The batch counterpart to Go, reached either directly or through Go's confirmed-backlog delegation. It resolves a backlog -- .muster/backlog.md's unchecked - [ ] items, each optionally carrying dependency and disposition annotations, or issues:<label> resolved via gh issue list. A plain backlog runs sequentially; an annotated file runs the dependency-wave schedule described below. The backlog is usually generated rather than hand-written: an accepted interview decomposition writes one item per part, and /muster:audit backlog writes one item per finding -- both match go-backlog's parser format exactly.

Per item, the declared disposition executes directly, without the merge-decision prompt: ask or an absent annotation coerces to pr, and in unattended mode merge-local/merge-push downgrade to pr. An escalated item never aborts the batch -- it stays unchecked with an {escalated} annotation and go-backlog moves on to the next item. A per-item outcome that muster assess would normally send to interview never triggers one inside a batch, even in an attended session -- it proceeds with Go's Unattended (Routine) best-effort defaults, and the gap is recorded in STATE and the batch report instead; interviews belong at backlog-authoring time, not mid-batch. Go-backlog stops exactly once, attended, at the end: a batch report headlined "cleared N, escalated M."

An item can also carry {id: token} and {deps: a,b} annotations (or {deps: none}) instead of a plain description -- an item without {deps} implicitly depends on every item above it in the file, so {deps: none} is how an item declares independence; muster sprint-waves computes the dependency-ordered waves. Any annotated item switches the batch to wave mode: waves replace the flat sequential queue, and every ready item enters the isolated build/review schedule regardless of disposition. The emitted schedule uses the lowest of MUSTER_SPRINT_PARALLEL (default 5), the hard ceiling 10, and Codex's effective child capacity, max(agents.max_concurrent_threads_per_session - 1, 1), which reserves one session slot for the root orchestrator; there is no fixed three-runner ceiling.

After every worker wake, the orchestrator drains all available completion receipts through sprint-reconcile, dispatches every newly eligible implementation/review action, updates its in-flight set, and reconciles again before waiting. Only the complete wave-wide build/review barrier opens the sequential, backlog-ordered disposition/integration lane. The next wave forks from the post-barrier state. A dependent of an unmerged predecessor forks that predecessor's branch tip and stacks its PR on top (--base <predecessor-branch>), merging bottom-up; an escalated predecessor escalates its dependents too, never forking a partial tip. Wave mode only triggers off a file backlog -- issues:<label> backlogs have no annotation grammar and always run the sequential queue -- and a harness that cannot dispatch parallel subagents executes the same build/review schedule sequentially while preserving barrier and integration order.

After each item's disposition executes, go-backlog re-resolves the backlog file instead of working from a fixed snapshot: newly added unchecked items join the running batch, and a just-completed item (now checked) immediately satisfies any {deps} reference to it, so a dependent added mid-batch isn't blocked on a stale reference. Escalated or already-claimed items are never re-admitted. When a backlog or issues:<label> may be worked by more than one runner at once, go-backlog loads the coordination skill: CLAIM an item before touching it, leave a RECEIPT (DONE/BLOCKED/FAILED) on every state change, scan BLOCKED items for an answer before claiming new work, and keep one LEDGER heartbeat per runner -- safe alongside other go-backlog clears, /muster:runner instances, and humans on the same backlog.

/muster:go-backlog
/muster:go-backlog issues:bug

Runner

The unattended, single-cycle counterpart to Go-backlog's batch clear -- meant to be fired repeatedly by a Claude Code Routine or cron, not looped internally. Each invocation: resolve the source, resume an answered BLOCKED or HUMAN-HOLD item ahead of claiming anything new (resume rules depend on the binding -- see the coordination skill), or claim exactly ONE available item; drive it through the full Go lifecycle with the merge disposition force-coerced to pr (a scheduled runner never touches the base branch unattended); leave a receipt; stop. The schedule provides the loop, not the verb.

/muster:runner
/muster:runner issues:agent:todo

Scheduling. A Claude Code Routine on a timer, or cron invoking the CLI (claude -p "/muster:runner issues:agent:todo"), is the verified-safe standing cadence; match the backlog's arrival rate rather than firing faster, and use the runner's own idle receipts as the widen signal. Claude Code's native /loop binding is documented here too, with its limit: as of v2.1.196 a scheduled or /loop fire does not execute a disable-model-invocation: true command -- it reaches Claude as plain text instead -- and /muster:runner carries that flag by decision, so /loop /muster:runner <source> re-runs nothing after the first fire. For a native self-continuing loop, /goal re-runs on a condition rather than a time interval and is unaffected by that restriction. The safety inventory (pr-only, the 2-failure retry cap, the claim lock) applies to every firing mechanism unchanged.

Runner shares the same coordination skill as Go-backlog, so it composes safely with a running batch clear, other scheduled runners, and humans working the same backlog or issues:<label> -- the claim lock (Binding A's comment-race window, Binding B's claim-then-verify) is what makes concurrent firing safe. On escalation, Runner posts a FAILED receipt and marks the item escalated so the next cycle's claim step skips it; a 2-failure retry cap bounds reclaim loops before an item redirects to blocked rather than being retried forever.

Capture

The third backlog generator, alongside the interview skill's decomposition check and Audit's backlog mode -- so a backlog never has to be hand-written. It turns a session's discussion into backlog items: research findings, design decisions, review residuals, or an explicit user directive like "add those 5". An optional hint scopes which part of the conversation to mine; empty scans the whole session so far.

/muster:capture
/muster:capture the three findings from the audit we just discussed

Each candidate is traced to what was actually said -- a quoted fragment or a named decision, never a musing floated without a decision behind it, work already completed this session, or anything the user explicitly parked ("later", "maybe", "not now"). More than 10 survivors triggers a cap: only the 10 most recent/decision-weighted candidates are presented, with the holdback count stated explicitly.

Every surviving candidate runs the identical assess-passable validation and .muster/backlog.md dedupe the other two backlog generators use, capped at 2 reword attempts -- an item still not measurable after that is offered marked UNMEASURABLE rather than forcing a fabricated metric. Nothing is written until you approve: an AskUserQuestion prompt offers Approve all, Edit (a revised item re-enters validation before re-offering), Drop, or Cancel (writes nothing) -- the human gate on what enters the queue.

Capture has no run-active lifecycle. It only ever writes .muster/backlog.md and never assembles a crew or dispatches a subagent wave itself, so it is not an outcome-runner like the other modes -- a run-active marker would gate nothing here, and is deliberately omitted rather than copied from the other command prompts.

Next: the CLI commands that power these modes.