Skip to content

adr.md

Latest commit

 

History

History
48 lines (35 loc) · 1.45 KB

adr.md

File metadata and controls

48 lines (35 loc) · 1.45 KB

Write an Architecture Decision Record documenting a significant technical decision.

Steps

  1. Ask for or infer the decision topic from the argument (e.g., "use PostgreSQL over MongoDB").
  2. Scan the codebase for existing ADRs in docs/adr/, docs/decisions/, or adr/ directories.
  3. Determine the next ADR number by counting existing records.
  4. Research the current codebase to gather context:
    • What technologies are currently used.
    • What constraints exist (team size, performance requirements, existing integrations).
  5. Draft the ADR with all required sections.
  6. Create the file as docs/adr/NNNN-<slug>.md.
  7. If a docs/adr/README.md index exists, add an entry for the new ADR.

Format

# ADR-NNNN: <Title>

## Status
Proposed | Accepted | Deprecated | Superseded by ADR-XXXX

## Context
What is the issue that we are seeing that motivates this decision?

## Decision
What is the change that we are proposing and/or doing?

## Consequences
What becomes easier or harder as a result of this decision?

### Positive
- Benefit 1

### Negative
- Tradeoff 1

### Risks
- Risk 1 with mitigation strategy

Rules

  • ADRs are immutable once accepted; create a new ADR to supersede an old one.
  • Keep the context section factual and free of opinion.
  • List at least one positive, one negative, and one risk consequence.
  • Use the project's existing ADR format if one already exists.
  • Date the ADR with the current date in the status section.