All skills
architecture-style-selection
FoundationJIT onlyanalysis-agent: use when selecting monolith, modular, layered, service, event-driven, or hybrid architecture; skip when no style decision is required.
- Group
- Architecture & design
- Supported roles
- MainAnalysisTaskReview
- Source
- SKILL.md
Use when
Trigger signals that make this skill the right owner
- select monolith modular layered service event driven or hybrid architecture style
Do not use when
Anti-triggers — as binding as the triggers above
- no task-local architecture style selection decision is required
Required inputs
What must be supplied before this skill can decide anything
- current task contract
- selected primary Professional Skill
- task-local trigger evidence
Output contract
What this skill owes the next role
- Architecture style decision with forces, tradeoffs, constraints, and selected style; operating owner; transition, migration, coexistence, freeze, recovery, deletion, and retirement evidence; proof limits and residual owner.
Escalation signals
When this skill must hand the decision back
- Premature complexity or undersized structure increases delivery and operations risk
Loaded by
This skill never owns a task. These professionals may pull it in as Layer 3.
Targeted references
Each reference carries its own load condition. None of them enter context by default.
| Reference | Load when | Do not load when | Required by |
|---|---|---|---|
| benchmarks-and-patterns.mdbenchmark-pattern | Runtime boundary, migration, and reversibility forces leave competing styles. | Current constraints already require the least-complex viable style. | Analysis |
| checklist.mddecision-checklist | Style choice changes data ownership, deployability, or failure isolation. | No system-wide boundary or operating model changes. | Analysis |
| evidence-patterns.mdevidence-pattern | Style justification depends on current topology or operational readiness. | No topology, migration, or readiness claim requires proof. | Analysis |