software-architecture
Files
SKILL.mdagentsreferences
Install
Install only this skill with npx skills
npx skills add alisonaquinas/llm-software-design --skill 'software-architecture' -g -y
Install the containing skill bundle
/plugin install software-design@llm-skills
This skill is bundled inside software-design. Use
npx skills when you only want this skill, or install the bundle once to make every included skill available through the plugin marketplace flow. Browse the full skill bundle repository at github.com/alisonaquinas/llm-software-design.Invoke
Invoke this skill after installation
/software-design:software-architecture
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