dependency-architecturelisted

# Dependency Architecture ## Coverage Design and audit the dependency graph of a codebase. Covers direct vs transitive dependencies, runtime vs dev/build dependencies, package boundaries, import direction, adapter layers, duplicate-purpose libraries, lock-in, upgrade policy, supply-chain risk, and dependency drift. ## Philosophy Dependencies are architecture. Every package adds API surface, operational risk, update cost, and implicit design direction. A dependency that solves one task can still be wrong if it creates long-term coupling or duplicates an existing standard. Prefer fewer, clearer dependencies with explicit ownership. Wrap volatile external SDKs at boundaries. Let application code depend on local contracts, not vendor shapes, when the vendor is likely to change or be replaced. ## Method 1. Inventory dependencies by purpose, owner, and import surface. 2. Classify each as runtime, dev, build, test, or optional. 3. Identify duplicate-purpose libraries and unauthorized standards. 4. Check import direction and package boundary rules. 5. Decide where adapters are needed for external SDKs or volatile APIs. 6. Assess security, maintenance, license, and ecosystem health. 7. Define upgrade, pinning, and removal policy. ## Evals This skill ships a comprehension-eval artifact at [`examples/evals/dependency-architecture.json`](https://github.com/jacob-balslev/skill-graph/blob/main/examples/evals/dependency-architecture.json). The checklist below is the authoring gate