balancing-couplinglisted

# Balancing Coupling ## Quick start Use the balance test before proposing decoupling: > Strong coupling across a large distance to volatile knowledge is the problem. Weak, local, stable, or cohesive coupling is usually acceptable. Default output: a coupling assessment plus a prioritized refactoring plan. Do not modify code until the user approves specific changes. Never mention skill or reference-file loading to the user. Hard stops: - If the user gives a design/snippet but no paths, analyze the supplied context; do not inspect the filesystem. - If the user asks for config edits but the target project files or directories do not exist, stop and ask before creating them. - Do not create source scaffolding, placeholder modules, docs, package files, or CI files unless the user explicitly asks to scaffold a project. - Do not install packages solely to validate example configs without user approval. Use only the terminology in this skill and its references. Prefer neutral terms such as contracts, interfaces, boundaries, integrations, implementations, wrappers, and composition root. Do not introduce external architecture labels, named principle labels, or jargon absent from these files. ## Workflow 1. **Clarify scope.** Identify whether the user supplied enough code/design context, named repo paths to inspect, or asked for concrete edits. If the prompt describes a design or snippet without paths, analyze that supplied context directly; do not browse the filesystem. 2. **Lo