adrlisted

# Architecture Decision Records (ADRs) This skill provides knowledge about creating and maintaining Architecture Decision Records using the MADR v4.0.0 (Markdown Any Decision Records) format. ## Overview ADRs capture the "why" behind technical choices. They prevent teams from re-arguing settled decisions and give new team members context on past choices. ADRs are in ThoughtWorks' Technology Radar "Adopt" category and used by AWS and the UK Government Digital Service. ## When to Write an ADR - Choosing between technologies or frameworks - Selecting an architectural pattern - Making infrastructure decisions - Changing a significant convention - Any decision that would be questioned 6 months later ## Two-Tier Rule: Lightweight by Default, Full MADR for Big Decisions Not every decision deserves a full MADR document. Use two tiers: **Lightweight (the default).** A Matt-style micro-ADR: a title plus 1-3 sentences covering what we're deciding, why, and what would make us revisit it. Use this for every decision unless the full-MADR criteria below are met. ```markdown # NNNN — [Title of the decision] [1-3 sentences: what we're deciding + why + what would trigger revisiting it.] ``` **Full MADR v4.0.0 (big decisions only).** Required when the decision meets any of these criteria: - **Breaking** — it changes a public contract, convention, or behavior others depend on - **Costly to undo** — reversing it later would take significant rework or migration - **Multiple serious opt