Commands

Guild Stack v3 gives you 13 commands, all starting with /guild:. You only need three to start:

Command	What it does
`/guild:init`	Learns your project and sets up the `.guild/` folder.
`/guild:guild`	The front door. Tell it what you want; it suggests where to start.
`/guild:status`	Shows where your current task is and what comes next.

A command's route: a typed /guild: verb invokes one assembler skill, the skill calls deterministic scripts, and every output lands under the project's .guild/ folder. — Open full size

The Power layer is the full reference. The Architect layer shows what a command actually runs.

Command reference

Guild Stack v3 has 13 commands. Each one is /guild:<verb>. A sub-verb is a positional argument to its command, never a file of its own. On stable 3.0.0, eleven more command files are print-only aliases: they print the new spelling and exit. The upcoming beta (next) releases remove those files entirely (the mapping table shows every old spelling's new home).

The 13 commands

Command	Arguments	Dispatches to
`/guild:guild`	`[brief] [research\|debug]` + 5 flags `[brief] [research\|debug] [--class=product\|research\|debug\|ops\|init] [--rigor=quick\|standard\|deep] [--auto-approve[=spec,plan,build,qa,all]] [--review=local\|cross\|off] [--initiative=<id>\|new]`	`guild:using-guild`
`/guild:init`	`[--learn] [--new]` + `adopt` sub-verbs `[--learn] [--new] \| adopt <report\|catalog\|adopt\|rollback\|status\|window\|g5>`	`guild:init`
`/guild:ideate`	`[brief] [--skip]`	`guild:brainstorm`
`/guild:plan`	`[--team-size=N]` + `goal` sub-verbs `[--team-size=N] \| goal [new\|list\|show\|from-spec] [slug]`	`guild:plan`
`/guild:build`	`[lane-id]`	`guild:execute-plan`
`/guild:qa`	`[run-id]`	`guild:quality`
`/guild:ops`	`[runbook]`	`guild:operations`
`/guild:learn`	`[mode] [target]` + 6 modes `[map\|graph\|knowledge\|onboard\|diff\|explain] [target] [--rigor=…]`	`guild:learn`
`/guild:wiki`	`ingest \| query \| lint` `ingest <path> \| query "<text>" [filters] \| lint`	`guild:wiki`
`/guild:initiative`	8 sub-verbs + `[id]` `new\|status\|list\|resume\|update\|archive\|restore\|close [id]`	`guild:initiative`
`/guild:status`	`[--no-index]` + 3 sub-verbs `[--no-index] \| resume [--restart] \| stats [--rebuild-index] \| dashboard [--port N] [--stop]`	`guild:using-guild`
`/guild:config`	9 sub-verbs + `models`, `migrate` `<init\|set\|role\|show\|validate\|providers\|ui\|update-mcp-hashes\|reconcile> \| models inspect \| migrate`	`guild:using-guild` + config CLIs
`/guild:maintain`	6 sub-verbs `evolve <id> \| rollback <skill> [n] \| audit \| fix [run-id\|symptom] \| gc \| wiki revert`	`guild:evolve`

Entry and phases

/guild:guild [brief] is the bare entry. With no verb it runs intake: it classifies the request and proposes a phase and a workflow class for you to confirm. It never picks silently. research, debug, and --class= bind the class directly.

The six phase commands run one lifecycle phase each. See Lifecycle in depth for what each phase writes.

/guild:init onboards a repo. It is cheap by default; --learn adds the full learn pipeline. adopt localizes shipped capability into this project: report, status, and an unfrozen catalog are read-only; the rest ask first.
/guild:ideate turns a brief into an approved .guild/spec/<slug>.md. --skip validates a spec you already have and flags its gaps.
/guild:plan composes the team, then writes the lane plan and the PRD. goal emits goals from the approved spec.
/guild:build dispatches the plan's lanes. [lane-id] re-runs one lane.
/guild:qa is the review gate. It runs only after a passing .guild/runs/<run-id>/verify.md. It is opt-in and never auto-entered.
/guild:ops runs one of five runbooks: release, monitoring, incident, rollback, maintenance. Each has a mandatory pre-flight dry-run.

The team decision gate

Every phase command ends at a blocking team gate. The verbs are approve, restructure, add, remove, substitute, and edit_dependencies. A non-zero exit stops the run. --auto-approve never covers team approval.

Knowledge, durable work, and state

/guild:learn with no sub-verb runs the full learn pipeline. The sub-verbs scope it. See Knowledge system.
/guild:wiki ingests, queries, or lints .guild/wiki/. Ingest is human-gated: a source becomes a candidate first.
/guild:initiative manages durable multi-run work. A one-off run never creates one. See Initiatives.
/guild:status is read-only in its bare form. See Status, stats, and the dashboard.
/guild:config edits policy config. See Configuration.
/guild:maintain is self-maintenance. Every sub-verb goes to guild:evolve.

An unknown sub-verb on learn, wiki, initiative, or maintain prints usage and runs nothing.

Print-only aliases

On stable 3.0.0 these 11 v2 command names still exist as files. Each one prints its new spelling and exits; none of them dispatches work. That scheduled deletion is done and lands with the upcoming beta (next) releases: the 11 files are removed there, and typing an old spelling becomes an unknown command. Move your scripts and habits to the v3 spellings now.

v2 command	v3 spelling
`/guild:adopt`	`/guild:init adopt`
`/guild:audit`	`/guild:maintain audit`
`/guild:dashboard`	`/guild:status dashboard`
`/guild:evolve`	`/guild:maintain evolve`
`/guild:fix`	`/guild:maintain fix`
`/guild:goal`	`/guild:plan goal`
`/guild:migrate`	`/guild:config migrate`
`/guild:models`	`/guild:config models`
`/guild:resume`	`/guild:status resume`
`/guild:rollback`	`/guild:maintain rollback`
`/guild:stats`	`/guild:status stats`

Moving from v2? Read Migrate from v2 to v3.

What a command runs

A command file is a thin entrypoint. It parses its arguments and invokes exactly one assembler skill; the skill loads only the chapter the request needs, then calls deterministic scripts for anything that must be exact (scoring, validation, run lifecycle). Models make judgments; scripts enforce rules.

Command	Skills invoked, in order
`/guild:init`	`guild:init`
`/guild:ideate`	`guild:brainstorm`
`/guild:plan`	`guild:team-compose`, then `guild:plan`
`/guild:build`	`guild:execute-plan` (per lane: context assembly, dispatch, then `guild:review`)
`/guild:qa`	`guild:quality`
`/guild:ops`	`guild:operations`
`/guild:learn`	`guild:learn`

The full layer model, including hooks and the MCP servers, is on Core concepts. The skill surface itself is on Skills.