| name | adr-writer |
| version | 1.0.1 |
| model | sonnet |
| description | Produces a numbered Architecture Decision Record with context analysis, route comparison, decision rationale, consequences, and propagation checklist. Use when: 'write an ADR', 'architectural decision', 'record a decision', 'ADR for'. |
| triggers | ["write an ADR","architectural decision","record a decision","ADR for"] |
| category | govern-publish |
| inputs | [{"name":"decision_topic","type":"string","description":"The architectural decision or topic to document","required":true}] |
| outputs | [{"name":"adr_document","type":"ref","format":"markdown","description":"Numbered ADR markdown file saved to the decisions/ directory"}] |
ADR Writer Skill
I. Philosophy
An Architecture Decision Record is the project's institutional memory. Every significant technical choice that lives only in someone's head is a future incident — a re-fight, a regression, or a confused new contributor asking why things work the way they do.
ADRs are not bureaucracy. They are the minimum viable documentation that keeps a fast-moving project from looping back on itself. A good ADR takes fifteen minutes to write and saves three hours of re-derivation six months later.
The crafter does not write ADRs for every change — only for decisions that:
- Are hard to reverse
- Affect multiple components or repos
- Were made between competing legitimate alternatives
- Will confuse someone who wasn't in the room
II. When to Use
- When a significant architectural choice is being made or was just made
- When two or more teams or components need to align on an approach
- When a previous decision is being revisited and the reason for the change should be recorded
- When a new contributor asks "why do we do X this way?" and the answer is not in the code
Do not write an ADR for trivial implementation choices, naming conventions, or decisions with only one viable option.
III. Workflow
Step 1: GATHER
Read the decision context before writing anything.
- Identify what is being decided and why it matters now. What forces are at play — performance, maintainability, velocity, contract compatibility, cost?
- Identify which repos, contracts, and interfaces are affected. Run
grep and glob searches if needed — do not assume.
- Identify who made or is making the decision. Note any external constraints (regulatory, contractual, hard deadlines) that eliminate certain routes.
- Check whether a prior ADR covers related ground. Search the
decisions/ directory for existing ADR numbers and topics.
Step 2: SCOUT
Generate 3-5 routes before selecting one.
For each route:
- Description: What does this approach actually do?
- Risk: What can go wrong? What is the blast radius if it fails?
- Time: Rough estimate to implement
- Key tradeoff: What does this route give up to get its benefits?
Do not present routes that are not genuinely distinct. If two routes differ only in implementation detail (same architectural approach, different library), collapse them.
Optionally invoke the skill to produce a full scout document for complex decisions before drafting the ADR.
