architecture-decision-records
- Use it when:
- You're making or recording a significant technical decision, such as a database or framework choice, or setting up a decision process for a team.
- It does:
- Says when an ADR is worth writing, how one moves from proposed to accepted, deprecated or superseded, and how to keep a numbered index in docs/adr.
- You get:
- ADRs from five templates: standard (MADR), lightweight, a one-sentence Y-statement, deprecation with a migration plan, and RFC style.
- Also covers:
- adr-tools commands, and a review checklist for before submission, during review and after acceptance.
TL;DR
An Architecture Decision Record, or ADR, explains why a technical decision was made: its context, the decision and its consequences. Write one for a new framework, a database, an API pattern or a security architecture; skip it for bug fixes, minor upgrades and configuration changes. ADRs live as numbered files in docs/adr, with a README index of title, status and date. An accepted ADR is never edited: a new one supersedes it, and rejected ones stay as a record. Before drafting, the agent reads the matching template: a full record in the MADR format with decision drivers, considered options, pros, cons and risks; a lightweight one; a Y-statement (in the context of, facing, we decided for and against, to achieve, accepting that); a deprecation with a migration plan and lessons learned; or an RFC with detailed design, drawbacks, alternatives and open questions. It also lists adr-tools commands to create, supersede and link records. Keep each ADR to one or two pages and be honest about trade-offs.
Summarizes the skill at 4bde316.
npx skills add https://github.com/wshobson/agents --skill architecture-decision-records skills.sh pageSource on GitHubAll skills from wshobson/agents
More weekly downloads than 71% of skills
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 626 |
| Sep 28 | 747 |
| Oct 5 | 741 |
| Oct 12 | 740 |
| Oct 19 | 1,524 |
| Oct 26 | 1,115 |
| Nov 2 | 1,057 |
| Nov 9 | 941 |
More downloads than 74% of skills
More stars than 76% of repos
Older than 82% of skills
| Category |
Articles, docs, internal comms, research write-ups and prose that doesn't read as generated. Make the agent question you and write the plan down before it writes code. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
Knowledge and rules the agent applies while it works: best practices, design principles, API references. |
| Effect |
Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
Everyone else. Unverified vendor claims default to community. |
| Topics |
SKILL.md
From wshobson/agents at 4bde316. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: architecture-decision-records
description: 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.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
Proposed → Accepted → Deprecated → Superseded
↓
Rejected
Before drafting a standard, lightweight, or Y-statement ADR, read decision templates.
Before drafting a deprecation ADR or RFC, read deprecation and RFC templates.
ADR Management
Directory Structure
docs/
├── adr/
│ ├── README.md # Index and guidelines
│ ├── template.md # Team's ADR template
│ ├── 0001-use-postgresql.md
│ ├── 0002-caching-strategy.md
│ ├── 0003-mongodb-user-profiles.md # [DEPRECATED]
│ └── 0020-deprecate-mongodb.md # Supersedes 0003
ADR Index (README.md)
# Architecture Decision Records
This directory contains Architecture Decision Records (ADRs) for [Project Name].
## Index
| ADR | Title | Status | Date |
| ------------------------------------- | ---------------------------------- | ---------- | ---------- |
| [0001](0001-use-postgresql.md) | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |
| [0002](0002-caching-strategy.md) | Caching Strategy with Redis | Accepted | 2024-01-12 |
| [0003](0003-mongodb-user-profiles.md) | MongoDB for User Profiles | Deprecated | 2023-06-15 |
| [0020](0020-deprecate-mongodb.md) | Deprecate MongoDB | Accepted | 2024-01-15 |
## Creating a New ADR
1. Copy `template.md` to `NNNN-title-with-dashes.md`
2. Fill in the template
3. Submit PR for review
4. Update this index after approval
## ADR Status
- **Proposed**: Under discussion
- **Accepted**: Decision made, implementing
- **Deprecated**: No longer relevant
- **Superseded**: Replaced by another ADR
- **Rejected**: Considered but not adopted
Automation (adr-tools)
# Install adr-tools
brew install adr-tools
# Initialize ADR directory
adr init docs/adr
# Create new ADR
adr new "Use PostgreSQL as Primary Database"
# Supersede an ADR
adr new -s 3 "Deprecate MongoDB in Favor of PostgreSQL"
# Generate table of contents (to a separate file, so the hand-written
# index and guidelines in README.md are not overwritten)
adr generate toc > docs/adr/toc.md
# Link related ADRs
adr link 2 "Complements" 1 "Is complemented by"
Review Process
## ADR Review Checklist
### Before Submission
- [ ] Context clearly explains the problem
- [ ] All viable options considered
- [ ] Pros/cons balanced and honest
- [ ] Consequences (positive and negative) documented
- [ ] Related ADRs linked
### During Review
- [ ] At least 2 senior engineers reviewed
- [ ] Affected teams consulted
- [ ] Security implications considered
- [ ] Cost implications documented
- [ ] Reversibility assessed
### After Acceptance
- [ ] ADR index updated
- [ ] Team notified
- [ ] Implementation tickets created
- [ ] Related documentation updated
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