Skip to content

Workflows overview

A workflow is a multi-step skill that drives a phase of the product lifecycle. This section documents the ones a developer or PO drives directly, including modes reached through a front door. For the full per-command catalog (including internal helpers), see the Skills reference.

You don't have to remember these commands

The always-on router rule makes Claude the dispatcher: describe what you want in plain language ("I have an app idea", "fix #123", "what should I do next?") and Claude routes to the matching skill itself, announcing the choice in one line. You can always see which one ran: the Recommended next actions heading that closes a workflow names it (## Recommended next actions - /steer:audit code), so a wrong route is easy to spot and say so about. The /steer:* forms below are the explicit way to invoke a workflow - handy when you already know the one you want - not something you must memorize. Decision gates (creating issues, approving a spec, merging, deploying) still pause for a human regardless of how the skill was reached - pushing the branch and opening the PR are autonomous.

Announcing the route and running it are the same step: a reply that names the skill and then answers by hand is a misroute, not a route. Two things follow. A restricted session still routes the same way - plan mode, a read-only or reduced-permission session, or a client with fewer tools never changes which skill owns the request; every workflow has a read-only front (survey, diagnose, interview, plan), so Claude enters it and the skill reports what it could not carry out. And the follow-up questions come from inside the workflow - "which feature?", "which issue?" are asked after it starts, so at most one question precedes a route, and only when two skills are genuinely candidates.

That closing block is derived from what the run actually found, not a fixed sign-off. A workflow that swept its domain and found nothing to do - no open question, no failing prerequisite, no unfinished transition - closes with No action is currently required., at most naming an optional continuation. What it never does is prescribe work over state the run did not touch, so a recommendation you are handed means something genuinely unfinished was observed.

flowchart LR
    subgraph Setup
      setup["/steer:setup<br/>detect & route"]
      init["init mode<br/>new repo"]
      adopt["adopt mode<br/>existing app"]
      setup --> init & adopt
    end
    subgraph Build loop
      issues["/steer:work issues"]
      spec["/steer:spec"]
      work["/steer:work"]
    end
    subgraph Steady state
      sync["/steer:setup sync"]
      drift["/steer:audit spec"]
      audit["/steer:audit"]
    end
    Setup --> issues --> spec --> work --> drift
    work --> sync

I want to ... -> run ...

A one-screen cheat sheet, keyed by intent rather than phase. You don't have to memorize it - describe the goal in plain language and Claude routes for you - but when you'd rather invoke the skill yourself, this is the index. The phase tables below give the detail.

I want to ... Run
Get set up - I'm not sure what state the repo is in /steer:setup (detects & routes)
Start a brand-new repo from scratch /steer:setup init
Bring an existing app under steer /steer:setup adopt
Absorb a product owner's spec / roadmap document /steer:spec intake
Capture, triage, or decompose ideas into issues /steer:work issues
Shape or approve a feature spec /steer:spec
Start, resume, or finish an issue /steer:work
Implement with a review-gated loop (vetted, not first-draft) /steer:work --reviewed
Build or prototype an app as a non-developer /steer:build
Find out what to do next /steer:next
Browse everything steer can do - not sure what to ask for /steer:next capabilities
Show or share a visual, plain-language page of one feature /steer:status feature <id>
Give a client a progress/status report ("what did we ship this week?") /steer:status
Check standards conformance, or that the /spec spine matches its tracker specs /steer:audit code · /steer:audit spec
Apply a new plugin release (migrations, scaffold, spine) /steer:setup sync
Generate a release-milestone timeline /steer:spec roadmap
Run the maintain-phase sweep on a schedule (triage -> draft fix -> PR) Ask for an autonomous loop - Claude scaffolds it (/steer:loop): a workflow that discovers, triages, drafts a fix reviewed by steer-reviewer, and opens a draft PR, never merging or deploying (rule 53). It starts by asking you to declare the automation opt-in
Lock branch protection or flip the delivery mode /steer:setup protect
A tool is missing, or set up the local toolchain /steer:setup doctor
Every steer command fails at once (syntax error near unexpected token) - a CRLF-corrupted install, not a plugin bug /steer:setup doctor (§0 diagnoses it locally)
Run parallel worktrees from Orca, Conductor or git worktree, or clean up stacks deleted worktrees left running /steer:setup worktrees
steer itself is misbehaving Say so - Claude files the plugin bug upstream (/steer:report)
Answer accumulated open questions /steer:spec questions
Record a hard-to-reverse or cross-cutting decision /steer:spec adr
Sweep loose files at the repo root into /spec /steer:work tidy
Ship an emergency fix to a production incident /steer:work --hotfix
Load the rules manually (Desktop Chat tab / web chat, where the hook can't fire) /steer:standards

Setup (one-time)

Skill Use when
/steer:setup The front door - detects the repo state and routes to one of its modes below. Start here.
/steer:setup init A new repo with no /spec spine - installs the bundled scaffold + spine. Naming the mode skips detection.
/steer:setup adopt An existing app with working code but no spine.
/steer:setup doctor The local toolchain is missing or a runtime is shadowed - this runs before any of the others can.
/steer:setup protect Raise the branch-protection wall, or graduate off solo trunk - the step each bootstrap path ends on.
/steer:setup worktrees Worktrees made by another tool (Orca, Conductor, git) need that tool's teardown hook - this checks and installs it, and sweeps orphaned stacks.

Build loop

Skill Use when
/steer:work issues Drive an idea from capture -> draft spec -> decomposed work, without editing code.
/steer:spec Think a feature through and shape/approve acceptance criteria. questions sweeps the spine's open questions, adr records a hard-to-reverse decision, intake absorbs a PO document, roadmap lays unshipped intent on a timeline.
/steer:work Start, resume, or finish a specific issue. Add --reviewed to run it through a review-gated loop (plan -> plan-gate review -> implement -> /code-review -> bounded fix) - vetted, not first-draft.
/steer:build A non-developer wants to build or prototype an idea.

Steady state

Skill Use when
/steer:setup sync After a plugin release - apply migrations, reconcile spine + scaffold. Which migrations exist, and what each one rewrites, is in Versioning the contract.
/steer:audit Periodic read-only pass: code for whole-repo standards-conformance health, spec to diff the as-built /spec spine against its tracker specs, all for both.
/steer:next "What should I do next?" across the whole workspace. Read-only itself: it reconstructs, arbitrates, and names the one action that matters most. When that action is unambiguous and non-gated it is then announced and continued into (rule 00-router's bounded auto-continue), handing over at the first step that writes; a close call, a gated step, or an action no command performs waits for you.
/steer:spec roadmap A /steer:spec mode. Generate a release-milestone timeline from the /spec spine (viewable as a GitHub Projects v2 roadmap).