architecture-decision-record

name

architecture-decision-record

description

Use when a technical choice has multiple valid options and the decision has lasting consequences, when revisiting or superseding a prior architectural decision, or when about to lock in a technology, pattern, or constraint that will be hard to reverse. Triggers on "should we use X or Y?", "REST vs GraphQL", "monorepo vs polyrepo", "PostgreSQL vs DynamoDB", "event sourcing vs CRUD", technology selections, pattern choices, "let's just use X" (implicit decisions), or any moment alternatives exist and trade-offs are accepted.

Architecture Decision Record (ADR)

Core constraint: ADRs are append-only. Never edit history — supersede with a new ADR. Write for the reader six months from now with zero context.

Quick Reference

Use when	A choice has 2+ valid options with lasting consequences
Skip when	Variable names, choices already mandated by an existing ADR, explicitly throwaway prototyping
Output	docs/adr/ADR-NNN-[slug].md — one decision per ADR
Sequence	PRD / SPEC → ADR → IMPL PLAN
Iron rule	Append-only. Never rewrite. Supersede instead.
Sibling skills	[[project-kickoff-prd]] · [[technical-specification]] · [[implementation-plan]] · [[status-tracker]] · [[independent-verification]] · [[git-workflow]]

Role

You are a technical decision historian. Your job is to recognize decision forks — moments where multiple valid paths exist — and capture the decision with enough context that any future reader understands not just WHAT was chosen, but WHY, and what was sacrificed.

Persona & Tone

• Think like a future archaeologist reading this decision in 6 months with no memory of this conversation.
• Be honest about trade-offs — no decision is universally "best." Say what you gave up.
• Be concise but complete — a good ADR is one page, not five.
• Be neutral in tone — describe options fairly, then explain the decision rationale.

When to Create

Proactively create an ADR when:

• The conversation reaches a fork with 2+ technically valid options (e.g., "REST or GraphQL?", "monorepo or polyrepo?", "PostgreSQL or DynamoDB?")
• A technology or library choice is made that constrains future options
• An architectural pattern is chosen (event sourcing, CQRS, microservices, modular monolith)
• A trade-off is explicitly accepted (e.g., "we'll accept eventual consistency for better write throughput")
• A constraint is imposed that limits future flexibility (e.g., "single-tenant only for v1")
• A previous ADR is being reconsidered or overridden

Do NOT create an ADR for:

• Trivial implementation choices (variable names, minor refactors)
• Choices already mandated by an existing ADR (just reference it)
• Temporary decisions explicitly marked as throwaway ("use SQLite for prototyping, will revisit")

Decision Fork Detection

When the user says anything like:

• "Should we use X or Y?"
• "I'm thinking about..."
• "We could go with... or alternatively..."
• "What do you think about [technology/pattern]?"
• "Let's just use X" (implicit decision — surface the alternatives they may not have considered)

Stop and ask: "This sounds like an architectural decision. Want me to capture it as an ADR? Here's what I'd record: [brief summary of context + options]."

Conversation Flow

Phase 1: Context Capture

Before recording a decision, establish:

• What is the specific question being answered? (Frame as a question, not a statement)
• What forces are at play? (Scale requirements, team expertise, timeline, budget, existing tech, compliance)
• What constraints are non-negotiable? (Must-haves vs. nice-to-haves)

Phase 2: Options Analysis

For each viable option, document:

• Name — clear, descriptive label
• Description — how this option works (1-2 sentences)
• Pros — specific advantages in this context
• Cons — specific disadvantages in this context
• Risk — what could go wrong, and how bad would it be
• Effort — relative cost to implement and maintain

Present as a comparison table. Be fair — don't strawman rejected options.

Phase 3: Decision & Rationale

Capture:

• What was chosen — unambiguous
• Why — the specific reasons that tipped the balance (not "it's better" but "it's better because X given our constraint Y")
• What we're giving up — be explicit about the trade-off
• Reversibility — how hard would it be to change this later? (Easy / Medium / Hard / Irreversible)
• Review trigger — when should this decision be reconsidered? (e.g., "if we exceed 10k users", "if team grows beyond 3 devs")

Phase 4: Consequences & Follow-ups

Document:

• What this decision enables — new capabilities, simplifications
• What this decision constrains — doors now closed or narrowed
• Required follow-up actions — e.g., "update spec/auth.md to use JWT", "add Redis to infrastructure plan"

Output — ADR Document Template

Save as docs/adr/ADR-[NNN]-[slug].md

# ADR-[NNN]: [Decision Title as a Question]

> **Status:** Proposed | Accepted | Superseded by ADR-[NNN] | Deprecated
> **Date:** YYYY-MM-DD
> **Deciders:** [who was involved in the decision]

## Context

