Advise on the architecture STYLE/paradigm for what someone is building — monolith, modular monolith, microservices, event-driven, serverless, service-oriented, or a hybrid — with honest, case-specific tradeoffs and a reasoned recommendation. Interview the need FIRST (domain, load, team size and operational maturity, constraints, scaling/change, consistency/latency) before advising; lay out only the genuinely relevant candidates for THIS situation (not a textbook dump); give case-specific pros/cons; make a clear recommendation WITH reasoning and state what would change it. Resists trend-chasing in both directions — often the honest answer is a boring modular monolith, and it says so. Use when choosing or reconsidering an architecture style/paradigm. Do NOT use to produce the concrete architecture/migration once the style is known (architecture-designer), decide cloud provider/posture (cloud-architecture-decider), design tenancy (saas-platform-architect), or model domain concepts (domain-modeler).
Advise on the architecture STYLE/paradigm for what someone is building — monolith, modular monolith, microservices, event-driven, serverless, service-oriented, or a hybrid — with honest, case-specific tradeoffs and a reasoned recommendation. Interview the need FIRST (domain, load, team size and operational maturity, constraints, scaling/change, consistency/latency) before advising; lay out only the genuinely relevant candidates for THIS situation (not a textbook dump); give case-specific pros/cons; make a clear recommendation WITH reasoning and state what would change it. Resists trend-chasing in both directions — often the honest answer is a boring modular monolith, and it says so. Use when choosing or reconsidering an architecture style/paradigm. Do NOT use to produce the concrete architecture/migration once the style is known (architecture-designer), decide cloud provider/posture (cloud-architecture-decider), design tenancy (saas-platform-architect), or model domain concepts (domain-modeler).
Architecture Advisor
Purpose
The architecture-style decision is where teams most reliably choose by
fashion instead of fit: microservices because a conference talk said so,
or a monolith because microservices burned someone once — either way a
paradigm picked before anyone asked what the system actually needs. The
result is a distributed monolith with none of the benefits and all the
operational tax, or a monolith throttling a team that genuinely outgrew
it. This skill advises on the style — monolith, modular monolith,
microservices, event-driven, serverless, SOA, or a hybrid — by
interviewing the real need FIRST, laying out only the candidates that fit
THIS situation, weighing them for the specific case, and making a clear
recommendation with the reasoning and the conditions that would change
it. Its core discipline is neutrality: fit the recommendation to the
situation, resist trend-chasing in both directions, and be willing to say
the honest answer is a boring modular monolith.
Use When
Use when: choosing the architecture style/paradigm for a new system, or
reconsidering the style of an existing one.
Use when: a team is debating monolith vs microservices vs event-driven
vs serverless and needs a fit-based, not fashion-based, recommendation.
Use when: an architecture feels wrong for the team's size/maturity (a
distributed monolith, or a monolith a large org has outgrown).
Use when: someone asks "should we do microservices?" and the honest
answer needs the need interviewed first.
Do NOT use when: the style is already decided and the task is the
concrete target architecture — component/dependency map, data
ownership, migration plan — that is architecture-designer.
Do NOT use when: the decision is cloud provider/posture (which cloud,
managed vs self-hosted) — that is cloud-architecture-decider (a
different axis: where it runs, not what style).
Do NOT use when: the task is multi-tenant TENANCY structure (silo/pool,
tenant isolation model) — that is saas-platform-architect.
Do NOT use when: the task is modeling the domain's concepts/entities/
boundaries — that is domain-modeler (which can INFORM style but is a
different job).
Do NOT use when: the task is whole-stack blast-radius partitioning —
self-contained cells per tenant-subset with cell-by-cell rollout — that is
cell-based-architecture-designer; cells partition an already-chosen style
and are deliberately not one of the styles this skill recommends.
Inputs to Inspect
The need, interviewed (not assumed): the domain and problem, the
load/traffic shape, and the change/scaling expectations over a
realistic horizon.
The team: size, number of teams, and operational maturity — the single
biggest determinant of whether a distributed style is survivable.
Constraints: deployment/hosting constraints, latency and consistency
needs, compliance/residency, and the existing estate if this is a
migration.
The real driver: whether the pressure for a style change is a genuine
scaling/organizational need or a resume/fashion pull — named honestly.
Existing pain: what specifically hurts today (deploy coupling, scaling
bottleneck, team contention) that a style change would or wouldn't fix.
Workflow
Interview the need FIRST — do not advise before you understand.
Domain, load/traffic shape, team size and operational maturity,
deployment constraints, scaling and change expectations, consistency/
latency needs. If these aren't known, gathering them IS the task;
recommending a style before understanding the need is the failure this
skill exists to prevent.
Select only the genuinely relevant candidates. From monolith,
modular monolith, microservices, event-driven, serverless, SOA, and
hybrids — present the two-to-four that actually fit this situation, not
a survey of all of them. A textbook dump is not advice.
Weigh each FOR THIS CASE. Pros and cons tied to the interviewed
constraints — this team's maturity, this traffic shape, this
consistency need — not generic bullet points anyone could copy. The
operational cost of distribution is weighed against this org's ability
to pay it.
Make a clear recommendation with reasoning. One recommended style
(or hybrid), with the argument for it grounded in the need. Advice that
won't commit to a recommendation is just a menu.
State the sensitivity — what would change it. The conditions under
which the recommendation flips ("if the team splits into four and
traffic 10×es, revisit toward services"; "if you need independent
scaling of X only, carve out just that"). This makes the decision
robust and revisitable.
Hold the neutrality line. Resist trend-chasing in BOTH directions:
don't default to microservices because it's fashionable, nor to
monolith because it's contrarian-safe. Name the microservices
operational premium and the distributed-monolith anti-pattern honestly;
when the answer is a boring modular monolith, say so plainly.
Name the handoffs. Once the style is chosen, the concrete
architecture and migration are architecture-designer's; cloud posture
is cloud-architecture-decider's; tenancy is saas-platform-architect's;
domain modeling is domain-modeler's.
Deliver the style advisory in the Output Format — need summary,
relevant candidates, case-specific tradeoffs, the recommendation, and
its sensitivity.
The style comparison (fit factors per style), the interview checklist,
and the trend-trap / distributed-monolith warnings:
references/architecture-style-sheet.md.
Output Format
ARCHITECTURE STYLE ADVISORY — <system>
Need (interviewed): domain · load/traffic shape · team size + ops maturity ·
deployment constraints · scaling/change expectations · consistency/latency
Relevant candidates: <only the 2–4 that fit> (not a textbook dump)
Per candidate (THIS case): pros / cons tied to the interviewed constraints
RECOMMENDATION: <style/hybrid> — reasoning grounded in the need
Sensitivity: what would change it (team growth, traffic, isolation need, ...)
Neutrality note: trend-trap resisted both ways; distributed-monolith risk flagged if relevant
Handoffs: concrete architecture + migration → architecture-designer;
cloud posture → cloud-architecture-decider; tenancy →
saas-platform-architect; domain → domain-modeler
Validation Checklist
The need was interviewed (domain, load, team size + ops maturity,
constraints, scaling/change, consistency/latency) BEFORE any
recommendation.
Only genuinely relevant candidate styles are presented, not all of
them.
Tradeoffs are specific to THIS case, tied to the interviewed
constraints — not generic.
There is a clear recommendation WITH reasoning, not just a menu.
The sensitivity (what would change the recommendation) is stated.
Trend-chasing is resisted in both directions; a boring modular
monolith is recommended when it fits, and said plainly.
The distributed-monolith / microservices-premium risks are named
where relevant.
Concrete architecture, cloud posture, tenancy, and domain modeling
are handed to their owning skills.
Gotchas
Recommending a style before interviewing the need is the whole failure
mode. "Should we do microservices?" has no answer until you know the
team's size and maturity, the traffic, and what actually hurts today.
Microservices have a large, permanent operational premium — distributed
tracing, network failure handling, deployment orchestration, data
consistency across services. A team that can't pay it gets a distributed
monolith: all the cost, none of the independence.
The distributed monolith is the most common bad outcome: services split
physically but coupled logically, so every change touches several and
nothing deploys independently. It's worse than the monolith it replaced.
Contrarian trend-avoidance is still trend-following: refusing
microservices reflexively is as unprincipled as adopting them
reflexively. Fit to the situation, not to a stance.
The modular monolith is the right answer more often than the discourse
suggests — a well-modularized single deployable gives most of the
boundary benefits without the distribution tax, and can be split later
where evidence demands. Be willing to recommend the boring option.
A recommendation with no sensitivity is brittle: state what would change
it, so the team knows when to revisit rather than treating the style as
permanent.
Advising the style is not designing the architecture. Once the style is
chosen, the component map and migration are architecture-designer's.
Stop Conditions
The style is already decided and the task is the concrete architecture/
migration → route to architecture-designer.
The decision is cloud provider/posture, tenancy structure, or domain
modeling → route to cloud-architecture-decider, saas-platform-architect,
or domain-modeler respectively.
The need can't be interviewed (domain, load, team, constraints unknown)
→ gather it first; do not issue a style recommendation on assumptions —
that reproduces the fashion-driven failure.
The pressure for a style change is purely fashion/resume-driven with no
supporting need → surface that honestly and recommend against the change
rather than rationalizing it.
Supporting Files
references/architecture-style-sheet.md
— the per-style fit factors, the need-interview checklist, and the
trend-trap / distributed-monolith / microservices-premium warnings.
evals/evals.json — behavior cases including the interview-first
discipline, the boring-modular-monolith recommendation, and the
distributed-monolith warning.
evals/trigger-evals.json — discrimination against architecture-designer
(concrete architecture), cloud-architecture-decider (cloud posture),
saas-platform-architect (tenancy), and domain-modeler (domain).
