con un clic
adr
Create a numbered ADR from the bundled template.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Menú
Create a numbered ADR from the bundled template.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| 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.
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.