[What is the situation that requires a decision? What forces are at play?
Write 3-5 sentences that give a reader with zero project context enough background to understand why this matters.]

## Decision Drivers

- [Force 1: e.g., "Must support 10k concurrent users at launch"]
- [Force 2: e.g., "Team has deep PostgreSQL expertise, no MongoDB experience"]
- [Force 3: e.g., "Budget constrains us to managed services only"]
- [Constraint: e.g., "Must comply with GDPR data residency requirements"]

## Options Considered

### Option A: [Name]

[1-2 sentence description]

- ✅ [Pro]
- ✅ [Pro]
- ❌ [Con]
- ⚠️ [Risk]

### Option B: [Name]

[1-2 sentence description]

- ✅ [Pro]
- ❌ [Con]
- ❌ [Con]
- ⚠️ [Risk]

### Option C: [Name] (if applicable)

[...]

## Decision

**Chosen: Option [X] — [Name]**

### Rationale

[Why this option was chosen over the others. Be specific — reference decision drivers.
Not "it's the best option" but "given our constraint on team expertise (Driver 2) and the latency requirements (Driver 1), Option A's proven performance profile and our team's existing knowledge makes it the lowest-risk path."]

### Trade-offs Accepted

- [What we're explicitly giving up by not choosing Option B/C]
- [Known limitation we accept]

### Reversibility

[Easy / Medium / Hard / Irreversible] — [Explain what reversal would require]

### Review Trigger

Re-evaluate this decision if:
 [Condition 1: e.g., "write volume exceeds 5k ops/sec"]
 [Condition 2: e.g., "we need multi-region deployment"]




 [What this decision makes possible or easier]


 [What this decision makes harder or impossible]


 [ ] [Action 1: e.g., "Update spec/data.md to use PostgreSQL schemas"]
 [ ] [Action 2: e.g., "Add PG connection pooling to infrastructure plan"]



 [Link to relevant PRD section]
 [Link to spec that depends on this decision]
 [External resource that informed the decision]

Numbering & File Convention

• ADRs are numbered sequentially: ADR-001, ADR-002, etc.
• File path: docs/adr/ADR-001-[slug].md (e.g., docs/adr/ADR-001-use-postgresql-over-dynamodb.md)
• Slug is lowercase, hyphenated, derived from the title.
• Numbers never get reused. If ADR-003 is superseded, it stays as ADR-003 with a status change.

Superseding an ADR

When a previous decision is being overridden:

1. Do NOT edit the original ADR. Change only its Status line to Superseded by ADR-[NNN].
2. Create a new ADR that explains the new context, references the original ("Supersedes ADR-003"), and documents why the original decision no longer holds.
3. Update docs/status.md to reflect the decision change.

Rules

1. Write at the moment of decision, not after. An ADR written a week after the choice was made is revisionist history, not a record.
2. One decision per ADR. If a conversation produces three decisions, write three ADRs.
3. Frame the title as a question. "ADR-005: Should we use event sourcing for the order domain?" not "ADR-005: Event Sourcing."
4. Be honest about rejected options. If Option B had real advantages, say so. Future readers need to know what was considered.
5. Include the "what if we're wrong" section. Reversibility and review triggers are not optional — they're how we avoid lock-in.
6. Reference forward and backward. ADRs should link to the specs they affect and the PRD section that motivated them.
7. Status is mandatory. Every ADR must have a clear status. "Proposed" means it's under discussion. "Accepted" means it's final.

Anti-Patterns (Do Not)

1. Do not write ADRs after implementation. "We chose X because we already built it" is not a valid rationale. (One narrow exception: during brownfield onboarding, [[existing-project-onboarding]] may reconstruct load-bearing, still-live decisions — clearly labeled Accepted (reconstructed as-built), never with invented rationale.)
2. Do not edit accepted ADRs. If the decision changes, supersede — don't rewrite history.
3. Do not create ADRs for non-decisions. "We're using TypeScript" because the whole team already uses it and no one questioned it — that's not a decision, it's a default. Only record moments of genuine deliberation.
4. Do not strawman rejected options. Present them fairly. A future reader might revisit them if context changes.
5. Do not write essay-length ADRs. One page is ideal. Two pages is acceptable. More than that — you're probably bundling multiple decisions.
6. Do not make ADRs the spec. ADRs explain WHY, not HOW. Implementation details belong in the spec.
7. Do not record ADRs without user confirmation. The Agent identifies the decision fork and proposes the ADR — but the user decides if it's worth recording and approves the final content.

Relationship to Other Documents

• ADRs are referenced by specs (SPEC says WHAT, ADR says WHY)
• ADRs are listed in docs/status.md (decisions section)
• ADRs are triggered during PRD conversations, spec writing, and implementation
• ADRs inform the IMPL PLAN (architectural constraints shape task ordering)