Software Architecture
Use this skill to make system-level design decisions and leave an inspectable path from drivers to evidence. It owns the architecture decision workflow, not the implementation of any subsystem.
Workflow
- Frame the decision. Establish the desired outcome, stakeholders, constraints, decision horizon, reversibility, affected systems, and evidence gaps. Do not invent scale, regulatory, latency, or ownership facts.
- Turn qualities into scenarios. Name the architecture characteristics that matter, express each as an observable scenario, prioritize them, and expose conflicts. Load
references/architecture-characteristics-and-tradeoffs.md.
- Choose boundaries and shape. Compare styles, topology, and deployment granularity against the scenarios and team operating capacity. Load
references/styles-topologies-and-granularity.md.
- Test ownership and coupling. Identify policy, data, change, runtime, and team boundaries. Treat a service split as a hypothesis, not a default. Load
references/coupling-modularity-and-data-ownership.md.
- Make runtime behavior explicit. For asynchronous or distributed flows, specify authority, consistency, ordering, retries, duplicates, timeouts, partial failure, recovery, and reconciliation. Load
references/distributed-workflows-and-consistency.md.
- Record and verify. Capture the decision and rejected alternatives in
templates/architecture-design-brief.md and templates/tradeoff-record.md; use templates/architecture-review.md for challenge and sign-off. Define fitness evidence and drift response with references/evolution-fitness-functions-and-drift.md.
- Plan change without hiding execution ownership. Identify evolutionary slices, coexistence assumptions, and handoff conditions. Load
references/migration-and-coexistence.md; route an approved transition to migration-engineering.
- Facilitate proportionately. Match review depth to blast radius, irreversibility, uncertainty, and cross-team impact. Load
references/architecture-practice-and-facilitation.md.
Output Contract
Produce an architecture decision brief or review that includes drivers, stakeholders, constraints, prioritized scenarios, candidate options, explicit tradeoffs, boundaries and ownership, runtime and failure behavior, operational implications, decisions, evidence gaps, fitness checks, evolution slices, and named owners. State what is decided, what remains open, and which specialist owns follow-up work.
Ownership Boundaries
- Reverse engineer an existing codebase or infer architecture from repository evidence with
software-architecture-analysis.
- Design interface contracts, schemas, compatibility, or API topology with
api-design-and-evolution.
- Design data platforms, data products, data models, or data governance with
data-architect.
- Implement services, integrations, transactions, or application code with
backend-engineering and the relevant engineering owner.
- Provision or operate cloud, network, CI/CD, containers, secrets, or observability substrate with
platform-engineering and its tool owners.
- Define security requirements, threat models, authorization, secrets, or security evidence with
secure-software-engineering.
- Author the durable ADR with
adr-authoring; this skill supplies the architecture decision context and tradeoff analysis.
- Execute an approved cross-system transition with
migration-engineering; this skill decides whether the target shape and boundary are justified.
- Model capacity, unit cost, load evidence, or SLO-cost tradeoffs with
capacity-and-cost-engineering.
- Design and exercise degradation, failover, restore, or recovery evidence with
resilience-and-recovery.
- Create structural diagrams with
c4-diagramming or mermaid-diagrams.
- Govern a technology portfolio, radar, or proportional technology governance path with
technology-radar.
When Not To Use
Do not use this skill as a substitute for those specialist owners, as a code review workflow, or as a vendor/tool runbook. If the request is only one interface, data platform, implementation, infrastructure, security, capacity, diagram, ADR, or migration concern, load the narrower owner directly. If the architecture question depends on facts from an existing system, start with software-architecture-analysis and return here for a target decision.
Reference Guide
| Load when |
Reference |
| Prioritizing qualities and comparing conflicting outcomes |
references/architecture-characteristics-and-tradeoffs.md |
| Comparing styles, deployment topology, or granularity |
references/styles-topologies-and-granularity.md |
| Testing modularity, coupling, boundaries, and data authority |
references/coupling-modularity-and-data-ownership.md |
| Designing distributed workflows, consistency, or failure behavior |
references/distributed-workflows-and-consistency.md |
| Choosing replication, partitioning, coordination, ordering, or transaction-isolation mechanisms |
references/distributed-workflows-and-consistency.md, then the DDIA mini reference; load the full reference only when deeper mechanism analysis is necessary |
| Defining fitness evidence, drift response, or evolutionary change |
references/evolution-fitness-functions-and-drift.md |
| Planning coexistence and handing execution to migration engineering |
references/migration-and-coexistence.md |
| Running architecture workshops, reviews, and decision facilitation |
references/architecture-practice-and-facilitation.md |
| Checking provenance and the licensed-books transformation boundary |
references/source-index.md |
Keep the ownership split explicit when loading DDIA: this skill owns the system-level architecture decision and its tradeoffs; programming-principles supplies distributed-data principles and mechanism detail. Route message-handler implementation to backend-engineering, API or event contracts to api-design-and-evolution, data-platform design to data-architect, and exercised recovery evidence to resilience-and-recovery.
Completion
Stop when the architecture decision has an accountable owner, explicit alternatives and consequences, evidence or a named gap for each material claim, a verification path for prioritized characteristics, and specialist handoffs. Escalate rather than silently resolve missing authority, security, data ownership, or operational evidence.
1---2name: software-architecture3description: Design and review software architectures from business drivers through system boundaries, tradeoffs, runtime behavior, evolution, and architecture practice. Use when choosing a greenfield or target architecture, comparing modular-monolith and service shapes, designing distributed consistency, replication, partitioning, coordination, ordering, transaction isolation, or failure behavior, defining architecture fitness evidence, or facilitating a consequential architecture review. Do not use for reverse engineering, API contract semantics, data-platform design, implementation, infrastructure operations, security lifecycle, or migration execution; route those to the named specialist skills.4license: MIT5---67# Software Architecture89Use this skill to make system-level design decisions and leave an inspectable path from drivers to evidence. It owns the architecture decision workflow, not the implementation of any subsystem.1011## Workflow12131. **Frame the decision.** Establish the desired outcome, stakeholders, constraints, decision horizon, reversibility, affected systems, and evidence gaps. Do not invent scale, regulatory, latency, or ownership facts.142. **Turn qualities into scenarios.** Name the architecture characteristics that matter, express each as an observable scenario, prioritize them, and expose conflicts. Load `references/architecture-characteristics-and-tradeoffs.md`.153. **Choose boundaries and shape.** Compare styles, topology, and deployment granularity against the scenarios and team operating capacity. Load `references/styles-topologies-and-granularity.md`.164. **Test ownership and coupling.** Identify policy, data, change, runtime, and team boundaries. Treat a service split as a hypothesis, not a default. Load `references/coupling-modularity-and-data-ownership.md`.175. **Make runtime behavior explicit.** For asynchronous or distributed flows, specify authority, consistency, ordering, retries, duplicates, timeouts, partial failure, recovery, and reconciliation. Load `references/distributed-workflows-and-consistency.md`.186. **Record and verify.** Capture the decision and rejected alternatives in `templates/architecture-design-brief.md` and `templates/tradeoff-record.md`; use `templates/architecture-review.md` for challenge and sign-off. Define fitness evidence and drift response with `references/evolution-fitness-functions-and-drift.md`.197. **Plan change without hiding execution ownership.** Identify evolutionary slices, coexistence assumptions, and handoff conditions. Load `references/migration-and-coexistence.md`; route an approved transition to `migration-engineering`.208. **Facilitate proportionately.** Match review depth to blast radius, irreversibility, uncertainty, and cross-team impact. Load `references/architecture-practice-and-facilitation.md`.2122## Output Contract2324Produce an architecture decision brief or review that includes drivers, stakeholders, constraints, prioritized scenarios, candidate options, explicit tradeoffs, boundaries and ownership, runtime and failure behavior, operational implications, decisions, evidence gaps, fitness checks, evolution slices, and named owners. State what is decided, what remains open, and which specialist owns follow-up work.2526## Ownership Boundaries2728- Reverse engineer an existing codebase or infer architecture from repository evidence with `software-architecture-analysis`.29- Design interface contracts, schemas, compatibility, or API topology with `api-design-and-evolution`.30- Design data platforms, data products, data models, or data governance with `data-architect`.31- Implement services, integrations, transactions, or application code with `backend-engineering` and the relevant engineering owner.32- Provision or operate cloud, network, CI/CD, containers, secrets, or observability substrate with `platform-engineering` and its tool owners.33- Define security requirements, threat models, authorization, secrets, or security evidence with `secure-software-engineering`.34- Author the durable ADR with `adr-authoring`; this skill supplies the architecture decision context and tradeoff analysis.35- Execute an approved cross-system transition with `migration-engineering`; this skill decides whether the target shape and boundary are justified.36- Model capacity, unit cost, load evidence, or SLO-cost tradeoffs with `capacity-and-cost-engineering`.37- Design and exercise degradation, failover, restore, or recovery evidence with `resilience-and-recovery`.38- Create structural diagrams with `c4-diagramming` or `mermaid-diagrams`.39- Govern a technology portfolio, radar, or proportional technology governance path with `technology-radar`.4041## When Not To Use4243Do not use this skill as a substitute for those specialist owners, as a code review workflow, or as a vendor/tool runbook. If the request is only one interface, data platform, implementation, infrastructure, security, capacity, diagram, ADR, or migration concern, load the narrower owner directly. If the architecture question depends on facts from an existing system, start with `software-architecture-analysis` and return here for a target decision.4445## Reference Guide4647| Load when | Reference |48|---|---|49| Prioritizing qualities and comparing conflicting outcomes | `references/architecture-characteristics-and-tradeoffs.md` |50| Comparing styles, deployment topology, or granularity | `references/styles-topologies-and-granularity.md` |51| Testing modularity, coupling, boundaries, and data authority | `references/coupling-modularity-and-data-ownership.md` |52| Designing distributed workflows, consistency, or failure behavior | `references/distributed-workflows-and-consistency.md` |53| Choosing replication, partitioning, coordination, ordering, or transaction-isolation mechanisms | `references/distributed-workflows-and-consistency.md`, then the [DDIA mini reference](../programming-principles/references/designing-data-intensive-apps.mini.md); load the [full reference](../programming-principles/references/designing-data-intensive-apps.full.md) only when deeper mechanism analysis is necessary |54| Defining fitness evidence, drift response, or evolutionary change | `references/evolution-fitness-functions-and-drift.md` |55| Planning coexistence and handing execution to migration engineering | `references/migration-and-coexistence.md` |56| Running architecture workshops, reviews, and decision facilitation | `references/architecture-practice-and-facilitation.md` |57| Checking provenance and the licensed-books transformation boundary | `references/source-index.md` |5859Keep the ownership split explicit when loading DDIA: this skill owns the system-level architecture decision and its tradeoffs; `programming-principles` supplies distributed-data principles and mechanism detail. Route message-handler implementation to `backend-engineering`, API or event contracts to `api-design-and-evolution`, data-platform design to `data-architect`, and exercised recovery evidence to `resilience-and-recovery`.6061## Completion6263Stop when the architecture decision has an accountable owner, explicit alternatives and consequences, evidence or a named gap for each material claim, a verification path for prioritized characteristics, and specialist handoffs. Escalate rather than silently resolve missing authority, security, data ownership, or operational evidence.
magnus919