software-architecture

Software Architecture

This skill turns a vague "I want to build X" into a grounded architecture: it elicits the things that actually drive architectural decisions, then produces a right-sized architecture document with C4 diagrams and decision records that capture the why, not just the what.

The single most important idea: architecture is driven by quality attributes and constraints, not by technology. A junior approach jumps straight to "use Next.js + Postgres on AWS." A senior approach first asks "how many users, how much can it be down, how consistent must the data be, what's the team, what's the lock-in tolerance" — and derives the stack from the answers. This skill enforces that order: understand → decide → document.

Input

This skill consumes the requirements artifacts produced upstream, when they exist.

• SRS (primary) — if the user provides a path, use it; otherwise default to docs/srs.md. When found, it is the primary source: read the requirements and NFRs and design against them, shrinking the interview to confirmation plus the architecture-specific gaps (see Phase 1).
• Use cases (secondary) — default docs/use-cases.md. When found, read it to inform the runtime view (each significant use case becomes a runtime scenario / sequence diagram) and the resilience and security decisions (the exception/alternate flows reveal failure-handling needs; the actor-to-use-case mapping reveals trust boundaries). It refines how the design realizes the requirements; it does not replace the SRS as the driver of what.
• RTM — not consumed as input (it re-indexes the SRS and use cases without adding information), but written back to at delivery: this skill fills the Design ref column for the requirements its ADRs address (see Phase 5).
• If no SRS is found, fall back gracefully to the full elicitation interview (all seven rounds in references/elicitation-guide.md) — the skill stays fully usable standalone, for quick architecture work without a prior requirements phase.