software-architecture
Files
SKILL.mdagentsreferences
Install
Install the containing plugin
/plugin install software-design@llm-skills
Invoke this skill after installation
/software-design:software-architecture
This skill is bundled inside software-design. Install the plugin once, then Claude Code can use any of its included skills. Browse the full plugin repository at github.com/alisonaquinas/llm-software-design.
SKILL.md
name: software-architecture description: > compare architectural styles, service boundaries, layering approaches, and system-level tradeoffs. use when the user asks about monoliths versus services, modular boundaries, domain seams, integration styles, or how to structure a system for growth and maintainability.
Software Architecture
Use this skill to reason about high-level structure, boundaries, and system tradeoffs.
Intent Router
| Need | Load |
|---|---|
| architectural drivers, boundary heuristics, and review checklist | references/architecture-checklist.md |
Quick Start
- Start with system goals, constraints, and expected rate of change.
- Choose boundaries around business capability, ownership, and dependency direction.
- Optimize for clarity of responsibility before optimizing for distribution.
- Treat operational complexity as a first-class tradeoff.
Workflow
- state the primary drivers: scale, team topology, deploy cadence, reliability, compliance, and data shape
- compare two or three plausible structures rather than jumping to one favored style
- identify what must change, fail, or deploy independently
- recommend the simplest structure that satisfies the current drivers
- note which future signals would justify evolving the architecture
Outputs to Prefer
- explain the recommendation in terms of boundaries, ownership, data flow, and operational cost
- make coupling, latency, consistency, and failure-mode tradeoffs explicit
- distinguish current needs from hypothetical future-proofing
- recommend migration steps when the architecture should evolve incrementally
Common Requests
Compare a modular monolith and services for this system and recommend boundaries.
Review this architecture for boundary clarity, integration risk, and unnecessary distribution.
Verification and Next Steps
- verify the proposed boundaries against ownership, deploy cadence, data consistency, and failure isolation
- show one incremental migration step rather than only the target-state architecture
- name the future signal that would justify the next split or consolidation
Safety Notes
- avoid distributed systems when a modular monolith will do
- avoid vague future-proofing without a concrete likely change
- do not recommend service boundaries that exceed the team's operational maturity