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
- Inventory dependencies by purpose, owner, and import surface.
- Classify each as runtime, dev, build, test, or optional.
- Identify duplicate-purpose libraries and unauthorized standards.
- Check import direction and package boundary rules.
- Decide where adapters are needed for external SDKs or volatile APIs.
- Assess security, maintenance, license, and ecosystem health.
- Define upgrade, pinning, and removal policy.
Evals
This skill ships a comprehension-eval artifact at examples/evals/dependency-architecture.json. The checklist below is the authoring gate for dependency-boundary decisions; the eval file is the grader surface.
Verification
Do NOT Use When
| Use instead |
When |
framework-fit-analysis |
You are selecting a major framework, platform, runtime, or database. |
owasp-security |
The task is vulnerability-focused security review. |
refactor |
You are restructuring code without changing dependency architecture. |
architecture-decision-records |
The dependency decision is already made and needs a record. |
1---2name: dependency-architecture3description: Use when designing or auditing dependency structure: package boundaries, runtime vs build dependencies, adapter layers, duplicate-purpose libraries, supply-chain risk, upgrade policy, lock-in, and dependency graph health. Do NOT use for choosing a major framework (use `framework-fit-analysis`), vulnerability-only review (use `owasp-security`), or routine refactoring without dependency boundary changes (use `refactor`).4license: MIT5---6
7# Dependency Architecture
8
9## Coverage
10
11Design 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.
12
13## Philosophy
14
15Dependencies 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.
16
17Prefer 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.
18
19## Method
20
211. Inventory dependencies by purpose, owner, and import surface.
222. Classify each as runtime, dev, build, test, or optional.
233. Identify duplicate-purpose libraries and unauthorized standards.
244. Check import direction and package boundary rules.
255. Decide where adapters are needed for external SDKs or volatile APIs.
266. Assess security, maintenance, license, and ecosystem health.
277. Define upgrade, pinning, and removal policy.
28
29## Evals
30
31This 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 for dependency-boundary decisions; the eval file is the grader surface.
32
33## Verification
34
35- [ ] Each dependency has a purpose and owner
36- [ ] Runtime dependencies are not hidden as dev/build dependencies
37- [ ] Duplicate-purpose packages are justified or removed
38- [ ] External SDKs do not leak vendor types across core boundaries without intent
39- [ ] Package import direction is enforceable
40- [ ] Upgrade policy and lockfile discipline are clear
41- [ ] Security and license risks have been checked for high-impact dependencies
42
43## Do NOT Use When
44
45| Use instead | When |
46|---|---|
47| `framework-fit-analysis` | You are selecting a major framework, platform, runtime, or database. |
48| `owasp-security` | The task is vulnerability-focused security review. |
49| `refactor` | You are restructuring code without changing dependency architecture. |
50| `architecture-decision-records` | The dependency decision is already made and needs a record. |
aibot88