ADR Generator
Create Architecture Decision Records following the standard ADR format.
Quick Start
- •Identify the architectural decision to document
- •Gather context and constraints
- •List options considered with pros/cons
- •Document the decision and rationale
- •Save to
docs/adr/oradr/directory
ADR Template
markdown
# ADR-NNNN: [Title] ## Status [Proposed | Accepted | Deprecated | Superseded by ADR-XXXX] ## Context [What is the issue that we're seeing that is motivating this decision or change?] ## Decision [What is the change that we're proposing and/or doing?] ## Consequences ### Positive - [Benefit 1] - [Benefit 2] ### Negative - [Tradeoff 1] - [Tradeoff 2] ### Neutral - [Side effect that is neither positive nor negative]
Workflow
| Step | Action | Output |
|---|---|---|
| 1 | Identify decision | Clear problem statement |
| 2 | Research options | List of alternatives |
| 3 | Evaluate tradeoffs | Pros/cons for each option |
| 4 | Document decision | ADR file |
| 5 | Get approval | Status -> Accepted |
Naming Convention
code
docs/adr/ ├── 0001-use-postgresql-for-persistence.md ├── 0002-adopt-event-sourcing.md ├── 0003-implement-cqrs-pattern.md └── README.md (index of all ADRs)
When to Create ADRs
- •Choosing between technologies or frameworks
- •Defining API design patterns
- •Selecting architectural patterns (microservices, monolith, etc.)
- •Making security-related decisions
- •Establishing coding standards that affect architecture
Limitations
- •ADRs document decisions, not implementation details
- •Keep ADRs focused on a single decision
- •Link related ADRs rather than combining them