Skip to content

Skills reference

Every skill steer ships, invoked as /steer:<skill>. 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: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:init and /steer:adopt 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: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 greenfield bootstrap, existing-code adoption, or steady-state sync, flagging missing prerequisites first if the toolchain is incomplete. Thin dispatcher over /steer:init, /steer:adopt, /steer:sync. It does not run /steer:doctor itself — /steer:init and /steer:build invoke it when prerequisites are absent, and setup surfaces that.
/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). Runs spec-only on an unmanaged repo (lite mode — no bootstrap required; /steer:setup is the follow-up, not the precondition). See Spec.
/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: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.
/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 62-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.
/steer:issues High-level 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: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. See Issues.
/steer:audit Repeatable read-only audit in two modes: code (whole-repo standards-conformance health, leverage-ranked — the default) and spec (as-built /spec vs tracker intent, the former drift skill); all runs both. Hands off to /steer:tidy. Treats a declared-trunk unprotected main (solo trunk mode) as intentional, not a finding. 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 rule 88-artifacts. The code dashboard can render as a fillable triage form whose machine-keyed export (finding-key per finding) /steer:issues publish-audit ingests — file exactly the checked findings; the drift board stays read-only.
/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.
/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-gate-prompts). 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. See Decisions.
/steer:next "What should I do next?" across the workspace. Read-only itself — Edit/Write are disallowed, so nothing it does mutates the repo; when the single arbitrated action is unambiguous and non-gated it is announced and continued into as a fresh invocation of the owning skill, which then runs under that skill's own tier and autonomy rules (rule 00-router, bounded auto-continue). 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:explain Render a high-level, stakeholder-readable view of one feature spec as a 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) so it reads in seconds — with a Markdown fallback where Artifacts are unavailable. A read-only, derived view: every visual encodes a real spec value, the /spec intent and tracker item stay canonical, on demand only, never auto-generated, and it writes nothing back into the spine.
/steer:status Render a client-facing, time-boxed progress 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:help Human-facing capabilities menu — renders the router's intent→skill table in plain language, tiered (the six essentials first — setup, spec, build, work, next, status — then the rest folded under journey groups), so a new user sees a handful of lines rather than the full inventory. Read-only; sources the live router table so it can't drift. Optional argument zooms into one skill or area. Can additionally offer the menu as a shareable Claude Artifact card grid (rule 88-artifacts); the inline menu is the fallback.
/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. 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.
/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: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.

standards and reference are a pair

Neither appears in the router's Intent → skill table — they are the two user-invocable skills rule 00-router surfaces only in its below-table prose, which is why /steer:help presents them together. They are split across the two tables here by how you reach them: /steer:standards is invoked directly on surfaces where the SessionStart hook doesn't fire, while /steer:reference is usually routed to (by /steer:standards or the model) for one full-detail topic.

Reached through a front door

Directly invocable, but a front door auto-routes to each, so you rarely call one by name. Each is reached through the front door noted.

Skill Reached via Purpose
/steer:init /steer:setup One-time setup for a new repo — bootstrap the /spec spine + scaffold, or resolve legacy template placeholders. 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).
/steer:adopt /steer:setup 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.
/steer:sync /steer:setup Bring a managed repo up to date with the current plugin — apply migrations, reconcile spine + scaffold, repair missing/mis-wired capability-critical scaffold (16 capabilities in all — e.g. plugin enablement, in-CI loading, version-pin enforcement, drift gate, branch-protection, delivery-mode declaration, Copilot-surface currency, line-ending normalization; 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.
/steer:doctor /steer:init, /steer:build 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.
/steer:tidy /steer:audit 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 (rule 22-housekeeping): 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: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.
/steer:roadmap /steer:issues 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 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 rule 88-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.
/steer:questions /steer:spec, /steer:issues 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: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:intake clarify (the feature scope disambiguates the per-feature Q-NNN ids). Bundle mode is read-only (writes nothing to the spec).
/steer:reference /steer:standards, model 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; backs rule 88-artifacts), 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-gate-prompts), 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.

Internal gateways (never user-invoked)

user-invocable: false — called only by other skills, never a user's first move.

Skill Purpose
/steer:tracker-sync The single gateway for all GitHub tracker reads/writes (MCP-first, gh fallback, manual floor). Also reads/writes native issue fields (field-get/field-set/bootstrap-fields for Priority/Effort/dates) and records native blocked-by relationships (link-blocked-by). 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:spec-scaffold Create a feature's spec (intent.md + contract.md) from the bundled templates (spine materialization is /steer:init / /steer:adopt's job).