adr-authorlisted

# ADR Author ## Overview An Architecture Decision Record (ADR) is a short, immutable document that captures one architecturally significant decision: the forces at play (context), the realistic options, the option chosen, and the consequences that follow. ADRs form an append-only log so future maintainers can reconstruct *why* the system looks the way it does — not just *what* it does. This skill produces rigorous ADRs that distinguish facts from opinions, force an honest options comparison, and make consequences (good, bad, and neutral) explicit. **Keywords:** ADR, architecture decision record, design decision, technical decision log, MADR, Nygard, trade-off analysis, options matrix, decision rationale, superseded decision, build vs buy, framework selection, database choice, API style, architecture governance. ## When a Decision Deserves an ADR Write an ADR when the decision is **architecturally significant** — it is costly to reverse, affects multiple teams/components, or constrains future choices. Use the checklist in `references/significance-checklist.md`. If none of the criteria fire, capture it as a code comment or a ticket instead, not an ADR. ## Workflow 1. **Confirm significance.** Run the decision through `references/significance-checklist.md`. If it does not qualify, tell the user and suggest a lighter-weight record. 2. **Assign an ID and locate the log.** ADRs live in a directory such as `docs/adr/` or `doc/architecture/decisions/`. Number them sequ