Skip to content

Skills reference

Every skill steer ships, named as /steer:<skill>. Only the front doors below are typed; the internal skills are reached through a front door or by Claude, and their /steer: name identifies them rather than inviting you to type it. This page is kept in sync with plugins/steer/skills/ by the /plugin-docs skill, and the validate_docs.py gate fails CI if any shipped skill is missing here.

Invocation

Always namespaced: /steer:spec, never bare /spec. There is no commands/ directory - the thin command shims were removed.

Front doors

The handful of skills a user picks from. Each detects context and hands off to the specialized skills below as needed, so you rarely reach past this set.

In a polyrepo member, spine-reading skills resolve the workspace first

A member repo (spec/PRODUCT.md) holds only its own ADRs, design, ARCHITECTURE.md and code - spec/features/**, vision.md, /spec/app/, spec/history/ and spec/tracker.md live once in the workspace. Every skill that reads or writes those (spec, spec-scaffold, intake, questions, work, issues, tracker-sync, next, audit, roadmap, explain, adr, protect) resolves the workspace before acting and says so, rather than reporting an absent local file as empty.

Three skills are deliberately not in that list. /steer:status reports rather than resolves: from a member it names its scope - "this covers one repo of several" - and points at the workspace instead of reading across it. /steer:setup sync reconciles only the member's own surface and never reinstalls the product-level artifacts that are absent there by design. /steer:setup only detects the member's role and routes. Resolving the spine from a member and reporting across members are separate contracts; see the product spine and /steer:reference polyrepo for the full treatment.

The two bootstrap doors carry the same carve-out in the other direction: /steer:setup's init and adopt modes install spec/PRODUCT.md and skip the product-level artifacts entirely - including the interview that would populate them and the tracker-label bootstrap that keys off a local tracker.md. /steer:work tidy is a third flavour: it neither resolves nor creates, reporting a stray product-level file instead of making the directory locally. Writing any of them into a member manufactures the split-brain spine the topology exists to prevent. See Product spine and /steer:reference polyrepo.

Skill Purpose
/steer:setup One front door for getting a repo onto the standards - detects the /spec spine state and routes to its init (greenfield bootstrap), adopt (existing-code adoption) or sync (steady state) mode, flagging missing prerequisites first if the toolchain is incomplete. Naming the mode skips detection; /steer:setup sync --check is the read-only drift report. Two more modes bracket those three: doctor (local prerequisites, which have to hold before any of them can run) and protect (the branch-protection wall each of them ends on) - both reachable without spine detection, as is worktrees (parallel-worktree handling). A thin dispatcher: each mode delegates to the internal skill that owns the work.
/steer:build Guided flow for a non-technical PO: idea -> spec -> working app -> dev handoff (a v0 PR in PR flow, or graduation off the trunk in solo trunk - the skill offers and recommends solo trunk for a greenfield build). See Build.
/steer:spec Spec-only brainstorm for a feature - author/iterate intent.md (+ contract.md), drive open questions, approve. A clarify <id> mode sweeps the draft for gaps (edge cases, error paths, permissions, lifecycle, scope) before approval, converting each into a structured Q-NNN question; validate adds cross-artifact analyze warnings (intent <-> contract <-> tracker consistency, acceptance-criteria quality). Four further modes are the spec-authoring companions it absorbed: questions sweeps the whole spine's open questions (questions bundle [<id>] renders them as one fillable PO questionnaire), distinct from clarify, which interrogates only the draft in hand; adr records a hard-to-reverse choice, with adr accept <n> the ratification gate; intake absorbs a PO office document by diffing it against the last absorbed version (intake clarify <path> folds a client's answers document - again not clarify <id>); and roadmap lays unshipped intent on a release timeline. Runs spec-only on an unmanaged repo (lite mode - no bootstrap required; /steer:setup is the follow-up, not the precondition) - but all four folded modes need the spine and route to /steer:setup without it. See Spec.
/steer:work Execute a GitHub issue end-to-end - validate, claim, branch, implement, test, PR; the start, resume and finish subcommands drive that lifecycle step by step, with a read-only status reporting where it stands. Add --reviewed to wrap execution in independent plan- and code-review gates plus a bounded fix loop (the review-gated path formerly the deliver skill) - vetted, not first-draft. Add --hotfix for a genuine production incident - the fast-path relaxes ceremony and ordering but keeps every human authority gate and requires a mandatory post-incident follow-up (rule 61-gates § Hotfix). Writes Refs owner/repo#N + an explicit close instead of Closes #N when the tracker repo is provably not the code repo, since GitHub closing keywords do not cross repositories. See Work. Adds a promote subcommand for the production promotion: not issue-scoped (what ships is everything already merged), it reads policy/delivery.yml's production_gate and only drives prod-branch-pr - under github-environment, manual or none it reports what is unreleased and stops, because there is no PR to open. It cuts the consumer changelog in its own PR to the default branch (the fragments live there, so a cut that existed only on prod would leave them pending and the two CHANGELOG.mds permanently divergent), then opens the main -> prod PR on a second, idempotent run. Merging that PR deploys production and stays the human gate. A tidy subcommand is not issue-scoped either: it sweeps the loose files at the repo root into their correct home (/spec/reference, /spec/design), moving the confidently-classified strays now and proposing every rename and delete for a yes - rendered by the internal /steer:tidy. An issues <mode> subcommand carries the backlog layer, which never edits code - capture, triage, brainstorm, materialize, decompose, epic, status, board, reconcile, the publish-* family and bootstrap-labels, rendered by the internal /steer:issues. Its status is the spine join (intent status, contract readiness, sub-issue progress, an epic's child rollup), distinct from this skill's own status #N, which reports one claimed issue's execution state. See Issues.
/steer:audit Repeatable read-only audit in two modes: code (standards-conformance health, leverage-ranked - the default) and spec (as-built /spec vs tracker intent, the former drift skill); all runs both. code is whole-repo unless --since <ref> bounds it to what that diff changed plus each changed file's counterparty surfaces - for "did this work introduce anything" rather than "how healthy is this repo", where an unscoped sweep keeps returning an unrelated backlog that never trends down. Under a scope, findings outside it are counted as pre-existing in one line and never ranked; spec mode takes no scope. Hands off to /steer:work tidy. Treats a declared-trunk unprotected main (solo trunk mode) as intentional, not a finding. Its handoff is derived, not chosen: each routing option carries a next-actions category, so a confirmed defect with a written rule to build against is Blocking now and goes to /steer:work, while filing the finding set (/steer:work issues publish-audit) is Recommended and covers the remainder - tracking a blocker is never the recommended action ahead of fixing it. After the run, optionally offers the report as a shareable Claude Artifact (a findings dashboard for code, a verdict-chipped drift board for spec) - derived, temp-only, post-confirmation, per the Artifact standard (/steer:reference artifacts). The code dashboard can render as a fillable triage form whose machine-keyed export (finding-key per finding) /steer:work issues publish-audit ingests - file exactly the checked findings; the drift board stays read-only.
/steer:next "What should I do next?" across the workspace, plus capabilities - the plain-language menu of everything a user picks from (the model-only skills are deliberately absent), rendered by the internal /steer:help and needing no repo state. Read-only itself - Edit is disallowed for the invoking turn and Write is granted only for an Artifact temp path, and the boundary across the run is one the skill keeps; when the single arbitrated action is unambiguous and non-gated it is announced and continued into (rule 00-router, bounded auto-continue) - but that tool removal is turn-scoped, so a continuation into a writing skill reaches its first writing step and hands over there. Reconstructs the local workspace state in one call via the bundled scripts/workspace-snapshot.sh helper (git, spine state + polyrepo role + version drift, features, open questions, ADRs, work claims), then fetches only the live PR/CI and tracker state separately, batched.
/steer:status Render a client-facing progress report - feature <id> renders one feature in depth through the internal /steer:explain, and the window modes render a time-boxed report across the whole /spec spine - what shipped this period, what's in progress, what needs the client's input, and what's next - as a shareable Claude Code Artifact with a Markdown fallback (a weekly-status-report view for a client or PO). A thin orchestrator + presentation layer: reads closed issues and milestone progress through /steer:tracker-sync and open blocking questions and feature status from /spec, then renders them in plain product language. Read-only and derived - /spec and the tracker stay canonical; never fabricates counts, dates, or status, never writes back, and is never auto-generated on a schedule. Period defaults to the last week; since <date> or milestone scope it otherwise.
/steer:standards Load the always-on operating manual on demand - reads every rules/*.md in lexical order (no hand-maintained rule list to drift), for surfaces where the SessionStart hook doesn't fire.

/steer:explain and /steer:status run in a forked subagent

Both carry context: fork, so each runs in its own subagent rather than the main session. They are pure renderers - the whole input is the argument ([feature-id], [this-week | since <date> | milestone [<name>] | feature <id>]) and the whole output is a page - so nothing is lost by cutting them off from the conversation, while the spine and tracker reads behind the page stay out of your session's context. That is the point: you asked for the report, not for the dozen files it was derived from.

Both also set background: false, so the turn waits for the fork instead of continuing while it runs. A backgrounded fork is given the narrower background-subagent tool set, and that set re-admits Bash, Edit, NotebookEdit and EnterWorktree - which covers everything these two declare disallowed (/steer:explain disallows all four; /steer:status disallows the latter three and scope-grants the Bash reads it needs) - so backgrounding would quietly widen what a "read-only" renderer can reach. Waiting does not put the heads-up ahead of an Artifact publish: the heads-up is written inside the fork and only a fork's final result reaches the main session, so the Artifact permission prompt is the gate that holds. The key needs Claude Code v2.1.218+; before that release a forked skill always blocked the invoking turn, which is the behaviour background: false asks for, so an older CLI lands on the intended side.

Note what the frontmatter does and does not buy you: disallowed-tools is documented against the turn that invokes a skill, and upstream does not say whether it reaches a forked subagent. These two skills are read-only because their procedures are, and background: false keeps them off the wider tool set - not because the runtime is guaranteed to enforce the list.

context: fork is set on exactly these two skills; every other skill runs in the session that invoked it. That is deliberate - a skill that reports on this conversation (/steer:report) or drives other skills (/steer:spec roadmap) needs the session it was called from.

standards and reference are a pair, split by who types them

Neither is a front door - rule 00-router surfaces them only in its below-table prose. /steer:standards stays typable because it is the fallback for surfaces where the SessionStart hook doesn't fire: a user on the Desktop chat tab or claude.ai web loads the manual by hand. Reference prose has no such surface - Claude loads a topic because a rule or a skill named it - so /steer:reference is user-invocable: false and sits in the internal table below.

Internal gateways (never user-invoked)

user-invocable: false - never a user's first move. Every one has exactly one declared way in, and check_standards.py fails the build on a skill that has none: absorbed as a mode of one front door (/steer:setup init, /steer:status feature <id>), a gateway an owning skill calls mid-procedure (tracker-sync, spec-scaffold), or rule-reached - the three with no front door (reference, report, loop), named by an always-on rule, or reached from Claude's own read of what the ask needs.

Skill Purpose
/steer:tracker-sync The single gateway for all GitHub tracker reads/writes (MCP-first, gh fallback, manual floor). Its catalogue is split by portability: a core of eight marker-keyed operations (find, get, create, update-state, claim, comment, link-delivery, close/reopen) that the lifecycle runs on, and a GitHub-native companion for what has no equivalent elsewhere - labels, Issue Types, milestones, native issue fields (field-get/field-set/bootstrap-fields for Priority/Effort/dates) and native relationship edges (link-parent, link-related, link-blocked-by), every one of them capability-degrading to the marker it mirrors. Its close operation is the only closure path when the tracker repo is not the code repo - GitHub closing keywords do not cross repositories (see Work).
/steer:reference Load one of the bundled full-detail reference docs by topic: conventions (tooling/convention questions, stack-default rationale), traceability (living docs, tracker refs, drift gates, PO vs dev split, keeping internal ids out of end-user copy), design-sources (features from a Claude Design export/URL, Figma, or screenshots), context-hygiene (delegate heavy/multi-phase runs to subagents; persist durable run-state in /spec/** so it survives compaction), architecture-diagrams (the global system diagram: Tier 1 Mermaid vs opt-in Tier 2 LikeC4, which diagram types, and keeping it in sync), or artifacts (how a skill renders a shareable page as a Claude Artifact - the derived-view discipline, CSP/inline mechanics, the styling contract (DESIGN.md tokens or the house default), the temp-path write invariant, the fillable-page return leg, and the Markdown fallback - this is the standard itself, with no always-on rule condensing it), gates (answering a human authority gate in-session - the three-option prompt, the per-gate minimum it must show, how the decision is recorded, and the merge/deploy/secrets boundary no prompt can cross; backs rule 61-gates), or polyrepo (a product spanning several repos - the workspace/member split, where each spec artifact lives, resolving the spine from a member, honest report scope, and what crosses the repo edge: sub-issues and Projects v2 yes, milestones, closing keywords and drift gates no; deliberately backed by no always-on rule - the topology is delivered by this topic plus the orient-session.sh SessionStart note, so a single-repo product pays zero always-on bytes). Read-only; the prose ships with the plugin and is loaded on demand - never copied into the repo. Reached when a rule or a skill names the topic it needs; a user asks the question in plain language instead.
/steer:report File a bug about the steer plugin itself upstream in element22llc/e22-plugins - gathers the defect (a recorded hook fault, a contradictory skill/rule, or a missing/broken template/script), scrubs it of secrets/paths/product-code, deduplicates by a stable fingerprint, and auto-files it via the GitHub MCP server when one is available, falling back to gh - no confirmation, with the scrub redacting or omitting anything unredactable (paste-URL fallback when offline or unauthenticated). For plugin defects, not product bugs. Reached when Claude hits a steer defect - it auto-files with no confirmation step, which is why the model owns the channel rather than the user.
/steer:loop Scaffold an autonomous loop - a scheduled GitHub Actions workflow that wakes on its own, triages work (CI failures, open issues, drift) via /steer:audit + /steer:next, drafts fixes in isolated worktrees reviewed by steer-reviewer, pushes its own work branches, and opens draft PRs (the draft flag marks unattended output - the merge review is the gate). Wired to stop at every human gate (rule 53-autonomous-loops): it delivers up to the PR, it never merges/deploys/pushes-to-main, and it presupposes pr-flow (a protected main - graduate a solo-trunk repo first). Instantiates the on-demand templates/github/workflows/steer-loop.yml and lands it via the normal autonomous branch-push + PR. verify/remove modes inspect or tear down an existing loop. The automation opt-in is a decision the dev makes, not a file this skill writes for them, and it is scaffold's first step, ahead of instantiating the workflow: where policy/automation.yml does not already declare loops: true, the trade goes to the dev first (unattended API spend per run, draft-PR noise, the PR flow a loop requires) and the marker is written only on confirmation, with who decided recorded; the /spec/history/ entry follows at delivery, since arming an unattended agent is a repo-level event. Reached when a dev asks for a scheduled sweep in plain language, or from rule 53-autonomous-loops, which a repo carries only once that marker exists. The marker gates that always-on boundary prose, not the skill: an ask still routes here on a repo that never opted in, and step 1 is what stops the run.
/steer:explain Render one feature spec as a stakeholder-readable, shareable Claude Code Artifact - a private, hosted page on claude.ai built around at-a-glance visuals (status pipeline, acceptance meter, clickable user-journey, scope and open-question boards) - with a Markdown fallback. Read-only and derived: the /spec intent and tracker item stay canonical, and it writes nothing back. Reached only through /steer:status feature <id>.
/steer:help Render the capability menu - the shipped skill set in plain language, essentials first and the rest grouped by journey, every line built from the live skill frontmatter, with an optional Artifact card grid. Reached only through /steer:next capabilities; a user who wants the menu asks next for it.
/steer:issues The GitHub Issues lifecycle for the spine - capture, triage, brainstorm, materialize, decompose, epic (group features under a parent tracking issue as an Epic -> Feature -> Task hierarchy), status, a read-only ranked relationship-aware board, and reconcile - sequencing into a release timeline is handed off to /steer:spec roadmap - plus publish-* modes that file /steer:audit, drift, adoption, and /code-review//security-review findings as issues (publish-audit also accepts the audit dashboard's filled triage export, filing exactly the checked findings), and bootstrap-labels to set up the label taxonomy. Triage escalate-only auto-sets the native Priority field. In a polyrepo member the tracker and every feature's specs are read from the workspace (a member carries neither), and decomposition accounts for what crosses the repo edge: sub-issues do, closing keywords do not. Reached only through /steer:work issues; a user who wants the backlog asks work for it. See Issues.
/steer:tidy Sweep loose files out of the repo root into their correct home (/spec/reference, /spec/design). A confidently-classified stray is moved immediately; renames and deletes are proposed and wait for a yes. Exactly two things are deletion candidates (HOUSEKEEPING.md): true OS junk (.DS_Store, desktop.ini, Thumbs.db), which also gets a .gitignore pattern so it can't return, and an already-absorbed source - a spec/requirements doc whose bytes match a committed spec/sources/**/original.*, where the stray is a redundant duplicate of content /steer:spec intake already preserved, so deleting beats moving it into /spec/reference as a second copy. The .gitignore step is junk-only; an absorbed doc isn't junk and a later version of it is expected. Reached only through /steer:work tidy; a user who wants the sweep asks work for it.
/steer:init One-time setup for a new repo - bootstrap the /spec spine + scaffold, or resolve legacy template placeholders. The legacy-fork path walks the migration ledger before stamping spec/.version: stamping first would make /steer:sync skip every entry at or below that version, retiring those transforms on exactly the repos furthest behind. Offers solo trunk mode when one person is both PO and dev with no MVP yet (commit directly to main, no feat/*/PR ceremony, declared in the product CLAUDE.md ## Delivery mode). Reached only through /steer:setup init.
/steer:adopt Reverse-engineer a /spec spine from an existing app's code and add the scaffold, plus a root DESIGN.md from the app's real visual identity and a spec/PRODUCTIONIZATION.md triage (Keep / Refactor / Rewrite / Reject per area). See Adopt. Reached only through /steer:setup adopt.
/steer:sync Bring a managed repo up to date with the current plugin - apply migrations, reconcile spine + scaffold, repair missing/mis-wired capability-critical scaffold (18 capabilities in all - e.g. plugin enablement, in-CI loading, version-pin enforcement, drift gate, branch-protection, delivery-mode declaration, agent-surface currency, line-ending normalization, changelog fragments; the full set with its repair contract is in the plugin's templates/reference/CAPABILITIES.md), auto-detect & repair stale/invalid /steer: skill invocations in the repo's live instruction surfaces (CLAUDE.md, README, PR template), re-stamp /spec/.version, land a PR. --check runs a read-only capability + drift report. An OpenSpec repo (spine state openspec) is a sync case too - there it reconciles steer's surface only (the scaffold plus the three artifacts under openspec/steer/), never touches spec/**, writes no spec/.version stamp, and records the run in the PR description rather than spec/history/. Reached only through /steer:setup sync (/steer:setup sync --check for the read-only report).
/steer:doctor Detect the local prerequisites a repo needs before init/build/dev - git, mise (and the pnpm/uv/node it manages), and Docker - with per-OS guidance. It installs mise and the runtimes it manages on your confirmation; git and Docker Desktop are handed over as instructions to run yourself (a sudo command and a GUI app - neither is scriptable). Also flags a runtime shadowed by a global version manager (nvm/asdf/volta/fnm) or a system copy, so bare pnpm/node can't silently run an un-pinned version. Before any of that it runs a plugin-integrity check - a CRLF-corrupted install (see Windows setup) stops every bundled script from parsing, so it is reported as an install fault rather than a missing prerequisite. Reached through /steer:setup doctor; the init mode and /steer:build also route there when prerequisites are absent.
/steer:protect Verify (and, on confirmation, apply) GitHub branch protection against policy/branch-protection.yml - the real PR gate - on the default branch plus any additional branches the policy declares (e.g. a prod promotion branch, whose required PR review is the production approval gate), plus the repo-level security settings it declares (secret scanning + push protection, Dependabot alerts + security updates). steer is advisory locally; this configures the server-side wall. Verify-only by default - verify writes nothing, reporting a stale delivery-mode marker and naming apply as the fix. Also the graduation gate out of solo trunk mode: running apply raises the PR wall and ends the mode. A graduating apply is the one path that also writes locally - the CLAUDE.md ## Delivery mode marker and a /spec/history/ entry, and nothing else (in a polyrepo member the marker is local, the history entry the workspace's). Treats a declared-trunk unprotected main as intentional, not drift. apply --solo / apply --team selects the policy profile (schema 3) in the repo's own policy copy before applying: solo keeps the PR, the ci check, linear history and admin enforcement but drops the approval count to 0 on every protected branch, because a PR's author cannot approve it and a one-person repo would otherwise be unable to merge - offered when a graduating solo-trunk repo has exactly one collaborator, and flagged as drift to tighten once a second one joins. waive is the other answer to the graduation signals: for a repo that deliberately stays single-dev on trunk (its infra/ tree or deploy target is part of the plan), it records a graduation waiver - <!-- steer:graduation=waived --> under the delivery-mode marker plus a /spec/history/ entry - and the SessionStart graduation nudge and the trunk-push ask fall silent together. A decision, not a third mode: the repo stays solo-trunk, a second collaborator voids it (verify and /steer:audit report that), and apply removes it at a real graduation. In a polyrepo it names the sibling repos still unprotected, so a one-repo verdict never reads as product-wide, and says plainly that org-level rulesets need GitHub Team or Enterprise. Its only GitHub dependency is the remote: it does not read /spec/tracker.md, so a repo with GitHub-hosted code and a Jira, Linear, or not-yet-declared tracker gets the wall exactly like any other. Reached through /steer:setup protect (verify / apply [--solo | --team] / waive); the init and adopt modes end by offering it.
/steer:worktrees Check a repo's parallel worktrees, whichever tool made them - Claude Code, Orca, Conductor or plain git worktree. A read-only scan (scripts/scan-worktrees.sh) reports whether each worktree inherited the primary checkout's mise trust, whether worktree-env.sh gives it its own Compose project and ports, which git-ignored boot files (.env*, .mise.local.toml, .claude/settings.local.json) .worktreeinclude misses or a worktree lacks, and whether an in-repo worktree dir is git-ignored. Only Claude Code raises WorktreeRemove, so for any other tool it checks the tool's own teardown: for Orca it installs an orca.yaml scripts.archive hook that runs docker:clean, fail-soft because a failing archive hook blocks Orca's removal; for Conductor or plain git it names the manual step. It also lists orphaned Compose stacks - this repo's worktree projects whose directory is gone - and removes them, volumes included, only on an explicit yes. It never creates first-time trust, and every edit waits for confirmation. Reached through /steer:setup worktrees.
/steer:questions Sweep every open question across the spine (each feature's intent.md, vision.md, and PRODUCTIONIZATION.md when present) and walk the PO/dev through answering each one, folding the decision back into the spec - promoting a question to a tracked issue is one sub-step. An answer may also arrive from an ingested clarification document (routed here by /steer:spec intake clarify); it folds under the same tier gate as an in-session answer, recording the source-ref and quoted span as provenance. A bundle [<feature-id>] mode renders the PO-answerable open questions across the whole spine (all features at once) as a shareable, fillable Claude Code Artifact - with a Markdown fallback - for a Product Owner with no repo access to answer in a browser; each answer is anchored by a feature-scoped [<feature-id>] Q-NNN heading so the returned document maps back deterministically through /steer:spec intake clarify (the feature scope disambiguates the per-feature Q-NNN ids). Bundle mode is read-only (writes nothing to the spec). Reached through /steer:spec questions (questions bundle [<id>] for the questionnaire); /steer:work issues and /steer:spec intake also route there, which is why the spine requirement is enforced in this skill rather than at the door: with no spec/.version it stops and routes to /steer:setup, because a sweep of a spine that does not exist reports a clean bill of health.
/steer:adr Record a hard-to-reverse or cross-cutting decision as an ADR, then offer its Deciders in-session ratification - an Approve · Reject · Decide later prompt carrying the decision, the rejected alternatives, and the negative consequences (rule 61-gates). accept <n> is the single writer of Proposed -> Accepted: it stamps the ratifier, date, and channel (in-session vs offline-review) and writes one /spec/history/ entry. Never runs on Claude's own initiative. Requires a stamped spine: a direct call on a repo with no spec/.version stops and routes to /steer:setup, while a bootstrap (/steer:setup, /steer:build) calling in mid-run proceeds. See Decisions. Reached through /steer:spec adr; adr accept <n> is the ratification gate rule 61-gates names.
/steer:intake Absorb a PO-supplied spec/roadmap document (docx/pptx/xlsx/pdf) into the spine - version-stamp and commit the binary plus a normalized Markdown extraction under spec/sources/<id>/, git diff it against the prior version, and route the real changes into /spec and the tracker via the usual gateways (never clobbering prose; conflicts become Open questions). A clarify <doc> mode absorbs a client clarification document through the same front-end, then segments it and maps each unit inline against open questions and the feature list, sorting them into a human-confirmed three-bucket worklist (answers -> /steer:spec questions; new scope -> reconcile rows; low-confidence -> surfaced, never guessed). A read-only status mode prints the source ledger - every spec/sources/<id>/source.md with its latest absorbed version, the features/issues it maps to, and any version whose extraction is still awaiting a text-bearing copy. Idempotent re-runs. See Intake. Reached through /steer:spec intake; intake clarify <path> absorbs a client's answers document, which is a different job from /steer:spec clarify <id> (interrogating the draft in hand). Requires a spine.
/steer:roadmap Generate a release-milestone timeline (viewable as a GitHub Projects v2 roadmap) by turning intended-but-unshipped work into milestone-grouped issues - a no-argument run is a read-only preview (the only read-only mode), then from-features (target specs not yet live) or from-gap (a spec-gap from /steer:audit spec), plus a roadmap sync reconcile. Writes the human-confirmed native Start/Target date issue fields (for per-issue Gantt bars) in addition to milestone grouping; proposes a dependency-ordered plan; never fabricates dates. Can offer the milestone plan as a shareable Claude Artifact timeline - a derived preview of the Projects v2 view, per the Artifact standard (/steer:reference artifacts). In a polyrepo the release axis moves off Milestones (which cannot span repositories) onto a Project iteration/single-select field - recorded as the one named exception to its native-attributes-only guardrail. Reached through /steer:spec roadmap - a roadmap is a projection of the spine's unshipped intent, not of backlog state. GitHub-only: it says so and stops when /spec/tracker.md declares another tracker.
/steer:spec-scaffold Create a feature's spec (intent.md + contract.md) from the bundled templates, or additively reconcile an existing one without overwriting filled-in content (spine materialization is /steer:setup's job).