Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →vladikk/balanced-coupling
The Balanced Coupling model for software design.
Passed 24 of 25 test cases with the skill, and 9 of 25 without it.
and 22 more in the full report
15 fixed9 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
We currently have a microservice managed by Team A that directly queries the PostgreSQL read-replica of another microservice managed by Team B because they need real-time order data. Please provide an architectural assessment of this connection. Format your response as a structured analysis covering the nature of knowledge shared between the services, the technical and team distance involved, the business rate of change, an overall evaluation of whether this design creates complexity or modularity, and actionable refactoring suggestions.
| Checked | Without skill | With skill |
|---|---|---|
| Classifies direct database read-replica querying as intrusive coupling. | Missed | Passed |
| Evaluates the combination of high integration strength and high socio-technical distance as producing complexity. | Passed | Passed |
| Provides plain-language explanations when introducing Domain-Driven Design subdomain terms. | Passed | Passed |
The instructions your model reads when the skill loads.
A comprehensive reference for understanding the Balanced Coupling model as described by Vlad Khononov. This document synthesizes the full model from the companion blog at coupling.dev, covering its foundations, dimensions, balancing mechanics, relationship to prior coupling models, and connections to domain-driven design.
The term "coupling" has long been synonymous with bad design. The balanced coupling model challenges this assumption. According to the dictionary, coupling is simply a device for connecting parts. If a system is a set of components interacting to achieve a goal, then coupling is what connects those components and makes it possible to achieve those goals. Coupling is what makes the value of a system greater than the sum of its parts.
You cannot build a system out of fully independent components — that would go against the very definition of "system." The question is not whether to couple, but how to couple. Some forms of coupling lead to modularity; others create complexity. The balanced coupling model treats coupling not as a nuisance to eliminate but as a design tool to wield deliberately.
The model adopts the Cynefin framework's definition of complexity:
In software design, complexity means a system where the outcomes of changes are unpredictable. The goal of modular design is to avoid situations where the effect of a change can only be identified in retrospect.
Crucially, complexity is subjective — it is a function of both system design and our cognitive limits:
complexity = f(system design, cognitive limits)
Studies suggest humans can hold only 4 +/- 1 units of information in working memory simultaneously. When the information required to make a change exceeds this cognitive capacity, the design is complex.
If complexity makes change outcomes unpredictable, modularity is its opposite. A modular design satisfies two criteria:
test cases passed, vs 9 / 25 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.