Agent skill · writing content · aiskillstore
architecture-decision-records
Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
Why this skill is useful
Codifies a structured approach to documenting architectural decisions, which the AI could infer but now doesn't have to guess.
What it needs
About 7k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Architecture Decision Records Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions. When to Use This Skill Making significant architectural decisions Documenting technology choices Recording design trade-offs Onboarding new team members Reviewing historical decisions Establishing decision-making processes 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 Archi …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/architecture-decision-records--1456c5