adr

name	adr
description	This skill should be used when the user asks to "create an ADR", "write an architecture decision record", "evaluate a design proposal", "compare technology options", "choose between X and Y", or describes a system-design decision needing tradeoff analysis.
argument-hint	<decision or system to design>

Architecture

Create an Architecture Decision Record (ADR) or evaluate a system design.

Modes

Create an ADR: "Should we use Kafka or SQS for our event bus?" Evaluate a design: "Review this microservices proposal" System design: "Design the notification system for our app"

See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.

Output — ADR Format

# ADR-[number]: [Title]

**Status:** Proposed | Accepted | Deprecated | Superseded
**Date:** [Date]
**Deciders:** [Who needs to sign off]

## Context
[What is the situation? What forces are at play?]

## Decision
[What is the change we're proposing?]

## Options Considered

### Option A: [Name]
| Dimension | Assessment |
|-----------|------------|
| Complexity | [Low/Med/High] |
| Cost | [Assessment] |
| Scalability | [Assessment] |
| Team familiarity | [Assessment] |

**Pros:** [List]
**Cons:** [List]

### Option B: [Name]
[Same format]

## Trade-off Analysis
[Key trade-offs between options with clear reasoning]

## Consequences
- [What becomes easier]
- [What becomes harder]
- [What we'll need to revisit]

## Action Items
1. [ ] [Implementation step]
2. [ ] [Follow-up]

Tips

1. State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
2. Name your options — Naming explicit alternatives forces a more balanced analysis, even when one option is the front-runner.
3. Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.