/adr

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.