[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEBTVYT4PTSX8VBFHSCBKN":3,"skill-same:01M6AEBTVYT4PTSX8VBFHSCBKN":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6AEBTVYT4PTSX8VBFHSCBKN","architecture-decision-records",null,"Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.","davila7\u002Fclaude-code-templates","davila7","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6216945?v=4","01M6ADEWWFPS191NFM0Y1EX1JH","Daniel Avila","01M6ADJHGM78PHQRD3XZTFDVKK",33481,"MIT","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Farchitecture-decision-records\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"architecture","architecture decision records","decision","records","architecture decision","technical","capture","decisions","context","community","patterns","for","unknown","rationale","2026","2026-11-10 10:12:30",false,"---\nname: architecture-decision-records\ndescription: \"Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\"\nmetadata:\n  risk: unknown\n  source: community\n  date_added: \"2026-02-27\"\n---\n\n# 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:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fdatatype-json.html)\n- [PostgreSQL Full Text Search](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Ftextsearch.html)\n- Internal: Performance benchmarks in `\u002Fdocs\u002Fbenchmarks\u002Fdatabase-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:\u002F\u002Fmartinfowler.com\u002FeaaDev\u002FEventSourcing.html)\n- [EventStoreDB Documentation](https:\u002F\u002Fwww.eventstore.com\u002Fdocs)\n```\n\n## ADR Management\n\n### Directory Structure\n\n```\ndocs\u002F\n├── adr\u002F\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\u002Fadr\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\u002Fadr\u002FREADME.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\u002Fcons 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:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions)\n- [MADR Template](https:\u002F\u002Fadr.github.io\u002Fmadr\u002F)\n- [ADR GitHub Organization](https:\u002F\u002Fadr.github.io\u002F)\n- [adr-tools](https:\u002F\u002Fgithub.com\u002Fnpryce\u002Fadr-tools)\n","# 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:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fdatatype-json.html)\n- [PostgreSQL Full Text Search](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Ftextsearch.html)\n- Internal: Performance benchmarks in `\u002Fdocs\u002Fbenchmarks\u002Fdatabase-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:\u002F\u002Fmartinfowler.com\u002FeaaDev\u002FEventSourcing.html)\n- [EventStoreDB Documentation](https:\u002F\u002Fwww.eventstore.com\u002Fdocs)\n```\n\n## ADR Management\n\n### Directory Structure\n\n```\ndocs\u002F\n├── adr\u002F\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\u002Fadr\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\u002Fadr\u002FREADME.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\u002Fcons 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:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions)\n- [MADR Template](https:\u002F\u002Fadr.github.io\u002Fmadr\u002F)\n- [ADR GitHub Organization](https:\u002F\u002Fadr.github.io\u002F)\n- [adr-tools](https:\u002F\u002Fgithub.com\u002Fnpryce\u002Fadr-tools)\n",{"name":5,"metadata":44,"description":7},{"risk":36,"source":33,"date_added":45},"2026-02-27","main","2b749c82b5d11fac39d9a6e021ce3f5b8a541bd1","cli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Farchitecture-decision-records",3931,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates","https:\u002F\u002Faitmpl.com","https:\u002F\u002Fgithub.com\u002Fdavila7","https:\u002F\u002Fdanielavila.me","Building AI dev tools with LLMs","2026-11-14 06:14:46",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add davila7\u002Fclaude-code-templates --skill architecture-decision-records",{"tool":62,"command":63},"bunx","bunx skills add davila7\u002Fclaude-code-templates --skill architecture-decision-records",{"tool":65,"command":66},"pnpm","pnpm dlx skills add davila7\u002Fclaude-code-templates --skill architecture-decision-records","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Farchitecture-decision-records\u002FSKILL.md",true,[],[71,98,124,157,192,216],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":78,"publishedAt":39},"01M70NHBTQ8BV0A2SCAZXEPHCX","wealthville-pool-scoring","Score DeFi liquidity pools before providing liquidity. Returns a 0-100 pool score and an Enter\u002FHold\u002FExit\u002FReduce\u002FAvoid verdict with calibrated confidence for ~68,800 Solana pools and 575 EVM pools, plus a public miss-inclusive track record. Use when asked whether a pool is worth LPing into, which pools look best right now, or how accurate the scores have actually been.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fweb-data\u002Fwealthville-pool-scoring\u002FSKILL.md",[77],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[79,80,81,82,83,35,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"scoring","pool","wealthville pool scoring","liquidity","which","exit","now","use","when","reduce","with","record","track","verdict","evm","solana","how","public","look",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":105,"publishedAt":39},"01M70MB6VR8ERJ4EM8D5KHBMEV","technical-debt-auditor","Scans a codebase and produces a quantified technical debt report with a prioritized remediation plan. Analyzes dead code, TODO\u002FFIXME\u002FHACK markers, dependency staleness, complexity hotspots, code duplication signals, test coverage gaps, unused exports, and outdated patterns. Use this skill when the user asks to audit their codebase for tech debt, wants a health check of their code quality, says things like \"where should I focus refactoring\", \"find code smells\", \"audit my codebase\", \"what technical debt do we have\", \"prioritize cleanup work\", or asks about code quality metrics. Also trigger when the user mentions \"code rot\", \"legacy cleanup\", \"refactoring priorities\", or wants to understand the overall health of a project before a major effort. Trigger even if the user doesn't say \"technical debt\" explicitly — any request to systematically assess code quality and identify improvement priorities belongs here.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Ftechnical-debt-auditor\u002FSKILL.md",[104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[106,107,29,108,109,110,111,112,113,114,115,87,116,117,118,119,120,121,122,123],"technical debt","debt","technical debt auditor","auditor","coverage","complexity","markers","project","cleanup","unused","code","todo","work","plan","focus","signals","audit","dependency",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":139,"publishedAt":39},"01M70KPYH9QNHCNME5GJQGE22K","readonly-sql-guard","Make an agent's database access provably read-only. Use when an agent runs caller-supplied SQL against a production\u002FERP\u002Fanalytics database (a \"query\" MCP tool, text-to-SQL, an admin console), or when reviewing DB-access code for write\u002FDDL\u002Fside-effect\u002Ftransaction-escape risks. Checks what a statement CALLS, not just its shape.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdatabase\u002Freadonly-sql-guard\u002FSKILL.md",[130,133,134],{"categoryNo":131,"categoryName":132,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[140,141,142,143,144,145,146,35,147,148,149,150,151,152,153,86,154,155,87,156],"readonly","guard","sql guard","sql","readonly sql guard","erp","effect","read-only","db","just","tool","calls","only","MCP","access","database","query",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":161,"licenseFileUrl":162,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":39},"01M6AFY6F7CC2BBZP1QD6VTNVC","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,35,191],"artifacts builder","web","web artifacts builder","artifacts","builder","state","routing","state management","component","css","frontend","ui","Tools","file","components","shadcn","react","Tailwind","suite","jsx","html","single-file","ui components",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":161,"licenseFileUrl":196,"sourceHtmlUrl":197,"categories":198,"keywords":203,"publishedAt":39},"01M6AFWF33SFV9Z3SF4PEEE4BF","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FSKILL.md",[199,202],{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},[204,205,206,207,208,170,209,179,180,210,211,212,213,35,214,89,215],"webapp testing","testing","webapp","browser","playwright","applications","debugging","toolkit","logs","screenshots","local","behavior",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":161,"licenseFileUrl":220,"sourceHtmlUrl":221,"categories":222,"keywords":230,"publishedAt":39},"01M6AF67Q67JJJ5V51JR2P52KA","discernment-nudge","After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FSKILL.md",[223,226,227],{"categoryNo":224,"categoryName":225,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":228,"categoryName":229,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000036","内容创作者",[231,232,233,234,235,236,237,238,172,239,182,116,240,241,242,243,244,152,245,87,246,247,248,249,250,95,251],"discernment nudge","nudge","interpretation","help","run","reasoning","data","writing","lookup","content","review","conversation","short","up","invoke","you","analysis","claims","argument","assemble","recommendations"]