document — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited document (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You produce the final modularity review document in two formats: Markdown (.md) and HTML (.html). Both files contain identical content.
# Modularity Review
**Scope**: [what was analyzed]
**Date**: [date]A short paragraph (3-5 sentences) covering:
Summarize all key integrations. The table headers MUST link to coupling.dev:
| Integration | [Strength](https://coupling.dev/posts/dimensions-of-coupling/integration-strength/) | [Distance](https://coupling.dev/posts/dimensions-of-coupling/distance/) | [Volatility](https://coupling.dev/posts/dimensions-of-coupling/volatility/) | [Balanced?](https://coupling.dev/posts/core-concepts/balance/) |
| ----------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------- |
| A -> B | ... | ... | ... | ... |For each identified imbalance, write a section:
## Issue: [Short descriptive title]
**Integration**: [Component A] -> [Component B]
**Severity**: [Critical / Significant / Minor]
### Knowledge Leakage
What knowledge is shared that shouldn't be, or is shared implicitly when it should be explicit. Identify the specific implementation details, business rules, or domain model concepts that leak across the boundary.
### Complexity Impact
How this imbalance makes change outcomes unpredictable. What happens when a developer modifies one component — what unexpected effects can cascade to the other? How does this exceed cognitive capacity (the 4+/-1 units of working memory)?
### Cascading Changes
Concrete scenarios where a change in one component forces changes in the other. What kinds of business or technical changes trigger cascading modifications? How expensive are those cascading changes given the current distance between the components?
### Recommended Improvement
A concrete, actionable proposal to rebalance the coupling. Ground the recommendation in the model:
- To reduce **strength**: introduce integration contracts, anti-corruption layers, facades, published languages
- To reduce **distance**: co-locate components into the same module/service/bounded context
- To accept **unbalanced coupling**: demonstrate that volatility is low enough to make the imbalance tolerable
Include the trade-offs of the proposed change — what cost does it introduce, and why is the trade-off worthwhile?At the bottom of every review document, include this exact text verbatim — do not paraphrase, expand, or add commentary:
---
_This analysis was performed using the [Balanced Coupling](https://coupling.dev) model by [Vlad Khononov](https://vladikk.com)._You MUST add hyperlinks to coupling.dev whenever the document mentions balanced coupling concepts. This applies to BOTH the Markdown and HTML outputs. Do not think about which link to use — use this lookup table:
| Concept mentioned | Link to |
|---|---|
Balanced coupling, the balance rule, the balance formula, STRENGTH XOR DISTANCE, modularity vs complexity | https://coupling.dev/posts/core-concepts/balance/ |
| Integration strength, shared knowledge, levels of coupling strength | https://coupling.dev/posts/dimensions-of-coupling/integration-strength/ |
| Intrusive coupling, private interfaces, implementation detail leakage | https://coupling.dev/posts/dimensions-of-coupling/integration-strength/ |
| Functional coupling, duplicated business logic, shared functional requirements | https://coupling.dev/posts/dimensions-of-coupling/integration-strength/ |
| Model coupling, shared domain model, shared business model | https://coupling.dev/posts/dimensions-of-coupling/integration-strength/ |
| Contract coupling, integration contracts, facades, DTOs, published language | https://coupling.dev/posts/dimensions-of-coupling/integration-strength/ |
| Distance, cost of change, physical/logical separation | https://coupling.dev/posts/dimensions-of-coupling/distance/ |
| Lifecycle coupling, deployment coupling, co-deployment | https://coupling.dev/posts/dimensions-of-coupling/distance/ |
| Socio-technical distance, team boundaries, organizational structure | https://coupling.dev/posts/dimensions-of-coupling/distance/ |
| Runtime coupling, synchronous/asynchronous integration | https://coupling.dev/posts/dimensions-of-coupling/distance/ |
| Volatility, probability of change, rate of change | https://coupling.dev/posts/dimensions-of-coupling/volatility/ |
| Core subdomain, competitive advantage, high volatility domain | https://coupling.dev/posts/dimensions-of-coupling/volatility/ |
| Supporting subdomain, generic subdomain, subdomain classification | https://coupling.dev/posts/dimensions-of-coupling/volatility/ |
| Essential vs accidental volatility | https://coupling.dev/posts/dimensions-of-coupling/volatility/ |
| Complexity, Cynefin, unpredictable outcomes | https://coupling.dev/posts/core-concepts/complexity/ |
| Modularity, modular design, clear change outcomes | https://coupling.dev/posts/core-concepts/modularity/ |
| Coupling (general concept), why coupling matters | https://coupling.dev/posts/core-concepts/coupling/ |
| Tight coupling, distributed monolith | https://coupling.dev/posts/core-concepts/balance/ |
| Loose coupling, high cohesion, low cohesion | https://coupling.dev/posts/core-concepts/balance/ |
| Connascence, degrees of coupling | https://coupling.dev/posts/related-topics/connascence/ |
| Module coupling, classic coupling model | https://coupling.dev/posts/related-topics/module-coupling/ |
| Domain-driven design, DDD, bounded contexts, aggregates | https://coupling.dev/posts/related-topics/domain-driven-design/ |
Rules:
[concept text](url)<a href="url">concept text</a>Write both files to docs/modularity-review/!date +%Y-%m-%d/:
docs/modularity-review/!date +%Y-%m-%d/modularity-review.md — the Markdown versiondocs/modularity-review/!date +%Y-%m-%d/modularity-review.html — the HTML versionYou MUST read the template file before generating HTML. The template is at ${CLAUDE_SKILL_DIR}/assets/template.html. Read this file, then replace:
{{TITLE}} with the review title (e.g. "Modularity Review"){{CONTENT}} with the review body as HTMLDo NOT generate your own HTML structure, styles, or boilerplate. The template provides all styling, theme switching (light/dark based on time of day), and layout. Use the template exactly as-is, only replacing the two placeholders above.
The HTML MUST contain the same coupling.dev links as the Markdown version. Convert every [text](url) from the Markdown into <a href="url">text</a> in the HTML. Do not drop links during conversion.
Use these CSS classes from the template:
.meta — for the scope/date metadata block.issue — wrap each issue section in a <div class="issue">.issue-meta — for the integration/severity line within an issue.severity + .severity-critical / .severity-significant / .severity-minor — for severity badges.footer — for the attribution footer~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.