Applies modular monolith with enforced internal boundaries.
SkillScore86Maintained
Automatic
◆Coding pack
Last verified 8/20/2026
What it changes
Passed 18 of 21 test cases with the skill, and 14 of 21 without it.
Without skill68%
With skill86%
Checks it passed that the model alone missed
Treat any boundary violation as a build-breaking error.
Require tracking change-coupling metrics between internal modules.
Include change-coupling metrics tracking how frequently internal modules change together.
and 2 more in the full report
4 fixed15 passed either way3 still failing0 broke
Pass-rate lift
+18 pp
Tokens
+3%
Agent turns
0%
Response time
-34%
Model gemini-3.6-flashMeasured 8/20/2026v119 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
Our backend API codebase is getting crowded, and dev teams are stepping on each other's toes with tightly coupled database calls and internal imports. We aren't ready to deploy microservices yet due to infra overhead, but we want to establish clear domain boundaries within our existing single codebase. Can you draft an architecture plan and decision record outlining how we should organize modules, protect internal code, and expose APIs between domains?
What was checked, without and with the skill
Checked
Without skill
With skill
Specify conditions under which a module would be extracted into a separate service within the architecture decision record.
Missed
Passed
Require tracking change-coupling metrics between internal modules.
Missed
Passed
case-01 · gemini-3.6-flash · 8/20/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md71 linessingle file
The Modular Monolith Paradigm
When To Use
Organizing large codebases into well-bounded modules
Teams wanting microservice boundaries without distributed complexity
When NOT To Use
Already distributed as microservices
Tiny applications where module boundaries add unnecessary complexity
When to Employ This Paradigm
When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.
When release velocity is slowed by tangled dependencies between internal modules.
When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.
Adoption Steps
Identify Modules: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.
Encapsulate Internals: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.
Expose Public Contracts: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.
Enforce Architectural Fitness: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.
Plan for Evolution: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.
Key Deliverables
An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.
Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.
Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.
Risks & Mitigations
Regression to a "Big Ball of Mud":
Mitigation: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.
Shared Database Hotspots:
Mitigation: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.
Applies coarse-grained service architecture for deployment independence. Use when independent deployment is needed but shared databases rule out microservices.