Document

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha c439dc5935b0 · 14 Oct 2026Report an issue or request a re-scan

• Publishervladikk GitHub userOwner of the repository this skill is read from
• Source foldervladikk/modularity/skills/documentThe exact folder we audited
• LicenceNOASSERTIONAs the repository states it
• Commit pinned for this verdictc439dc5935b0A new audit runs when the source changes
• Repository statusNot archivedLast push 44 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Produces modularity review documents in both Markdown and HTML formats. Use when writing the final review output from a modularity analysis.

---
name: document
description: >
  Produces modularity review documents in both Markdown and HTML formats.
  Use when writing the final review output from a modularity analysis.
user-invocable: false
allowed-tools: Read, Write
---

# Document

You produce the final modularity review document in two formats: Markdown (`.md`) and HTML (`.html`). Both files contain identical content.

## Document Structure

### Header

```markdown
# Modularity Review

**Scope**: [what was analyzed]
**Date**: [date]
```

### Executive Summary

A short paragraph (3-5 sentences) covering:

- What the project does (its core functionality)
- The overall modularity status (healthy, needs attention, critical issues)
- The most important finding from the review

### Coupling Overview Table

Summarize all key integrations. The table headers MUST link to coupling.dev:

```markdown
| 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      | ...                                                                                 | ...                                                                     | ...                                                                         | ...                                                            |
```

### Issues

For each identified imbalance, write a section:

```markdown
## 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?
```

### Footer

At the bottom of every review document, include this exact text verbatim — do not paraphrase, expand, or add commentary:

```markdown
---

_This analysis was performed using the [Balanced Coupling](https://coupling.dev) model by [Vlad Khononov](https://vladikk.com)._
```

### Severity Criteria

- **Critical**: High strength + high distance + high volatility. Active source of complexity. Changes in this area are frequent, expensive, and unpredictable. Fix first.
- **Significant**: Unbalanced coupling in a moderately volatile area, or implicit coupling that hides integration points. Will cause pain as the system evolves.
- **Minor**: Unbalanced coupling in a low-volatility area, or low cohesion that increases cognitive load but doesn't cause cascading changes. Address opportunistically.

## Linking to coupling.dev (REQUIRED)

**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                    

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-14
   ✓SAFE B 89 / 100

   first audit · source c439dc5935b0

Questions about Document

• github.com/vladikk/modularity/tree/main/skills/document — the audited source at commit c439dc5935b0 and every finding aboveObserved · 14 Oct 2026

Spotted something wrong? Report a correction · Methodology