dependency-analysislisted

# Dependency Analysis ## Purpose Dependencies are the main determinant of how expensive a codebase is to change. They come in two kinds, and both need attention: - **Internal**: which module may reference which. Cycles and excessive coupling make code untestable, unbuildable in isolation, and resistant to change. - **External**: third-party packages and plugins. They are code you ship without having reviewed, carrying versions, vulnerabilities, licences, and their own dependencies. ## When to use - Before adding any external dependency. - Orienting in an unfamiliar codebase — the dependency graph is the fastest map. - When a small change requires edits in many unrelated places. - When modules cannot be tested without instantiating the world. - When an upgrade breaks the build, or an upgrade is being avoided out of fear. - When build times, package sizes, or cook/asset sizes grow unexpectedly. - During a security review, since vulnerabilities are version-specific. ## When NOT to use - Designing the boundaries themselves. Use `software-architecture`; this skill analyses the graph, that one decides what it should be. - Runtime performance. Use `performance-profiling-method`. - Restructuring for its own sake, with no cost being paid. ## Required context | Fact | Why it matters | |---|---| | The module or assembly boundaries | Defines the internal graph's nodes | | The manifest **and** the lockfile | The manifest states ranges; the lockfile states what is installe