Create Architecture Decision Records (ADRs) documenting key architectural choices. Analyzes context, evaluates alternatives, and captures decisions using standard ADR template. Use when documenting database design, technology selection, pattern choices, or architectural trade-offs.
Create Architecture Decision Records (ADRs) documenting key architectural choices. Analyzes context, evaluates alternatives, and captures decisions using standard ADR template. Use when documenting database design, technology selection, pattern choices, or architectural trade-offs.
acceptance
[{"adr_complete":"ADR document created with all required sections"},{"alternatives_analyzed":"At least 2 alternatives evaluated with pros/cons"},{"rationale_clear":"Decision rationale clearly explained"},{"consequences_documented":"Positive and negative consequences identified"}]
inputs
{"context":{"type":"string","required":true,"description":"Decision context (e.g., file path to analyze, or description of decision)","validation":"Must describe what decision needs to be made or what to analyze"},"decision_number":{"type":"number","required":false,"description":"ADR number (auto-incremented if not provided)"}}
outputs
{"adr_created":{"type":"boolean","description":"Whether ADR was successfully created"},"adr_path":{"type":"string","description":"Path to created ADR file"},"decision_number":{"type":"number","description":"ADR number assigned"}}
Create comprehensive Architecture Decision Records following industry best practices. ADRs document architectural choices, alternatives considered, rationale, and consequences to provide context for future development.
ADR Structure:
Context: Problem and constraints
Decision: What was decided
Alternatives: Options evaluated with pros/cons
Rationale: Why this decision was made
Consequences: Positive, negative, and neutral impacts
Prerequisites
docs/adrs/ directory (created if missing)
Context for decision (file to analyze, problem description, or existing architecture)
Workflow
Step 0: Determine ADR Number
Action: Find next available ADR number.
# List existing ADRsls -la docs/adrs/ 2>/dev/null || echo"ADR directory does not exist"# Find highest number
find docs/adrs/ -name "adr-*.md" 2>/dev/null | \
sed 's/.*adr-\([0-9]*\)-.*/\1/' | \
sort -n | \
tail -1
Calculate next number:
If no ADRs exist: Start at 001
If ADRs exist: Increment highest by 1
Create ADR directory if missing:
mkdir -p docs/adrs
Step 1: Analyze Context
Action: Understand what decision needs to be documented.
Context Types:
1. File/Schema Analysis (like Prisma schema):
# Read the file to analyze
Read(file_path: {context_path})
Analyze to identify:
Technology choices: Database, ORM, patterns used
Data modeling decisions: Schema structure, relationships
Architectural patterns: Multi-tenancy, event sourcing, etc.
Design tradeoffs: Normalization vs. denormalization, indexing strategies
2. Technology Selection:
List technologies being compared
Identify requirements driving selection
Note constraints (team skills, budget, timeline)
3. Pattern Adoption:
Describe pattern being adopted
Explain problem it solves
Note implementation approach
Step 2: Identify Key Decisions
Action: Extract architectural decisions from context.
For Schema/File Analysis:
Scan for decision indicators:
# ADR-001: PostgreSQL Database with Prisma ORM**Date:** 2025-11-05
**Status:** Accepted
**Deciders:** Backend Team
## Context
Need database for multi-tenant SaaS application managing hotels, conversations, and analytics. Requirements:
- Relational data (hotels → users → conversations → messages)
- ACID transactions (billing, user management)
- Full-text search
- Multi-tenancy via hotelId
- TypeScript integration
## Decision
Use **PostgreSQL** with **Prisma ORM** for database layer.
[... rest of ADR with alternatives, rationale, consequences ...]
Example 2: Technology Selection
Input:context: "Choose state management for React app"
Output ADR:
# ADR-002: State Management Strategy**Date:** 2025-11-05
**Status:** Accepted
## Context
React application needs client state management for:
- User authentication state
- Global UI state (theme, modals)
- Form state (multi-step wizards)
[... alternatives: Zustand, Redux, Context ...]
Using This Skill
From Winston subagent:
/winston *create-adr "packages/backend/src/schema.prisma"
/winston *create-adr "Choose between REST and GraphQL"
Directly:
Use create-adr skill with context: "Analyze authentication strategy in src/auth/"
Philosophy
ADRs are living documentation that:
Preserve context for future developers
Document tradeoffs honestly
Explain "why" not just "what"
Guide future decisions through patterns
Good ADRs prevent "why did we do this?" questions 6 months later.