Architecture Decision Records
Unverified●30/40Claude Code◐PartialHas SKILL.md but declares no allowed-tools — Claude Code will ask for permission each time
Cursor·UnknownWe have not crawled the repo tree, so we will not guess
Codex·UnknownWe have not crawled the repo tree, so we will not guess
Gemini CLI·UnknownThe spec defines no detection rule for Gemini
Copilot·UnknownWe have not crawled the repo tree, so we will not guess
npx agentalley add architecture-decision-recordsWho is stuck, and on what
Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
The whole source
Frontmatter — 2 properties
| 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 architectural choices, or establishing decision processes. |
| 1 | --- |
| 2 | name: architecture-decision-records |
| 3 | description: Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes. |
| 4 | ---A5 — No allowed-tools declared — no way to tell what this skill may touch |
| 5 | |
| 6 | # Architecture Decision Records |
| 7 | |
| 8 | Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions. |
| 9 | |
| 10 | ## When to Use This Skill |
| 11 | |
| 12 | - Making significant architectural decisions |
| 13 | - Documenting technology choices |
| 14 | - Recording design trade-offs |
| 15 | - Onboarding new team members |
| 16 | - Reviewing historical decisions |
| 17 | - Establishing decision-making processes |
| 18 | |
| 19 | ## Core Concepts |
| 20 | |
| 21 | ### 1. What is an ADR? |
| 22 | |
| 23 | An Architecture Decision Record captures: |
| 24 | |
| 25 | - **Context**: Why we needed to make a decision |
| 26 | - **Decision**: What we decided |
| 27 | - **Consequences**: What happens as a result |
| 28 | |
| 29 | ### 2. When to Write an ADR |
| 30 | |
| 31 | | Write ADR | Skip ADR | |
| 32 | | -------------------------- | ---------------------- | |
| 33 | | New framework adoption | Minor version upgrades | |
| 34 | | Database technology choice | Bug fixes | |
| 35 | | API design patterns | Implementation details | |
| 36 | | Security architecture | Routine maintenance | |
| 37 | | Integration patterns | Configuration changes | |
| 38 | |
| 39 | ### 3. ADR Lifecycle |
| 40 | |
| 41 | ``` |
| 42 | Proposed → Accepted → Deprecated → Superseded |
| 43 | ↓ |
| 44 | Rejected |
| 45 | ``` |
| 46 | |
| 47 | ## Templates |
| 48 | |
| 49 | ### Template 1: Standard ADR (MADR Format) |
| 50 | |
| 51 | ```markdown |
| 52 | # ADR-0001: Use PostgreSQL as Primary Database |
| 53 | |
| 54 | ## Status |
| 55 | |
| 56 | Accepted |
| 57 | |
| 58 | ## Context |
| 59 | |
| 60 | We need to select a primary database for our new e-commerce platform. The system |
| 61 | will handle: |
| 62 | |
| 63 | - ~10,000 concurrent users |
| 64 | - Complex product catalog with hierarchical categories |
| 65 | - Transaction processing for orders and payments |
| 66 | - Full-text search for products |
| 67 | - Geospatial queries for store locator |
| 68 | |
| 69 | The team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID |
| 70 | compliance for financial transactions. |
| 71 | |
| 72 | ## Decision Drivers |
| 73 | |
| 74 | - **Must have ACID compliance** for payment processing |
| 75 | - **Must support complex queries** for reporting |
| 76 | - **Should support full-text search** to reduce infrastructure complexity |
| 77 | - **Should have good JSON support** for flexible product attributes |
| 78 | - **Team familiarity** reduces onboarding time |
| 79 | |
| 80 | ## Considered Options |
| 81 | |
| 82 | ### Option 1: PostgreSQL |
| 83 | |
| 84 | - **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text |
| 85 | search, PostGIS for geospatial, team has experience |
| 86 | - **Cons**: Slightly more complex replication setup than MySQL |
| 87 | |
| 88 | ### Option 2: MySQL |
| 89 | |
| 90 | - **Pros**: Very familiar to team, simple replication, large community |
| 91 | - **Cons**: Weaker JSON support, no built-in full-text search (need |
| 92 | Elasticsearch), no geospatial without extensions |
| 93 | |
| 94 | ### Option 3: MongoDB |
| 95 | |
| 96 | - **Pros**: Flexible schema, native JSON, horizontal scaling |
| 97 | - **Cons**: No ACID for multi-document transactions (at decision time), |
| 98 | team has limited experience, requires schema design discipline |
| 99 | |
| 100 | ## Decision |
| 101 | |
| 102 | We will use **PostgreSQL 15** as our primary database. |
| 103 | |
| 104 | ## Rationale |
| 105 | |
| 106 | PostgreSQL provides the best balance of: |
| 107 | |
| 108 | 1. **ACID compliance** essential for e-commerce transactions |
| 109 | 2. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce |
| 110 | infrastructure complexity |
| 111 | 3. **Team familiarity** with SQL databases reduces learning curve |
| 112 | 4. **Mature ecosystem** with excellent tooling and community support |
| 113 | |
| 114 | The slight complexity in replication is outweighed by the reduction in |
| 115 | additional services (no separate Elasticsearch needed). |
| 116 | |
| 117 | ## Consequences |
| 118 | |
| 119 | ### Positive |
| 120 | |
| 121 | - Single database handles transactions, search, and geospatial queries |
| 122 | - Reduced operational complexity (fewer services to manage) |
| 123 | - Strong consistency guarantees for financial data |
| 124 | - Team can leverage existing SQL expertise |
| 125 | |
| 126 | ### Negative |
| 127 | |
| 128 | - Need to learn PostgreSQL-specific features (JSONB, full-text search syntax) |
| 129 | - Vertical scaling limits may require read replicas sooner |
| 130 | - Some team members need PostgreSQL-specific training |
| 131 | |
| 132 | ### Risks |
| 133 | |
| 134 | - Full-text search may not scale as well as dedicated search engines |
| 135 | - Mitigation: Design for potential Elasticsearch addition if needed |
| 136 | |
| 137 | ## Implementation Notes |
| 138 | |
| 139 | - Use JSONB for flexible product attributes |
| 140 | - Implement connection pooling with PgBouncer |
| 141 | - Set up streaming replication for read replicas |
| 142 | - Use pg_trgm extension for fuzzy search |
| 143 | |
| 144 | ## Related Decisions |
| 145 | |
| 146 | - ADR-0002: Caching Strategy (Redis) - complements database choice |
| 147 | - ADR-0005: Search Architecture - may supersede if Elasticsearch needed |
| 148 | |
| 149 | ## References |
| 150 | |
| 151 | - [PostgreSQL JSON Documentation](https://www.postgresql.org/docs/current/datatype-json.html) |
| 152 | - [PostgreSQL Full Text Search](https://www.postgresql.org/docs/current/textsearch.html) |
| 153 | - Internal: Performance benchmarks in `/docs/benchmarks/database-comparison.md` |
| 154 | ``` |
| 155 | |
| 156 | ### Template 2: Lightweight ADR |
| 157 | |
| 158 | ```markdown |
| 159 | # ADR-0012: Adopt TypeScript for Frontend Development |
| 160 | |
| 161 | **Status**: Accepted |
| 162 | **Date**: 2024-01-15 |
| 163 | **Deciders**: @alice, @bob, @charlie |
| 164 | |
| 165 | ## Context |
| 166 | |
| 167 | Our React codebase has grown to 50+ components with increasing bug reports |
| 168 | related to prop type mismatches and undefined errors. PropTypes provide |
| 169 | runtime-only checking. |
| 170 | |
| 171 | ## Decision |
| 172 | |
| 173 | Adopt TypeScript for all new frontend code. Migrate existing code incrementally. |
| 174 | |
| 175 | ## Consequences |
| 176 | |
| 177 | **Good**: Catch type errors at compile time, better IDE support, self-documenting |
| 178 | code. |
| 179 | |
| 180 | **Bad**: Learning curve for team, initial slowdown, build complexity increase. |
| 181 | |
| 182 | **Mitigations**: TypeScript training sessions, allow gradual adoption with |
| 183 | `allowJs: true`. |
| 184 | ``` |
| 185 | |
| 186 | ### Template 3: Y-Statement Format |
| 187 | |
| 188 | ```markdown |
| 189 | # ADR-0015: API Gateway Selection |
| 190 | |
| 191 | In the context of **building a microservices architecture**, |
| 192 | facing **the need for centralized API management, authentication, and rate limiting**, |
| 193 | we decided for **Kong Gateway** |
| 194 | and against **AWS API Gateway and custom Nginx solution**, |
| 195 | to achieve **vendor independence, plugin extensibility, and team familiarity with Lua**, |
| 196 | accepting that **we need to manage Kong infrastructure ourselves**. |
| 197 | ``` |
| 198 | |
| 199 | ### Template 4: ADR for Deprecation |
| 200 | |
| 201 | ```markdown |
| 202 | # ADR-0020: Deprecate MongoDB in Favor of PostgreSQL |
| 203 | |
| 204 | ## Status |
| 205 | |
| 206 | Accepted (Supersedes ADR-0003) |
| 207 | |
| 208 | ## Context |
| 209 | |
| 210 | ADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility |
| 211 | needs. Since then: |
| 212 | |
| 213 | - MongoDB's multi-document transactions remain problematic for our use case |
| 214 | - Our schema has stabilized and rarely changes |
| 215 | - We now have PostgreSQL expertise from other services |
| 216 | - Maintaining two databases increases operational burden |
| 217 | |
| 218 | ## Decision |
| 219 | |
| 220 | Deprecate MongoDB and migrate user profiles to PostgreSQL. |
| 221 | |
| 222 | ## Migration Plan |
| 223 | |
| 224 | 1. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled |
| 225 | 2. **Phase 2** (Week 3-4): Backfill historical data, validate consistency |
| 226 | 3. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor |
| 227 | 4. **Phase 4** (Week 6): Remove MongoDB writes, decommission |
| 228 | |
| 229 | ## Consequences |
| 230 | |
| 231 | ### Positive |
| 232 | |
| 233 | - Single database technology reduces operational complexity |
| 234 | - ACID transactions for user data |
| 235 | - Team can focus PostgreSQL expertise |
| 236 | |
| 237 | ### Negative |
| 238 | |
| 239 | - Migration effort (~4 weeks) |
| 240 | - Risk of data issues during migration |
| 241 | - Lose some schema flexibility |
| 242 | |
| 243 | ## Lessons Learned |
| 244 | |
| 245 | Document from ADR-0003 experience: |
| 246 | |
| 247 | - Schema flexibility benefits were overestimated |
| 248 | - Operational cost of multiple databases was underestimated |
| 249 | - Consider long-term maintenance in technology decisions |
| 250 | ``` |
| 251 | |
| 252 | ### Template 5: Request for Comments (RFC) Style |
| 253 | |
| 254 | ```markdown |
| 255 | # RFC-0025: Adopt Event Sourcing for Order Management |
| 256 | |
| 257 | ## Summary |
| 258 | |
| 259 | Propose adopting event sourcing pattern for the order management domain to |
| 260 | improve auditability, enable temporal queries, and support business analytics. |
| 261 | |
| 262 | ## Motivation |
| 263 | |
| 264 | Current challenges: |
| 265 | |
| 266 | 1. Audit requirements need complete order history |
| 267 | 2. "What was the order state at time X?" queries are impossible |
| 268 | 3. Analytics team needs event stream for real-time dashboards |
| 269 | 4. Order state reconstruction for customer support is manual |
| 270 | |
| 271 | ## Detailed Design |
| 272 | |
| 273 | ### Event Store |
| 274 | ``` |
| 275 | |
| 276 | OrderCreated { orderId, customerId, items[], timestamp } |
| 277 | OrderItemAdded { orderId, item, timestamp } |
| 278 | OrderItemRemoved { orderId, itemId, timestamp } |
| 279 | PaymentReceived { orderId, amount, paymentId, timestamp } |
| 280 | OrderShipped { orderId, trackingNumber, timestamp } |
| 281 | |
| 282 | ``` |
| 283 | |
| 284 | ### Projections |
| 285 | |
| 286 | - **CurrentOrderState**: Materialized view for queries |
| 287 | - **OrderHistory**: Complete timeline for audit |
| 288 | - **DailyOrderMetrics**: Analytics aggregation |
| 289 | |
| 290 | ### Technology |
| 291 | |
| 292 | - Event Store: EventStoreDB (purpose-built, handles projections) |
| 293 | - Alternative considered: Kafka + custom projection service |
| 294 | |
| 295 | ## Drawbacks |
| 296 | |
| 297 | - Learning curve for team |
| 298 | - Increased complexity vs. CRUD |
| 299 | - Need to design events carefully (immutable once stored) |
| 300 | - Storage growth (events never deleted) |
| 301 | |
| 302 | ## Alternatives |
| 303 | |
| 304 | 1. **Audit tables**: Simpler but doesn't enable temporal queries |
| 305 | 2. **CDC from existing DB**: Complex, doesn't change data model |
| 306 | 3. **Hybrid**: Event source only for order state changes |
| 307 | |
| 308 | ## Unresolved Questions |
| 309 | |
| 310 | - [ ] Event schema versioning strategy |
| 311 | - [ ] Retention policy for events |
| 312 | - [ ] Snapshot frequency for performance |
| 313 | |
| 314 | ## Implementation Plan |
| 315 | |
| 316 | 1. Prototype with single order type (2 weeks) |
| 317 | 2. Team training on event sourcing (1 week) |
| 318 | 3. Full implementation and migration (4 weeks) |
| 319 | 4. Monitoring and optimization (ongoing) |
| 320 | |
| 321 | ## References |
| 322 | |
| 323 | - [Event Sourcing by Martin Fowler](https://martinfowler.com/eaaDev/EventSourcing.html) |
| 324 | - [EventStoreDB Documentation](https://www.eventstore.com/docs) |
| 325 | ``` |
| 326 | |
| 327 | ## ADR Management |
| 328 | |
| 329 | ### Directory Structure |
| 330 | |
| 331 | ``` |
| 332 | docs/ |
| 333 | ├── adr/ |
| 334 | │ ├── README.md # Index and guidelines |
| 335 | │ ├── template.md # Team's ADR template |
| 336 | │ ├── 0001-use-postgresql.md |
| 337 | │ ├── 0002-caching-strategy.md |
| 338 | │ ├── 0003-mongodb-user-profiles.md # [DEPRECATED] |
| 339 | │ └── 0020-deprecate-mongodb.md # Supersedes 0003 |
| 340 | ``` |
| 341 | |
| 342 | ### ADR Index (README.md) |
| 343 | |
| 344 | ```markdown |
| 345 | # Architecture Decision Records |
| 346 | |
| 347 | This directory contains Architecture Decision Records (ADRs) for [Project Name]. |
| 348 | |
| 349 | ## Index |
| 350 | |
| 351 | | ADR | Title | Status | Date | |
| 352 | | ------------------------------------- | ---------------------------------- | ---------- | ---------- | |
| 353 | | [0001](0001-use-postgresql.md) | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 | |
| 354 | | [0002](0002-caching-strategy.md) | Caching Strategy with Redis | Accepted | 2024-01-12 | |
| 355 | | [0003](0003-mongodb-user-profiles.md) | MongoDB for User Profiles | Deprecated | 2023-06-15 | |
| 356 | | [0020](0020-deprecate-mongodb.md) | Deprecate MongoDB | Accepted | 2024-01-15 | |
| 357 | |
| 358 | ## Creating a New ADR |
| 359 | |
| 360 | 1. Copy `template.md` to `NNNN-title-with-dashes.md` |
| 361 | 2. Fill in the template |
| 362 | 3. Submit PR for review |
| 363 | 4. Update this index after approval |
| 364 | |
| 365 | ## ADR Status |
| 366 | |
| 367 | - **Proposed**: Under discussion |
| 368 | - **Accepted**: Decision made, implementing |
| 369 | - **Deprecated**: No longer relevant |
| 370 | - **Superseded**: Replaced by another ADR |
| 371 | - **Rejected**: Considered but not adopted |
| 372 | ``` |
| 373 | |
| 374 | ### Automation (adr-tools) |
| 375 | |
| 376 | ```bash |
| 377 | # Install adr-tools |
| 378 | brew install adr-tools |
| 379 | |
| 380 | # Initialize ADR directory |
| 381 | adr init docs/adr |
| 382 | |
| 383 | # Create new ADR |
| 384 | adr new "Use PostgreSQL as Primary Database" |
| 385 | |
| 386 | # Supersede an ADR |
| 387 | adr new -s 3 "Deprecate MongoDB in Favor of PostgreSQL" |
| 388 | |
| 389 | # Generate table of contents |
| 390 | adr generate toc > docs/adr/README.md |
| 391 | |
| 392 | # Link related ADRs |
| 393 | adr link 2 "Complements" 1 "Is complemented by" |
| 394 | ``` |
| 395 | |
| 396 | ## Review Process |
| 397 | |
| 398 | ```markdown |
| 399 | ## ADR Review Checklist |
| 400 | |
| 401 | ### Before Submission |
| 402 | |
| 403 | - [ ] Context clearly explains the problem |
| 404 | - [ ] All viable options considered |
| 405 | - [ ] Pros/cons balanced and honest |
| 406 | - [ ] Consequences (positive and negative) documented |
| 407 | - [ ] Related ADRs linked |
| 408 | |
| 409 | ### During Review |
| 410 | |
| 411 | - [ ] At least 2 senior engineers reviewed |
| 412 | - [ ] Affected teams consulted |
| 413 | - [ ] Security implications considered |
| 414 | - [ ] Cost implications documented |
| 415 | - [ ] Reversibility assessed |
| 416 | |
| 417 | ### After Acceptance |
| 418 | |
| 419 | - [ ] ADR index updated |
| 420 | - [ ] Team notified |
| 421 | - [ ] Implementation tickets created |
| 422 | - [ ] Related documentation updated |
| 423 | ``` |
| 424 | |
| 425 | ## Best Practices |
| 426 | |
| 427 | ### Do's |
| 428 | |
| 429 | - **Write ADRs early** - Before implementation starts |
| 430 | - **Keep them short** - 1-2 pages maximum |
| 431 | - **Be honest about trade-offs** - Include real cons |
| 432 | - **Link related decisions** - Build decision graph |
| 433 | - **Update status** - Deprecate when superseded |
| 434 | |
| 435 | ### Don'ts |
| 436 | |
| 437 | - **Don't change accepted ADRs** - Write new ones to supersede |
| 438 | - **Don't skip context** - Future readers need background |
| 439 | - **Don't hide failures** - Rejected decisions are valuable |
| 440 | - **Don't be vague** - Specific decisions, specific consequences |
| 441 | - **Don't forget implementation** - ADR without action is waste |
| 442 |
Reviews
Installed this one?Write the first review and take the Trailblazer badge.
Alternatives
Research Review via External Reviewer Backend (ultra reasoning)Get a deep critical review of research from an external reviewer backend (Codex or manual). Use when user says "review my research", "help me review", "get external review", or wants critical feedback on research ideas, papers, or experimental results.●····●38/40Training CheckPeriodically check WandB metrics during training to catch problems early (NaN, loss divergence, idle GPUs). Avoids wasting GPU hours on broken runs. Use when training is running and you want automated health checks.●····●37/40Changelog AutomationAutomate changelog generation from commits, PRs, and releases following Keep a Changelog format. Use when setting up release workflows, generating release notes, or standardizing commit conventions.◐····●36/40Hermes Tweet> Install and operate Hermes Tweet, a Hermes Agent plugin for X/Twitter research, timeline reading, tweet analysis, and approval-gated private or state-changing operations. Use this skill when installing Hermes Tweet, researching X/Twitter accounts, monitoring launch signals, investigating mentions, auditing giveaways, or preparing gated X operations. Use proactively when a Hermes Agent workflow needs current X/Twitter context. Requires XQUIK_API_KEY for read and action tools.◐····●36/40