Architecture Decision Records
Turn live architecture trade-offs in agent sessions into numbered ADR markdown files and a durable log future you can read.
Overview
Architecture Decision Records is an agent skill most often used in Build (also Validate, Ship) that writes structured ADR markdown when significant technical alternatives are chosen or explained.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill architecture-decision-recordsWhat is this skill?
- Auto-detects decision moments when choosing frameworks, libraries, patterns, databases, or API shapes
- Produces lightweight Michael Nygard–style ADRs with Context, Decision, and status lifecycle fields
- Maintains an ADR log so “why X instead of Y?” is answerable without digging through chat history
- Supports explicit capture (“ADR this”) and retrospective lookup of existing records
- Status workflow covers proposed, accepted, deprecated, and superseded-by links
- ADR status values: proposed, accepted, deprecated, superseded by ADR-NNNN
Adoption & trust: 4.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Important architecture choices only exist in chat, Slack, or memory, so future you cannot explain why the codebase diverged from the obvious default.
Who is it for?
Solo builders who make non-trivial stack choices and want low-friction documentation without a separate wiki process.
Skip if: Trivial rename refactors or experiments you intend to throw away before any durable architectural commitment.
When should I use this skill?
User says let's record this decision, ADR this, we decided to, why did we choose X, or discusses significant framework, library, pattern, database, or API trade-offs.
What do I get? / Deliverables
Each major decision becomes a numbered ADR with context, alternatives, and status in-repo, plus an ADR log for quick historical lookup.
- ADR-NNNN markdown files
- ADR index or log in the repo
- Status-linked decision history for superseded choices
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
ADRs belong beside the codebase once you are making real structural choices during implementation and ongoing iteration. Docs subphase is the canonical shelf for persistent decision records that explain why the repo looks the way it does.
Where it fits
Document why the spike uses SQLite instead of Postgres before promoting the prototype to production shape.
Record the API style and auth model you picked after comparing two integration approaches with your agent.
Link a superseding ADR when a reviewer questions an earlier pattern choice during pre-release review.
How it compares
Use for in-session ADR authoring instead of unstructured “we decided…” comments that never become searchable repo docs.
Common Questions / FAQ
Who is architecture-decision-records for?
Indie developers and tiny teams using AI coding agents who need a paper trail for framework, data, and API decisions without a formal architecture review board.
When should I use architecture-decision-records?
During Validate when comparing prototype stacks, Build when locking patterns and storage, and Ship review when explaining trade-offs—or when you say ADR this, we decided to, or why did we choose X.
Is architecture-decision-records safe to install?
It is documentation-only with no special network requirements; still review the Security Audits panel on this page and avoid pasting secrets into ADR context sections.
SKILL.md
READMESKILL.md - Architecture Decision Records
# Architecture Decision Records Capture architectural decisions as they happen during coding sessions. Instead of decisions living only in Slack threads, PR comments, or someone's memory, this skill produces structured ADR documents that live alongside the code. ## When to Activate - User explicitly says "let's record this decision" or "ADR this" - User chooses between significant alternatives (framework, library, pattern, database, API design) - User says "we decided to..." or "the reason we're doing X instead of Y is..." - User asks "why did we choose X?" (read existing ADRs) - During planning phases when architectural trade-offs are discussed ## ADR Format Use the lightweight ADR format proposed by Michael Nygard, adapted for AI-assisted development: ```markdown # ADR-NNNN: [Decision Title] **Date**: YYYY-MM-DD **Status**: proposed | accepted | deprecated | superseded by ADR-NNNN **Deciders**: [who was involved] ## Context What is the issue that we're seeing that is motivating this decision or change? [2-5 sentences describing the situation, constraints, and forces at play] ## Decision What is the change that we're proposing and/or doing? [1-3 sentences stating the decision clearly] ## Alternatives Considered ### Alternative 1: [Name] - **Pros**: [benefits] - **Cons**: [drawbacks] - **Why not**: [specific reason this was rejected] ### Alternative 2: [Name] - **Pros**: [benefits] - **Cons**: [drawbacks] - **Why not**: [specific reason this was rejected] ## Consequences What becomes easier or more difficult to do because of this change? ### Positive - [benefit 1] - [benefit 2] ### Negative - [trade-off 1] - [trade-off 2] ### Risks - [risk and mitigation] ``` ## Workflow ### Capturing a New ADR When a decision moment is detected: 1. **Initialize (first time only)** — if `docs/adr/` does not exist, ask the user for confirmation before creating the directory, a `README.md` seeded with the index table header (see ADR Index Format below), and a blank `template.md` for manual use. Do not create files without explicit consent. 2. **Identify the decision** — extract the core architectural choice being made 3. **Gather context** — what problem prompted this? What constraints exist? 4. **Document alternatives** — what other options were considered? Why were they rejected? 5. **State consequences** — what are the trade-offs? What becomes easier/harder? 6. **Assign a number** — scan existing ADRs in `docs/adr/` and increment 7. **Confirm and write** — present the draft ADR to the user for review. Only write to `docs/adr/NNNN-decision-title.md` after explicit approval. If the user declines, discard the draft without writing any files. 8. **Update the index** — append to `docs/adr/README.md` ### Reading Existing ADRs When a user asks "why did we choose X?": 1. Check if `docs/adr/` exists — if not, respond: "No ADRs found in this project. Would you like to start recording architectural decisions?" 2. If it exists, scan `docs/adr/README.md` index for relevant entries 3. Read matching ADR files and present the Context and Decision sections 4. If no match is found, respond: "No ADR found for that decision. Would you like to record one now?" ### ADR Directory Structure ``` docs/ └── adr/ ├── README.md ← index of all ADRs ├── 0001-use-nextjs.md ├── 0002-postgres-over-mongo.md ├── 0003-rest-over-graphql.md └── template.md ← blank template for manual use ``` ### ADR Index Format ```markdown # Architecture Decision Records | ADR | Title | Status | Date | |-----|-------|--------|------| | [0001](0001-use-nextjs.md) | Use Next.js as frontend f