Skill · Dependency management
Dependency management.
Keep dependencies current, respond to advisories, reduce supply-chain risk.
Decide what to depend on, keep dependencies current, respond to advisories, and reduce supply-chain risk. The category of a dependency drives its policy: critical runtime, supporting runtime, dev and build, or optional. Evaluating a new one means weighing five risk dimensions, because every package carries a cost beyond installation.
The default is not to add. A free package is not free once you count evaluation, maintenance, and supply-chain surface, so a dependency earns its place only when the value clearly exceeds that cost.
Audience: engineers setting an update cadence, responding to a security advisory, evaluating or removing a dependency, or unblocking a broken upgrade.
The framework
Four categories, each setting its own policy.
Every dependency falls into one of these, and the category drives the update cadence, the patch SLA, and the pinning strategy.
- 01Critical runtime: would break production if it failed (framework, database driver, payment SDK, auth library). Monthly minor updates, advisories patched within 24 to 72 hours, exact pins, thorough vetting.
- 02Supporting runtime: runs in production but is replaceable or non-critical (utilities, formatting). Monthly updates, patched within a week, narrow ranges acceptable.
- 03Dev and build: runs only during development or build (bundlers, linters, test frameworks). Quarterly updates, still patched within a week because supply-chain attacks target build tools.
- 04Optional and personal: tools individual developers use that are not part of the shared environment. Not managed at the project level, noted for completeness.
Evaluating a dependency
Five dimensions before adding one.
When evaluating whether to add a dependency, weigh these five. A package can look harmless and still fail on maintenance health or surface area.
01
Maintenance health
Last commit date, open-issue age, number of maintainers, commercial backing. A dependency abandoned a year ago is a liability waiting to surface.
02
Surface area
Package size, transitive-dependency count, bundle footprint, privileges required. A small package pulling in 50 transitive packages has the surface of all 50.
03
Replaceability
How hard it would be to remove, whether alternatives exist, whether the API is standard. A dependency you cannot replace puts you at its maintainer's mercy.
04
Trust
Maintainer reputation, code quality, license, security history, and supply-chain practices like signed releases and 2FA on publishes.
05
Cost
The time to evaluate, integrate, and maintain, plus the risk of breaking changes and the security exposure. Every dependency has a cost; free packages are not free.
How to manage them
Default to no; test before merging; pin narrowly.
Default to not adding a dependency. Every package carries a cost (evaluation, integration, ongoing maintenance, and supply-chain surface), and a free package is not free, so add one only when the value clearly exceeds that cost. A small package that pulls in 50 transitive dependencies carries the surface area of all 50, so audit the tree, not only the top level.
Even a patch-level update can break things, so test before merging: run the full suite for critical dependencies and smoke-test in staging. Be deliberate about the version of a fix, because reaching for a bug fix that arrives as a major version drags in unrelated breaking changes, and major upgrades get planned rather than rushed under deadline pressure.
Pinning everything to exact versions stops automatic patches and misses security fixes, while unpinned floating versions make builds non-reproducible. Use narrow ranges with a committed lockfile, automate the update PRs with Renovate or Dependabot, and run the audit in CI, tuning the noise rather than disabling it. The policy is what survives team turnover.
Reference files
The reference that goes alongside the SKILL.md.
references/upgrade-checklist.md
A step-by-step checklist for a major version upgrade of a critical dependency, from changelog reading to staged rollout.
Bridges to other skills
The skills next to dependency hygiene.
This skill owns the dependency tree. These cover the code that uses it, the infrastructure scanning beside it, and the purchasing it is not.
The code itself
code-review-webGeneral code review covers the code that calls a dependency. This skill manages the dependency tree, the advisories, and the upgrades, not the application logic.
Infrastructure scanning
security-baselineVulnerability scanning of infrastructure sits in the security baseline, which also wires up the advisory alerts. This skill responds to the package-level advisories those surface.
Service contracts
vendor-evaluationPinning a vendor or service contract is a procurement decision. Dependency management is about libraries and runtimes, not the commercial relationships behind a paid service.
Bundle impact
performance-optimizationWhen a dependency's real problem is its weight on the bundle or runtime, that is a performance investigation. This skill decides whether to keep it; that one measures its cost.
Open source under MIT
Read the SKILL.md on GitHub.
The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.
Frequently asked questions.
- How should I categorize dependencies?
- Into four categories, because the category drives the policy. Critical runtime would break production if it failed (framework, database driver, payment SDK), so it gets monthly minor updates, advisories patched within 24 to 72 hours, and exact pins. Supporting runtime is production code that is replaceable, patched within a week. Dev and build runs only at build time and gets quarterly updates, though supply-chain attacks still target build tools. Optional and personal tools are not managed at the project level.
- How fast should I patch a security advisory?
- By severity and by whether the dependency is direct or transitive. A critical advisory on a direct production dependency is patched today; high this week; medium this month; low is tracked. Critical and high in production code are emergencies, while medium and low are scheduled work. A transitive finding is patched a step slower if a fix exists, and tracked if one does not. Even patch-level updates can break things, so test before merging rather than auto-shipping the fix.
- Should I add this dependency?
- Default to no, and add one only when the value clearly exceeds the cost, where the cost includes ongoing maintenance, beyond installation. Evaluate it on five dimensions: maintenance health, surface area (a small package pulling in 50 transitive deps has the surface of all 50), replaceability, trust, and cost. For a small problem, the answer is often to solve it without a dependency at all, because a free package is not free once you count what it takes to keep it.
- Should I pin every version exactly?
- No, and do not let them float either. Pinning everything to exact versions stops automatic patches and misses security fixes, while an unpinned 'latest' in production makes builds non-reproducible. Use narrow ranges (like a caret range) together with a committed lockfile, which gives reproducible builds plus the ability to take patch updates. Exact pins are reserved for critical runtime dependencies where a surprise patch is itself a risk.
- How do I keep up without it becoming toil?
- Automate. Use Renovate or Dependabot to open update PRs, run the security audit in CI on every PR, and block merges on critical advisories with an override path for false positives. Tune the audit rather than disabling it when it gets noisy. Then audit usage quarterly: remove packages installed but imported nowhere, plan an upgrade for anything more than one or two major versions behind, replace packages unmaintained for over a year, and re-check licenses. Update PRs that pile up unmerged for months are their own failure mode.