architecture-style-selection
Registry Trigger
Use when
- select monolith modular layered service event driven or hybrid architecture style
Do not use when
- no task-local architecture style selection decision is required
Skill Role
Select the least complex architecture style that satisfies current ownership, change, data, reliability, regulatory, and delivery constraints.
High-Value Rules
- Select the simplest style that satisfies current constraints without relying on preference, fashion, or speculative scale.
- Choose a service or distributed boundary only when independent lifecycle, deployment, scaling, failure isolation, regulation, or ownership outweighs network, consistency, and operating cost.
- Compare viable alternatives across material forces, including the required rejected-alternative rationale.
- When the chosen style changes an existing boundary, define migration, coexistence, freeze, recovery, and deletion decisions only where the transition can expose mixed state or irreversible cost.
- Approve a new runtime responsibility only with a capable owner and consequence-derived controls, omitting unrelated operational bundles.
- Align architecture boundaries with current change authority and communication paths; reject distribution used to mask unclear module ownership or unenforced dependencies.
Anti-Patterns
- A modular monolith without enforced ownership and dependency direction can decay into a coupled monolith.
- A service split without data authority and failure semantics creates a distributed monolith.
- Organization structure is evidence about sustainable ownership, not a universal command to mirror the current org chart.
- Platform capability gaps change the cost and feasibility of a distributed option; they do not automatically select or reject it.
Stop Conditions
Escalate when a style decision materially changes deployment, data ownership, regulated or failure boundaries, operating responsibility, vendor exit, or rewrite-versus-evolve cost. Also escalate when its owner, constraints, alternatives, or transition evidence is missing. Derive the escalation owner and evidence depth from current governance and consequence rather than a fixed title, workload threshold, or schedule.
Output Contract
- architecture style decision with forces tradeoffs constraints selected style operating owner transition migration coexistence freeze recovery deletion retirement evidence proof limits and residual owner
Targeted References
| Path |
Type |
Load when |
Do not load when |
Required by |
Required output |
| benchmarks and patterns |
benchmark-pattern |
Runtime boundary, migration, and reversibility forces leave competing styles |
Current constraints already require the least-complex viable style |
analysis-agent |
option-comparison, selected-approach |
| checklist |
decision-checklist |
Style choice changes data ownership, deployability, or failure isolation |
No system-wide boundary or operating model changes |
analysis-agent |
checklist-result, residual-risk |
| evidence patterns |
evidence-pattern |
Style justification depends on current topology or operational readiness |
No topology, migration, or readiness claim requires proof |
analysis-agent |
evidence-record, proof-limit, residual-risk |
1---2name: architecture-style-selection3description: `analysis-agent`: use when selecting monolith, modular, layered, service, event-driven, or hybrid architecture; skip when no style decision is required.4---5
6# architecture-style-selection
7
8## Registry Trigger
9
10**Use when**
11
12- select monolith modular layered service event driven or hybrid architecture style
13
14**Do not use when**
15
16- no task-local architecture style selection decision is required
17
18## Skill Role
19
20Select the least complex architecture style that satisfies current ownership, change, data, reliability, regulatory, and delivery constraints.
21
22## High-Value Rules
23
24- Select the simplest style that satisfies current constraints without relying on preference, fashion, or speculative scale.
25- Choose a service or distributed boundary only when independent lifecycle, deployment, scaling, failure isolation, regulation, or ownership outweighs network, consistency, and operating cost.
26- Compare viable alternatives across material forces, including the required rejected-alternative rationale.
27- When the chosen style changes an existing boundary, define migration, coexistence, freeze, recovery, and deletion decisions only where the transition can expose mixed state or irreversible cost.
28- Approve a new runtime responsibility only with a capable owner and consequence-derived controls, omitting unrelated operational bundles.
29- Align architecture boundaries with current change authority and communication paths; reject distribution used to mask unclear module ownership or unenforced dependencies.
30
31## Anti-Patterns
32
33- A modular monolith without enforced ownership and dependency direction can decay into a coupled monolith.
34- A service split without data authority and failure semantics creates a distributed monolith.
35- Organization structure is evidence about sustainable ownership, not a universal command to mirror the current org chart.
36- Platform capability gaps change the cost and feasibility of a distributed option; they do not automatically select or reject it.
37
38## Stop Conditions
39
40Escalate when a style decision materially changes deployment, data ownership, regulated or failure boundaries, operating responsibility, vendor exit, or rewrite-versus-evolve cost. Also escalate when its owner, constraints, alternatives, or transition evidence is missing. Derive the escalation owner and evidence depth from current governance and consequence rather than a fixed title, workload threshold, or schedule.
41
42## Output Contract
43
44- architecture style decision with forces tradeoffs constraints selected style operating owner transition migration coexistence freeze recovery deletion retirement evidence proof limits and residual owner
45
46## Targeted References
47
48| Path | Type | Load when | Do not load when | Required by | Required output |
49|---|---|---|---|---|---|
50| [benchmarks and patterns](references/benchmarks-and-patterns.md) | benchmark-pattern | Runtime boundary, migration, and reversibility forces leave competing styles | Current constraints already require the least-complex viable style | analysis-agent | option-comparison, selected-approach |
51| [checklist](references/checklist.md) | decision-checklist | Style choice changes data ownership, deployability, or failure isolation | No system-wide boundary or operating model changes | analysis-agent | checklist-result, residual-risk |
52| [evidence patterns](references/evidence-patterns.md) | evidence-pattern | Style justification depends on current topology or operational readiness | No topology, migration, or readiness claim requires proof | analysis-agent | evidence-record, proof-limit, residual-risk |
machenjie