Create Architecture Decision Record from specification context.
Generates Architecture Decision Records from specification context using MADR format.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install spec-driven-development@melodic-software<spec file> [--decision <decision summary>]Create an ADR (Architecture Decision Record) from specification context.
Create an ADR when a specification contains:
Uses Markdown Any Decision Records (MADR) format:
# ADR-NNN: [Title in Imperative Form]
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Context
[Forces at play, situation motivating this decision]
## Decision
We will [decision in imperative form].
## Consequences
### Positive
- [Benefits]
### Negative
- [Drawbacks]
### Neutral
- [Trade-offs]
## Alternatives Considered
### [Alternative 1]
**Pros:** [advantages]
**Cons:** [disadvantages]
**Why Rejected:** [reason]
Load Specification
Extract Decisions
adr-creator agentResearch Alternatives
Generate ADR
Save ADR
docs/adr/ (or user-specified location)$1 - Specification file path--decision - Specific decision to document--output - Output directory (default: docs/adr/)--number - ADR number (auto-assigned if not provided)# Extract ADRs from specification
/spec-driven-development:adr-create .specs/auth/spec.md
# Create specific decision ADR
/spec-driven-development:adr-create .specs/auth/spec.md --decision "Use JWT for session tokens"
# Specify output location
/spec-driven-development:adr-create .specs/auth/spec.md --output docs/adr/
# Assign specific number
/spec-driven-development:adr-create .specs/auth/spec.md --number 42
# ADR-015: Use Redis for Session Caching
<!--
Generated from: SPEC-AUTH-001
Requirements: NFR-1 (Performance), FR-3 (Session Management)
Created: 2024-01-15
-->
## Status
Proposed
## Context
The authentication specification (SPEC-AUTH-001) requires session tokens
to be validated within 50ms (NFR-1). Current database-only approach
shows p95 latency of 150ms, exceeding the requirement.
We need a caching strategy to reduce session validation latency.
## Decision
We will use Redis as an in-memory cache for session tokens.
- Cache session data with TTL matching session expiry
- Use cache-aside pattern (lazy loading)
- Invalidate on logout and password change
## Consequences
### Positive
- Expected 80% reduction in session validation latency
- Reduced database load for session queries
- Industry-standard solution with extensive documentation
- Team has Redis experience
### Negative
- Additional infrastructure component
- Cache invalidation complexity
- Memory costs scale with active sessions
### Neutral
- Requires Redis cluster for high availability
- Monitoring and alerting setup needed
## Alternatives Considered
### In-Memory Application Cache
Local cache in each application instance.
**Pros:** No additional infrastructure
**Cons:** Not shared across instances, lost on restart
**Why Rejected:** Multi-instance deployment requires shared cache
### Database Materialized Views
Pre-computed session data in database.
**Pros:** No new technology
**Cons:** Still has database latency, complex refresh logic
**Why Rejected:** Doesn't meet 50ms latency requirement
## Related
- **Specification:** SPEC-AUTH-001
- **Requirements:** NFR-1, FR-3
- **Related ADRs:** ADR-012 (Redis Infrastructure)
When creating an ADR, the index is updated:
## ADR Index
| ADR | Title | Status | Spec | Date |
| --- | --- | --- | --- | --- |
| ADR-014 | Use PostgreSQL | Accepted | SPEC-001 | 2024-01-10 |
| ADR-015 | Use Redis for Sessions | Proposed | SPEC-AUTH | 2024-01-15 |
/spec-driven-development:specify - Generate specification/spec-driven-development:plan - Generate design/spec-driven-development:validate - Validate specification