Applies coarse-grained service architecture for deployment independence.
SkillScore95Maintained
Automatic
◆Coding pack
Last verified 8/20/2026
What it changes
Passed 21 of 22 test cases with the skill, and 14 of 22 without it.
Without skill64%
With skill95%
Checks it passed that the model alone missed
Gates all breaking database schema changes through a formal review process.
Prescribes consumer-driven contract tests to validate service interface stability.
Requires the ADR to specify coordination mechanisms such as an API gateway or service registry.
and 7 more in the full report
7 fixed14 passed either way1 still failing0 broke
Pass-rate lift
+32 pp
Tokens
-8%
Agent turns
0%
Response time
-37%
Model gemini-3.6-flashMeasured 8/20/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
Before launching our first independently deployed domain service, what governance information must be finalized in our Architecture Decision Record according to pre-deployment exit criteria?
What was checked, without and with the skill
Checked
Without skill
With skill
Requires the ADR to document explicit service boundaries and schema or table data ownership.
Passed
Passed
Requires the ADR to specify coordination mechanisms such as an API gateway or service registry.
Missed
Passed
case-17 · 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.md61 linessingle file
The Service-Based Architecture Paradigm
When To Use
Multi-team organizations with domain-aligned services
Systems requiring independent deployment of components
When NOT To Use
Single-team projects small enough for a monolith
Latency-sensitive systems where inter-service calls are prohibitive
When to Employ This Paradigm
When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.
When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.
When establishing clear service contracts for partner teams or external consumers.
Adoption Steps
Group Capabilities: Bundle related business functions into a small set of well-defined services, each with a designated owner.
Define Service Contracts: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.
Control Database Schemas: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.
Establish Service Mediation: Use a service registry or an API gateway to handle routing, authentication, and observability.
Plan for Evolution: Identify architectural "hotspots" that are likely candidates for being split into more granular services in the future.
Key Deliverables
An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.
A suite of contract tests and consumer-driven contract tests for each service to validate stability.
Runbooks that describe deployment procedures, rollback plans, and service dependencies.
Risks & Mitigations
Coupling Through a Shared Database:
Mitigation: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.
Architectural Degradation:
Mitigation: Without strong governance, this architecture can degrade into a "distributed monolith": a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.
Concrete Components
These vocabulary items name the concrete tools and abstractions
that show up when the paradigm is implemented. They are not