| name | docs-adr |
|---|---|
| description | Use when a change alters architecture, constraints, guardrails, or long-lived technical decisions and may need an ADR. |
Use when a change alters architecture, technical constraints, guardrails, or decisions with long-lived consequences.
docs/adr/NNNN-title-of-decision.md
Follow:
docs/adr/README.mddocs/adr/template.md
- Write the ADR after scope and impact are clear through definition, spec, or plan mode.
- Validate the ADR before implementation starts when the change depends on that decision.
- architecture choices that affect future changes
- trade-offs that should not be rediscovered repeatedly
- decisions that constrain implementation patterns or system boundaries
- updates to existing architectural rules
Use the existing ADR template:
- Title
- Context
- Decision
- Consequences
- Alternatives Considered
- Rationale
- Date
- Status
- Links
- Prefer updating an existing ADR or superseding one before adding a new record.
- Focus on why the decision was made, not on retelling the full implementation plan.
- Keep the document durable: record the context that matters after the current change is over.
- Do not defer the ADR until after coding when the implementation depends on the architectural decision.
- Update
docs/adr/README.mdwhen a new ADR is added. - If the change is local and reversible, ADR is usually the wrong artifact.