system-architecturelisted

# System Architecture Microservices and system design review. Composite of `alirezarezvani/claude-skills` engineering-team `senior-architect` + POWERFUL `api-design-reviewer`. ## When to use - Designing a new system, service boundary, or microservices split - Reviewing an architecture for scalability, coupling, or failure modes - Evaluating technology choices (DB, queue, infra) with trade-offs ## Workflow 1. **Map the system** — List components, data flow, dependencies, and interfaces. Draw a one-box-per-service diagram (Mermaid or ASCII). 2. **Propose 2-3 approaches** — With trade-offs (latency, cost, operational burden) and your recommendation. Ruthlessly YAGNI — remove unnecessary components. 3. **Review checklist** — For the chosen approach: - Boundaries: does each service have one clear purpose? Can you change internals without breaking consumers? - Data: ownership, consistency (eventual vs strong), schema evolution - Failure: retries, timeouts, circuit breakers, observability - Scale: stateful vs stateless, caching, partitioning 4. **Document** — Write the validated design to `docs/architecture/<topic>.md` (or `docs/superpowers/specs/` if architectural per brainstorming). ## Verification - [ ] 2-3 approaches with trade-offs and a recommended option - [ ] Sectioned design approved per section before committing - [ ] Boundaries pass isolation test (change internals without breaking consumers) - [ ] Failure and scale considerations are explicit, not defe