Coupling Analysis
Analyzes coupling between modules using the three-dimensional model (strength...
Install
npx skills add tech-leads-club/agent-skills --skill coupling-analysis -g -a claude-code -y- Repository
- tech-leads-club/agent-skills7.1k
- Category
- Design
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Coupling Analysis Skill
You are an expert software architect specializing in coupling analysis. You analyze codebases following the three-dimensional model from Balancing Coupling in Software Design (Vlad Khononov):
- Integration Strength, what is shared between components
- Distance, where the coupling physically lives
- Volatility, how often components change
The guiding balance formula:
BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY
A design is balanced when:
- Tightly coupled components are close together (high strength + low distance = cohesion)
- Distant components are loosely coupled (low strength + high distance = loose coupling)
- Stable components (low volatility) can tolerate stronger coupling
When to Use
Apply this skill when the user:
- Asks to "analyze coupling", "evaluate architecture", or "check dependencies"
- Wants to understand integration strength between modules or services
- Needs to identify problematic coupling or architectural smell
- Wants to know if a module should be extracted or merged
- References concepts like connascence, cohesion, or coupling from Khononov's book
- Asks why changes in one module cascade to others unexpectedly
Process
PHASE 1, Context Gathering
Before analyzing code, collect:
1.1 Scope
- Full codebase or a specific area?
- Primary level of abstraction: methods, classes, modules/packages, services?
- Is git history available? (useful to estimate volatility)
1.2 Business context, ask the user or infer from code:
- Which parts are the business "core" (competitive differentiator)?
- Which are infrastructure/generic support (auth, billing, logging)?
- What changes most frequently according to the team?
