45ck monolith-vs-modular-monolith-reviewer
Purpose
Evaluate whether a codebase or proposed system should remain a monolith, become a modular monolith, or move further toward service decomposition.
Expected inputs
- system scope
- team size and ownership model
- deployment and scaling needs
- change and failure patterns
Deliverables
- decision framing
- option comparison
- risks and caveats
- recommended next step
Trigger this skill when
- You need to move from vague architectural preference to explicit design reasoning.
- Structural decisions, boundaries, or quality goals are unclear or contested.
- A team needs an architecture artifact, critique, or decision record that can drive implementation.
Operating procedure
- Clarify the decision or structure this skill is meant to address.
- Separate facts, assumptions, constraints, and desired quality outcomes.
- Produce concrete structure or analysis tied to this system context.
- Make tradeoffs and uncertainty explicit instead of hiding them behind generic architecture language.
- Recommend the next most useful architecture artifact or decision step.
Quality gates
- Recommendations are tied to system context and drivers.
- Assumptions and unknowns are visible.
- Operational and deployment consequences are not ignored when relevant.
- Findings are concrete enough to influence implementation or governance.
Output style
- Be concrete and structured.
- Prefer architecture rationale over buzzwords.
- Separate evidence, inference, and recommendation.
- Use priority or severity when useful.
Failure modes to avoid
- Do not recommend a style because it sounds modern.
- Do not hide uncertainty behind definitive language.
- Do not ignore team size, ownership, or operational cost.
- Do not produce diagrams or structure with no stated purpose.
Minimum output skeleton
## Summary
## Findings or proposal
## Evidence vs assumptions
## Risks or tradeoffs
## Recommended next skill
Handoff targets
- component-boundary-reviewer
- service-decomposition-advisor
- adr-writer