メニュー
Creates one Architecture Decision Record (ADR) — a short, objective record of a decision already made, its context, and its consequences. Use when the user wants to document a technical decision, mentions ADR, architecture decision record, or invokes /adr.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Executes an implementation plan (from /spec) end to end: turns its Steps into a tracked checklist, works through them one at a time — implement, run the Step's Verify, check it off, commit — then runs the plan's overall Verification and delivers a PR. When the plan is one phase of a /phasing roadmap, delivery also writes the phase's carry-over fragment and flips its status in the roadmap. Invoking /implement is itself the go-ahead to execute; there's no separate approval gate. Use when the user wants to execute, build, or ship a plan that already exists, or invokes /implement.
Turns settled PRD/TDD/ADR scope into an ordered set of phases, each sized to be exactly one /spec (one Approach, one Verify surface, one PR), organized as a dependency graph so parallel streams fall out of real technical dependency instead of being guessed upfront. Writes the roadmap to docs/roadmaps/<slug>/roadmap.md; each phase becomes its own /spec afterward. Use when the user wants to break a feature or system into phases, plan a rollout across multiple PRs, or invokes /phasing.
Writes or updates a Product Requirements Document (PRD) — a concise, best-practice description of what a system, feature, or subsystem does for its users, never how it's built. Takes its input from a /brainstorm convergence artifact, a /tdd document, or the user's own description of a feature. Use when the user wants a PRD, product requirements doc, or asks to turn a brainstorm or design into product requirements, or invokes /prd.
Reviews a delivered change against its contracts — the /spec plan, the roadmap phase's boundary, binding ADRs, and test authenticity — and returns a verdict with blocking and advisory findings.
Writes or updates an implementation plan — a concise, actionable breakdown of how one change will be made: what recon (and any binding ADRs) found, the chosen approach, an ordered list of steps, and how each step (and the change as a whole) is verified done. Scoped to a single change, not a system (that's a TDD) and not user-facing behavior (that's a PRD) — the plan is the handoff artifact between deciding what to build and building it. Use when the user wants an implementation plan, asks to plan a feature, bugfix, or refactor before coding it, or invokes /spec.
Writes or updates a Technical Design Document (TDD) — a description of how a system, subsystem, or component is put together. Not a proposal: states the design rather than building a case for it, and references the ADRs, PRDs, or brainstorm docs that justify it instead of restating them. Grounds every part in the most reliable source available — code where it's built, anchor docs where it isn't yet — and flags unbuilt pieces inline instead of labeling the whole document. Use when the user asks for a technical design document, architecture document, or system design doc, or wants a system's (or part of a system's) architecture written down with diagrams.
| name | adr |
| description | Creates one Architecture Decision Record (ADR) — a short, objective record of a decision already made, its context, and its consequences. Use when the user wants to document a technical decision, mentions ADR, architecture decision record, or invokes /adr. |
| license | MIT |
| metadata | {"author":"Marcos Oliveira","version":"1.1.0"} |
Records one decision that has already been made — its context and its consequences, not a case for making it. If the decision is still open, that belongs in a discussion or proposal; write the ADR once it settles.
Search the repo for an existing ADR directory, in order: docs/adrs/, docs/adr/, doc/adrs/, decisions/, docs/architecture/decisions/.
docs/adrs/ as the default location, and use the AskQuestion tool so the user can confirm it or name a different path. Do not create any file or directory before they answer.Completion criterion: a confirmed directory path that exists on disk (create it once approved).
Use what the conversation already established. For any of these still missing, ask — one question per gap, no more:
Skip alternatives entirely unless the user names a rejected option — an ADR states the decision, it doesn't weigh options for the reader.
Completion criterion: Title, Context, Decision, and Consequences all hold real content — no placeholders.
List the ADR directory for files matching adr-NNNN-*.md; take the highest number and add one (0001 if the directory is empty). Slugify the title into kebab-case.
Filename: adr-NNNN-<title-in-kebab-case>.md (e.g. adr-0007-use-postgres-for-orders.md).
Completion criterion: filename decided, no collision with an existing file.
Follow references/template.md exactly — no extra sections. Status defaults to Accepted unless the user says otherwise (Proposed, Rejected, Deprecated, Superseded by <link>). Write in the same language the user used in the conversation.
If this ADR supersedes an earlier one, update that file's Status line to Superseded by [adr-NNNN](adr-NNNN-slug.md).
Tell the user the path written and its status.