documenting-decisionslisted

# Documenting Decisions Architecture Decision Records (ADRs) capture important technical decisions with their context, rationale, and consequences. They are the institutional memory that explains WHY the codebase looks the way it does. Write the prose this skill governs at a seventh-grade reading level, in STE-flavored mode — short sentences, common words, no unexplained jargon. Full methodology: `writing-prose`. Before you finalize prose this skill governs, call the Skill tool with `writing-prose` and apply its `## Self-lint` checklist. ## ADR Format Every ADR follows this structure: ```markdown # NNNN. Decision Title ## Status Proposed | Accepted | Deprecated | Superseded by [NNNN](NNNN-title.md) ## Context What is the issue that we're seeing that is motivating this decision or change? Describe the forces at play — technical constraints, business requirements, team capabilities, timeline pressure. Be objective: state facts, not opinions. ## Decision What is the change that we're proposing and/or doing? State the decision in full sentences, using active voice: "We will..." not "It was decided that..." ## Consequences What becomes easier or more difficult to do because of this change? List both positive and negative consequences. Every decision has trade-offs — if you cannot identify any negative consequences, you have not thought hard enough. ``` ## File Convention ADRs live in `docs/decisions/` with zero-padded sequential numbering: ``` docs/decisions/ 000