Menu
Create a numbered ADR from the bundled template.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Scaffold an autonomous loop for a managed repo — 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, and opens draft PRs. Wired to stop at every human gate (rule 53): it delivers up to the PR, it never merges/deploys. Instantiates templates/github/workflows/steer-loop.yml and lands it via the normal autonomous branch-push + PR (Commit autonomy — the merge review is the gate).
Adopt an existing repo that never went through bootstrap (a "vibe-coded" app) into the standards — reverse-engineer the /spec from the code, triage productionization (Keep/Refactor/Rewrite/Reject per area), and sync the plugin's bundled scaffolding without clobbering working code.
Guided flow for a non-technical product owner — idea → interview → approved spec → working local app → handoff for dev review, with Claude driving all tooling.
One-time setup for a new managed repo — bootstrap the /spec spine + repo scaffolding from the plugin's bundled scaffold (the plugin replaces the old static repository-template as the bootstrap source), or resolve placeholders in a legacy template fork. In both cases pin the toolchain and leave the repo working spec-first.
Absorb a PO-supplied spec/roadmap document (docx/pptx/xlsx/pdf) into the /spec spine — version-stamp and commit the binary plus a normalized Markdown extraction under spec/sources/ — relocating the dropped file into that canonical home so it does not linger where it was uploaded — git-diff it against the prior version, and surface a structured what-changed report. Then route the real changes into intent/contract/vision/roadmap and the tracker via the relevant skills, never clobbering human-authored prose (conflicts become Open questions). Idempotent on an unchanged document. In clarify mode, absorbs a client clarification document instead: it segments the extraction, maps each unit against open questions and the feature list, and sorts them into a three-bucket worklist — answers routed to /steer:questions, new scope to the reconcile rows, unmatched surfaced for the human.
Make GitHub branch protection — the real gate against direct-push-to-main — reliable on a managed repo: read policy/branch-protection.yml, diff it against the repo's live protection, and on explicit confirmation apply the missing settings via gh api (branch protection, secret scanning, Dependabot alerts). Verify by default; configures the GitHub-side gate only — steer is advisory in the local session (rule 95) and cannot block local pushes.
| name | adr |
| description | Create a numbered ADR from the bundled template. |
| when_to_use | Use for any hard-to-reverse or cross-cutting choice (stack, database, auth, deployment, new pattern) or when asked to record a decision. |
Create a new Architecture Decision Record at /spec/decisions/000N-[slug].md in
the product repo, from the bundled template.
spec/decisions/ and use the highest
existing 000N + 1 (start at 0001). Never renumber existing ADRs.[slug] (use-postgres-for-search).mkdir -p spec/decisions), then copy
${CLAUDE_PLUGIN_ROOT}/templates/spec/adr.md → spec/decisions/000N-[slug].md.Proposed
until accepted; set Deciders.Write an ADR for choices that are hard to reverse (database, auth provider, deployment platform, tenancy model, major pattern), a new pattern other features will follow, an explicit rejection of an obvious alternative, or anything a future dev would ask "why did they do it this way?" about.
Do not write one for routine implementation choices, things obvious from the
code, or single-feature decisions (those go in the feature's contract.md).
When superseding an ADR, mark the old one Superseded by [link] and link the new
one — do not delete or renumber it. Full guidance:
${CLAUDE_PLUGIN_ROOT}/templates/reference/SPEC-FRAMEWORK.md.
ADRs are exempt from template reconciliation — they are immutable,
point-in-time records. Never retrofit a newer adr.md template's sections into an
existing ADR; supersede it with a new one instead.
After drafting the ADR, emit a ## Recommended next actions block per
${CLAUDE_PLUGIN_ROOT}/templates/reference/NEXT-ACTIONS.md. A freshly written ADR
is Proposed, so the next step is a human decision — not a command.
| Observed state | Category | Action / suggested command |
|---|---|---|
ADR drafted, Status: Proposed | Human decision required | The Deciders ratify (Accepted) or reject it (no command) |
| ADR accepted, supersedes an older one | Recommended | Mark the old ADR Superseded by [link] |
| Accepted, no follow-up | Complete | No action is currently required. |
The block recommends; ratifying the decision stays with the named Deciders.