ADR Creator
Create concise Architecture Decision Records that explain a decision, the context that forced it, the options considered, and the consequences accepted.
Activation Contract
Use this skill when the user asks for an ADR, architecture decision record, technical decision record, or any formal record of why a technical or architectural choice was made.
Default to interview mode unless the user already supplied enough information to draft a complete ADR. Ask interview questions in the user's language. ADR artifact language is English unless the user explicitly asks for another language.
Hard Rules
- Ask one question at a time in interview mode.
- State once at the start of the interview that the user may skip questions or stop the interview at any time.
- Keep a dynamic estimated remaining-question counter; update it when dependencies appear or disappear.
- Recommend short example answers when they help the user respond.
- Format interview questions as readable Markdown, not plain text.
- Constructively challenge vague, contradictory, or rationale-free answers before drafting; proceed if the user explicitly says to continue anyway.
- Do not invent alternatives, pros, cons, or rationale. Ask when alternatives are missing.
- Use
Acceptedwhen the decision is already made; useProposedfor proposals, evaluations, or unclear status. - Write or modify files only when the user explicitly asks for a file/path.
Interview Flow
Gather only what is needed, dependency-first:
- Decision title and status.
- Context: problem, constraints, forces, and why the decision matters now.
- Chosen option or proposal.
- Options considered, with pros and cons for each.
- Consequences: benefits, drawbacks, risks, and trade-offs.
- Follow-up only when there are useful open actions or unresolved questions.
Question format:
### Question N — [focused question]
**Recommended answer:** [short example when useful]
**Why this matters:** [brief reason]
**Estimated remaining questions:** ~M
Mini example:
### Question 1 — Is this decision already made or still being proposed?
**Recommended answer:** "Accepted — we already chose PostgreSQL for billing data."
**Why this matters:** The status changes whether the ADR records a final choice or a proposal under review.
**Estimated remaining questions:** ~5
Output Contract
Read assets/template-markdown.md before drafting and fill that structure.
By default, return the final ADR as exactly one Markdown code block and do not create files. If the user explicitly requested a file/path, save the ADR there and summarize the saved path in chat.
Never leave placeholder instructions in the final ADR. If the user intentionally skips a required detail, use TBD sparingly and only for that skipped detail.
Reference
- Template:
assets/template-markdown.md