Quickstart

Muster turns an outcome into finished work. You give it a goal in plain language; it picks the right tools for each piece and drives toward your success criteria, showing its reasoning the whole way.

Choose a mode by task

Muster has ten modes, including Design for human-facing work and Init for native repository instruction setup. Start with the result you need:

Shape one outcome before work startsUse Plan to inspect the crew and approve the plan.

Deliver one outcome end to endUse Go for the hands-off lifecycle.

Plan a batch without executing itUse Plan-backlog.

Clear a batch of workUse Go-backlog, including dependency waves.

Reproduce and fix one failureUse Diagnose.

Find and fix broad codebase risksUse Audit.

Create or improve a human-facing surfaceUse Design.

Run one scheduled backlog cycleUse Runner.

Turn decisions into backlog itemsUse Capture.

Prepare a repository for MusterUse Init.

If you have not installed Muster yet, choose your harness first.

On Codex?

Every mode below is available on Codex as a skill ($muster-plan, $muster-go, and so on) once Muster's managed profiles and plugin are installed. See the Codex guide for that install path. If something does not appear or behaves oddly, start at Troubleshooting.

Plan and review: /muster:plan

The approve-first router. It detects whether the invocation is one outcome or a backlog, confirming via AskUserQuestion (stating the signals verbatim) whenever it isn't a clear single item, announces the artifact it's about to produce, then -- for a single outcome -- assembles the crew and shows the glass-box manifest plus a plan, and stops for your approval. It plans and shows; selecting Approve & run chains into /muster:go in-session, while Adjust and Cancel stay plan-only.

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

If the outcome is thin, Muster runs a deterministic gap-check (muster assess) and, if needed, an interview that asks one question at a time behind an approval gate before any crew is assembled.

Plan also takes a backlog ref (/muster:plan .muster/backlog.md, issues:<label>, or linear:<key>) and, once scope confirms, delegates to /muster:plan-backlog to plan the whole batch first: every item is routed up front into one batch plan -- per-item crews, run order, cross-item conflict flags -- and Approve & clear chains into the go-backlog clear; nothing executes before that approval.

/muster:run still works: a one-line heads-up, then identical behavior under the new name. Deprecated as of 2026-07-17, retiring in muster 0.7.0.

Hands-off delivery: /muster:go

The full lifecycle, hands-off. It shares Plan's scope detection and confirm, 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 decision, or an escalation.

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

You can also hand it a GitHub issue reference as the outcome:

/muster:go #42

/muster:autopilot still works: a one-line heads-up, then identical behavior under the new name. Deprecated as of 2026-07-17, retiring in muster 0.7.0.

Fix a bug: /muster:diagnose

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

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

Sweep the codebase: /muster:audit

Breadth-first review and fix. It fans out six read-only dimension reviews in parallel (architecture, tech-debt, coverage, simplification, readability, security), consolidates a ranked ledger, then fixes everything with tests and verifies.

/muster:audit
/muster:audit src/payments

Prefix with backlog to sweep read-only instead of fixing: /muster:audit backlog writes the ranked ledger to .muster/backlog.md, one item per finding-cluster, ready for /muster:go-backlog to clear later.

Design a human-facing surface: /muster:design

Initialize or inspect canonical DESIGN.md context, then run one of 23 design workflows. Human-facing implementation carries a scope-bound digest receipt; ordinary backend work never pays the design scan or provider cost.

/muster:design init
/muster:design polish src/App.tsx

Plan a whole backlog: /muster:plan-backlog

The approve-first batch planner -- reached directly, or through /muster:plan's confirmed-backlog delegation. It routes every item in a backlog up front into one batch plan (per-item crews, run order, cross-item conflict flags) and stops for approval before anything runs.

/muster:plan-backlog
/muster:plan-backlog issues:bug

Given a raw intent instead of an existing backlog ref, it first decomposes the intent into backlog items behind a capture-style approval gate, then plans the freshly written backlog. Approve & clear chains into /muster:go-backlog.

Clear a backlog: /muster:go-backlog

The batch counterpart to Go. Plain backlogs run sequentially; annotated file backlogs run dependency waves. An escalated item never aborts the batch -- it stays unchecked and go-backlog moves on. There is exactly one attended stop, at the end, for the batch report -- headlined "cleared N, escalated M."

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

A backlog item annotated with {id}/{deps} (the shape /muster:audit backlog and an accepted interview decomposition both emit by default) switches go-backlog into wave mode. Every ready item builds and reviews in its own worktree, concurrently up to MUSTER_SPRINT_PARALLEL (default 5, hard ceiling 10) when the harness supports it. After every completion wake, Muster reconciles all available receipts and dispatches every newly eligible action before waiting again. Disposition/integration remains backlog-ordered after the entire wave's build/review barrier; the next dependency wave waits for that lane. There is no fixed three-runner cap. Go-backlog re-resolves the file after the barrier and ordered lane so items added mid-batch can join the run instead of waiting for the next invocation.

/muster:sprint still works: a one-line heads-up, then identical behavior under the new name. Deprecated as of 2026-07-17, retiring in muster 0.7.0.

Schedule one cycle at a time: /muster:runner

The unattended counterpart to Go-backlog, meant to be fired repeatedly by a Claude Code Routine or cron rather than run once over a whole backlog: each cycle resumes an answered blocked item or claims exactly one available item, drives it through the full Go lifecycle force-coerced to a pr disposition, leaves a receipt, and stops.

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

Runner and Go-backlog share a claim/receipt/ledger discipline (the coordination skill), so a scheduled runner can safely work the same backlog or issues:<label> alongside an attended go-backlog clear or a human.

Turn a discussion into backlog items: /muster:capture

Had a conversation that produced findings, decisions, or an explicit "add those 5" -- but nothing has written them down yet? /muster:capture [hint] mines the session (or just the part hint scopes) for candidate backlog items, each traced back to what was actually said. Nothing is written until you approve the list; it never assembles a crew or runs anything itself.

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

Approve, and the items land in .muster/backlog.md alongside anything /muster:audit backlog or an interview decomposition already wrote there, ready for /muster:go-backlog to clear.

Initialize a repository: /muster:init

Init learns bounded repository facts, writes .muster/project-profile.json plus .muster/init-receipt.json, and hands native instruction generation to the active harness. It never runs repository scripts, hooks, installers, or discovered commands.

/muster:init
/muster:init path/to/repo

Claude Code and Codex use one canonical instruction pair: AGENTS.md is authoritative, and CLAUDE.md contains exactly:

# Claude Code

@AGENTS.md

If conflicting instruction files existed at the preparation baseline, Init leaves a HUMAN-HOLD instead of overwriting or merging them. Kimi has no proven callable native Init action, so Muster records an unavailable handoff and waits for an explicit acknowledgement instead of inventing a command. See The ten modes for the evidence and finalization states.

Inspect the routing yourself

Because the CLI is deterministic and makes no model calls, you can run it in a terminal to see exactly how Muster would resolve work:

# What did Muster detect about this project?
npx -y @adnova-group/muster detect

# Which provider wins each role, on which model, and what would beat it?
npx -y @adnova-group/muster capabilities

# Which specialist matches a free-text task?
npx -y @adnova-group/muster match "audit this code for security vulnerabilities"

# Which pipeline routes for an outcome?
npx -y @adnova-group/muster route "draft a PRD for a referral program"

Next: read Concepts to understand the router that powers all of this.