{
  "schema": "https://ai-atoms.com/schemas/skill-v1.json",
  "type": "skill",
  "id": "skill/architecture-decision-records",
  "version": "1.0.0",
  "name": "Architecture Decision Records",
  "description": "Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architect...",
  "system_prompt_fragment": "# Architecture Decision Records\n\nComprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\n\n## Use this skill when\n\n- Making significant architectural decisions\n- Documenting technology choices\n- Recording design trade-offs\n- Onboarding new team members\n- Reviewing historical decisions\n- Establishing decision-making processes\n\n## Do not use this skill when\n\n- You only need to document small implementation details\n- The change is a minor patch or routine maintenance\n- There is no architectural decision to capture\n\n## Instructions\n\n1. Capture the decision context, constraints, and drivers.\n2. Document considered options with tradeoffs.\n3. Record the decision, rationale, and consequences.\n4. Link related ADRs and update status over time.\n\n## Core Concepts\n\n### 1. What is an ADR?\n\nAn Architecture Decision Record captures:\n- **Context**: Why we needed to make a decision\n- **Decision**: What we decided\n- **Consequences**: What happens as a result\n\n### 2. When to Write an ADR\n\n| Write ADR | Skip ADR |\n|-----------|----------|\n| New framework adoption | Minor version upgrades |\n| Database technology choice | Bug fixes |\n| API design patterns | Implementation details |\n| Security architecture | Routine maintenance |\n| Integration patterns | Configuration changes |\n\n### 3. ADR Lifecycle\n\n```\nProposed → Accepted → Deprecated → Superseded\n              ↓\n           Rejected\n```\n\n## Templates\n\n### Template 1: Standard ADR (MADR Format)\n\n```markdown\n# ADR-0001: Use PostgreSQL as Primary Database\n\n## Status\n\nAccepted\n\n## Context\n\nWe need to select a primary database for our new e-commerce platform. The system\nwill handle:\n- ~10,000 concurrent users\n- Complex product catalog with hierarchical categories\n- Transaction processing for orders and payments\n- Full-text search for products\n- Geospatial queries for store locator\n\nThe team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID\ncompliance for financial transactions.\n\n## Decision Drivers\n\n* **Must have ACID compliance** for payment processing\n* **Must support complex queries** for reporting\n* **Should support full-text search** to reduce infrastructure complexity\n* **Should have good JSON support** for flexible product attributes\n* **Team familiarity** reduces onboarding time\n\n## Considered Options\n\n### Option 1: PostgreSQL\n- **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text\n  search, PostGIS for geospatial, team has experience\n- **Cons**: Slightly more complex replication setup than MySQL\n\n### Option 2: MySQL\n- **Pros**: Very familiar to team, simple replication, large community\n- **Cons**: Weaker JSON support, no built-in full-text search (need\n  Elasticsearch), no geospatial without extensions\n\n### Option 3: MongoDB\n- **Pros**: Flexible schema, native JSON, horizontal scaling\n- **Cons**: No ACID for multi-document transactions (at decision time),\n  team has limited experience, requires schema design discipline\n\n## Decision\n\nWe will use **PostgreSQL 15** as our primary database.\n\n## Rationale\n\nPostgreSQL provides the best balance of:\n1. **ACID compliance** essential for e-commerce transactions\n2. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce\n   infrastructure complexity\n3. **Team familiarity** with SQL databases reduces learning curve\n4. **Mature ecosystem** with excellent tooling and community support\n\nThe slight complexity in replication is outweighed by the reduction in\nadditional services (no separate Elasticsearch needed).\n\n## Consequences\n\n### Positive\n- Single database handles transactions, search, and geospatial queries\n- Reduced operational complexity (fewer services to manage)\n- Strong consistency guarantees for financial data\n- Team can leverage existing SQL expertise\n\n### Negative\n- Need to learn PostgreSQL-specific features (JSONB, full-text search syntax)\n- Vertical scaling limits may require read replicas sooner\n- Some team members need PostgreSQL-specific training\n\n### Risks\n- Full-text search may not scale as well as dedicated search engines\n- Mitigation: Design for potential Elasticsearch addition if needed\n\n## Implementation Notes\n\n- Use JSONB for flexible product attributes\n- Implement connection pooling with PgBouncer\n- Set up streaming replication for read replicas\n- Use pg_trgm extension for fuzzy search\n\n## Related Decisions\n\n- ADR-0002: Caching Strategy (Redis) - complements database choice\n- ADR-0005: Search Architecture - may supersede if Elasticsearch needed\n\n## References\n\n- [PostgreSQL JSON Documentation](https://www.postgresql.org/docs/current/datatype-json.html)\n- [PostgreSQL Full Text Search](https://www.postgresql.org/docs/current/textsearch.html)\n- Internal: Performance benchmarks in `/docs/benchmarks/database-comparison.md`\n```\n\n### Template 2: Lightweight ADR\n\n```markdown\n# ADR-0012: Adopt TypeScript for Frontend Development\n\n**Status**: Accepted\n**Date**: 2024-01-15\n**Deciders**: @alice, @bob, @charlie\n\n## Context\n\nOur React codebase has grown to 50+ components with increasing bug reports\nrelated to prop type mismatches and undefined errors. PropTypes provide\nruntime-only checking.\n\n## Decision\n\nAdopt TypeScript for all new frontend code. Migrate existing code incrementally.\n\n## Consequences\n\n**Good**: Catch type errors at compile time, better IDE support, self-documenting\ncode.\n\n**Bad**: Learning curve for team, initial slowdown, build complexity increase.\n\n**Mitigations**: TypeScript training sessions, allow gradual adoption with\n`allowJs: true`.\n```\n\n### Template 3: Y-Statement Format\n\n```markdown\n# ADR-0015: API Gateway Selection\n\nIn the context of **building a microservices architecture**,\nfacing **the need for centralized API management, authentication, and rate limiting**,\nwe decided for **Kong Gateway**\nand against **AWS API Gateway and custom Nginx solution**,\nto achieve **vendor independence, plugin extensibility, and team familiarity with Lua**,\naccepting that **we need to manage Kong infrastructure ourselves**.\n```\n\n### Template 4: ADR for Deprecation\n\n```markdown\n# ADR-0020: Deprecate MongoDB in Favor of PostgreSQL\n\n## Status\n\nAccepted (Supersedes ADR-0003)\n\n## Context\n\nADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility\nneeds. Since then:\n- MongoDB's multi-document transactions remain problematic for our use case\n- Our schema has stabilized and rarely changes\n- We now have PostgreSQL expertise from other services\n- Maintaining two databases increases operational burden\n\n## Decision\n\nDeprecate MongoDB and migrate user profiles to PostgreSQL.\n\n## Migration Plan\n\n1. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled\n2. **Phase 2** (Week 3-4): Backfill historical data, validate consistency\n3. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor\n4. **Phase 4** (Week 6): Remove MongoDB writes, decommission\n\n## Consequences\n\n### Positive\n- Single database technology reduces operational complexity\n- ACID transactions for user data\n- Team can focus PostgreSQL expertise\n\n### Negative\n- Migration effort (~4 weeks)\n- Risk of data issues during migration\n- Lose some schema flexibility\n\n## Lessons Learned\n\nDocument from ADR-0003 experience:\n- Schema flexibility benefits were overestimated\n- Operational cost of multiple databases was underestimated\n- Consider long-term maintenance in technology decisions\n```\n\n### Template 5: Request for Comments (RFC) Style\n\n```markdown\n# RFC-0025: Adopt Event Sourcing for Order Management\n\n## Summary\n\nPropose adopting event sourcing pattern for the order management domain to\nimprove auditability, enable temporal queries, and support business analytics.\n\n## Motivation\n\nCurrent challenges:\n1. Audit requirements need complete order history\n2. \"What was the order state at time X?\" queries are impossible\n3. Analytics team needs event stream for real-time dashboards\n4. Order state reconstruction for customer support is manual\n\n## Detailed Design\n\n### Event Store\n\n```\nOrderCreated { orderId, customerId, items[], timestamp }\nOrderItemAdded { orderId, item, timestamp }\nOrderItemRemoved { orderId, itemId, timestamp }\nPaymentReceived { orderId, amount, paymentId, timestamp }\nOrderShipped { orderId, trackingNumber, timestamp }\n```\n\n### Projections\n\n- **CurrentOrderState**: Materialized view for queries\n- **OrderHistory**: Complete timeline for audit\n- **DailyOrderMetrics**: Analytics aggregation\n\n### Technology\n\n- Event Store: EventStoreDB (purpose-built, handles projections)\n- Alternative considered: Kafka + custom projection service\n\n## Drawbacks\n\n- Learning curve for team\n- Increased complexity vs. CRUD\n- Need to design events carefully (immutable once stored)\n- Storage growth (events never deleted)\n\n## Alternatives\n\n1. **Audit tables**: Simpler but doesn't enable temporal queries\n2. **CDC from existing DB**: Complex, doesn't change data model\n3. **Hybrid**: Event source only for order state changes\n\n## Unresolved Questions\n\n- [ ] Event schema versioning strategy\n- [ ] Retention policy for events\n- [ ] Snapshot frequency for performance\n\n## Implementation Plan\n\n1. Prototype with single order type (2 weeks)\n2. Team training on event sourcing (1 week)\n3. Full implementation and migration (4 weeks)\n4. Monitoring and optimization (ongoing)\n\n## References\n\n- [Event Sourcing by Martin Fowler](https://martinfowler.com/eaaDev/EventSourcing.html)\n- [EventStoreDB Documentation](https://www.eventstore.com/docs)\n```\n\n## ADR Management\n\n### Directory Structure\n\n```\ndocs/\n├── adr/\n│   ├── README.md           # Index and guidelines\n│   ├── template.md         # Team's ADR template\n│   ├── 0001-use-postgresql.md\n│   ├── 0002-caching-strategy.md\n│   ├── 0003-mongodb-user-profiles.md  # [DEPRECATED]\n│   └── 0020-deprecate-mongodb.md      # Supersedes 0003\n```\n\n### ADR Index (README.md)\n\n```markdown\n# Architecture Decision Records\n\nThis directory contains Architecture Decision Records (ADRs) for [Project Name].\n\n## Index\n\n| ADR | Title | Status | Date |\n|-----|-------|--------|------|\n| 0001 | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |\n| 0002 | Caching Strategy with Redis | Accepted | 2024-01-12 |\n| 0003 | MongoDB for User Profiles | Deprecated | 2023-06-15 |\n| 0020 | Deprecate MongoDB | Accepted | 2024-01-15 |\n\n## Creating a New ADR\n\n1. Copy `template.md` to `NNNN-title-with-dashes.md`\n2. Fill in the template\n3. Submit PR for review\n4. Update this index after approval\n\n## ADR Status\n\n- **Proposed**: Under discussion\n- **Accepted**: Decision made, implementing\n- **Deprecated**: No longer relevant\n- **Superseded**: Replaced by another ADR\n- **Rejected**: Considered but not adopted\n```\n\n### Automation (adr-tools)\n\n```bash\n# Install adr-tools\nbrew install adr-tools\n\n# Initialize ADR directory\nadr init docs/adr\n\n# Create new ADR\nadr new \"Use PostgreSQL as Primary Database\"\n\n# Supersede an ADR\nadr new -s 3 \"Deprecate MongoDB in Favor of PostgreSQL\"\n\n# Generate table of contents\nadr generate toc > docs/adr/README.md\n\n# Link related ADRs\nadr link 2 \"Complements\" 1 \"Is complemented by\"\n```\n\n## Review Process\n\n```markdown\n## ADR Review Checklist\n\n### Before Submission\n- [ ] Context clearly explains the problem\n- [ ] All viable options considered\n- [ ] Pros/cons balanced and honest\n- [ ] Consequences (positive and negative) documented\n- [ ] Related ADRs linked\n\n### During Review\n- [ ] At least 2 senior engineers reviewed\n- [ ] Affected teams consulted\n- [ ] Security implications considered\n- [ ] Cost implications documented\n- [ ] Reversibility assessed\n\n### After Acceptance\n- [ ] ADR index updated\n- [ ] Team notified\n- [ ] Implementation tickets created\n- [ ] Related documentation updated\n```\n\n## Best Practices\n\n### Do's\n- **Write ADRs early** - Before implementation starts\n- **Keep them short** - 1-2 pages maximum\n- **Be honest about trade-offs** - Include real cons\n- **Link related decisions** - Build decision graph\n- **Update status** - Deprecate when superseded\n\n### Don'ts\n- **Don't change accepted ADRs** - Write new ones to supersede\n- **Don't skip context** - Future readers need background\n- **Don't hide failures** - Rejected decisions are valuable\n- **Don't be vague** - Specific decisions, specific consequences\n- **Don't forget implementation** - ADR without action is waste\n\n## Resources\n\n- [Documenting Architecture Decisions (Michael Nygard)](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)\n- [MADR Template](https://adr.github.io/madr/)\n- [ADR GitHub Organization](https://adr.github.io/)\n- [adr-tools](https://github.com/npryce/adr-tools)",
  "applicable_domains": [
    "other"
  ],
  "category": "other",
  "invocation": [
    "/architecture-decision-records"
  ],
  "authored_by": "claudeskills.in community",
  "source_url": "https://claudeskills.in/skill/architecture-decision-records",
  "provenance": {
    "source": "claudeskills.in",
    "source_url": "https://claudeskills.in/skill/architecture-decision-records",
    "license": "unknown",
    "imported_at": "2026-09-03",
    "notes": "Aggregated by claudeskills.in from community GitHub lists."
  },
  "tags": [
    "claudeskills",
    "other"
  ],
  "lifecycle": "draft"
}