Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.

Architecture Decision Records Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions. Use this skill when Making significant architectural decisions Documenting technology choices Recording design trade offs Onboarding new team members Reviewing historical decisions Establishing decision making processes Do not use this skill when You only need to document small implementation details The change is a minor patch or routine maintenance There is no architectural decision to capture Instructions 1. Capture the decision context, constraints, and drivers. 2. Document considered options with tradeoffs. 3. Record the decision, rationale, and consequences. 4. Link related ADRs and update status over time. Core Concepts 1. What is an ADR? An Architecture Decision Record captures: Context : Why we needed to make a decision Decision : What we decided Consequences : What happens as a result 2. When to Write an ADR Write ADR Skip ADR New framework adoption Minor version upgrades Database technology choice Bug fixes API design patterns Implementation details Security architecture Routine maintenance Integration patterns Configuration changes 3. ADR Lifecycle Templates Template 1: Standard ADR (MADR Format) Template 2: Lightweight ADR Template 3: Y Statement Format Template 4: ADR for Deprecation Template 5: Request for Comments (RFC) Style OrderCreated { orderId, customerId, items[], timestamp } OrderItemAdded { orderId, item, timestamp } OrderItemRemoved { orderId, itemId, timestamp } PaymentReceived { orderId, amount, paymentId, timestamp } OrderShipped { orderId, trackingNumber, timestamp } ADR Management Directory Structure ADR Index (README.md) Automation (adr tools) Review Process Best Practices Do's Write ADRs early Before implementation starts Keep them short 1 2 pages maximum Be honest about trade offs Include real cons Link related decisions Build decision graph Update status Deprecate when superseded Don'ts Don't change accepted ADRs Write new ones to supersede Don't skip context Future readers need background Don't hide failures Rejected decisions are valuable Don't be vague Specific decisions, specific consequences Don't forget implementation ADR without action is waste Resources [Documenting Architecture Decisions (Michael Nygard)](https://cognitect.com/blog/2011/11/15/documenting architecture decisions) [MADR Template](https://adr.github.io/madr/) [ADR GitHub Organization](https://adr.github.io/) [adr tools](https://github.com/npryce/adr tools) Limitations Use this skill only when the task clearly matches the scope described above. Do not treat the output as a substitute for environment specific validation, testing, or expert review. Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

architecture-decision-records