adr-writerlisted

# adr-writer Adapts the ADR pattern (Michael Nygard's original "any architecturally significant decision deserves a record") to the org's vault structure. Most architecturally significant decisions evaporate without an ADR; this skill makes capturing one cheap. ## When to use - A technical decision has been made (sync vs async, batch vs stream, monolith vs microservice, KMS vs HSM for this case). - A decision is about to be made and the author wants the ADR ready to ratify. - Retroactively documenting a past decision discovered to be undocumented. ## When NOT to use - Proposing a decision for org-wide discussion → `rfc-writer`. - Informing leadership for an ask → `decision-memo-writer`. - Quick decisions captured via the qc-decision template → [`quick-capture`](../quick-capture/SKILL.md). - Control-exception decisions → [`exception-request-drafter`](../exception-request-drafter/SKILL.md). ## Document structure (org's ADR template) ```markdown # ADR-{number} — {title} **Status**: proposed | accepted | superseded | rejected **Date**: YYYY-MM-DD **Authors**: {names} **Supersedes**: {[[adr-link]] if applicable} ## Context {The forces at play. What problem are we solving? What constraints apply?} ## Decision {The technical decision. Concise. Imperative voice — "we will use X" not "X might be a good choice".} ## Consequences ### Positive - ... ### Negative / trade-offs - ... ### Neutral - ... ## Alternatives considered ### {Alt 1} — rejected because ... ### {Alt 2} —