Dependency management

Every dependency is a commitment to its maintenance, security surface, and upgrade path. The dependency-management skill brings deliberate criteria to every package decision — whether adding, updating, auditing, or removing.

​

When this skill fires

The skill description reads: “Use when adding new dependencies, deciding whether to update packages, running security audits on dependencies, evaluating library alternatives, or encountering outdated or vulnerable packages.” Specific triggers:

• Adding a new package or library to a project
• Security audit warnings (npm audit, pip-audit, cargo audit, etc.)
• Batch dependency update time
• Major version upgrade decisions
• Choosing between alternative libraries
• Lockfile merge conflicts
• Questioning whether a package is still maintained

Do not use for:

• Internal module or code organization (that’s refactoring)
• Learning a single package’s API (that’s research)

​

What it does

The skill applies structured decision trees to four types of dependency work: adding a new package, updating an existing one, responding to security alerts, and removing a package. Each path has specific criteria and workflows.

​

Adding a new package

Evaluate every new dependency against all seven criteria: Rule: If a package fails two or more criteria, find an alternative or write it yourself.

​

Updating existing packages

Workflow for batch updates:

​

Security urgency matrix

When a security audit reports vulnerabilities:

1. Run the audit tool for your ecosystem
2. Classify each finding using the matrix above
3. Address critical and exploitable issues before any other work
4. Document accepted risks for findings you cannot immediately resolve

​

Lockfile and pinning rules

• Always commit lockfiles (package-lock.json, yarn.lock, poetry.lock, Cargo.lock)
• Pin exact versions for production application dependencies
• Use ranges only for libraries (not applications)
• Never manually edit lockfiles — use package manager commands
• After resolving lockfile merge conflicts, always run install to regenerate

​

Removing a dependency

Before removing any package:

1. Search the codebase for all imports and usages
2. Check whether other dependencies rely on it transitively
3. Remove the import statements and package reference, then run the full test suite
4. Verify the lockfile is cleanly regenerated after removal

​

Common mistakes

​

Example scenario

You receive: npm audit found 2 vulnerabilities (1 critical, 1 moderate). The dependency-management skill fires. The agent:

1. Runs npm audit --json to get full details on both vulnerabilities
2. Classifies: critical vulnerability in lodash (prototype pollution, exploit exists) — action: update immediately; moderate in debug (ReDoS, no known exploit) — add to next update cycle
3. Updates lodash on its own branch, runs full test suite, confirms passing
4. Documents the moderate vulnerability as accepted risk with a note for the next update cycle
5. Commits the lodash update with: “security: update lodash to 4.17.21 (prototype pollution CVE-2021-23337)“

​

Related skills