skill-architecturelisted

# Skill: System Architecture & ADRs ## Architecture Decision Record (ADR) Format An ADR documents **why** an architectural decision was made, not just **what** was chosen. ```markdown # ADR-NNN: [Decision Title] ## Status Proposed | Accepted | Deprecated | Superseded by ADR-NNN ## Context Why are we making this decision? What's the problem? What constraints do we have (timeline, team size, technical)? What have we already tried or considered? ## Decision What exactly are we choosing to do? Be specific and precise. ## Consequences ### Positive - Benefit 1 - Benefit 2 ### Negative - Tradeoff 1 - Tradeoff 2 ### Mitigations - How we'll handle negative consequences ``` ## Tech Stack Decision Template Compare 3 options for each major choice: | Factor | Option A | Option B | Option C | |--------|----------|----------|----------| | Learning curve | Steep | Gentle | Moderate | | Community | Large | Small | Medium | | Performance | 1000 rps | 10k rps | 5k rps | | Scalability | Hard | Easy | Medium | | Team expertise | None | High | Medium | **Decision**: Option B **Reasoning**: Team knows it, easy to scale, community support ## Coupling vs. Cohesion **High Cohesion** = related code lives together - Example: All user auth logic in AuthService module **Low Coupling** = modules don't depend on each other heavily - Example: PaymentService doesn't directly call AuthService; uses events instead **Goal**: High cohesion + low coupling = easy to change ## Service Granularit