# Dependency upgrade assessment

> Judge whether an upgrade is safe, and say what to test.

- Skill: `vstorm-co/dependency-upgrade-assessment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vstorm-co/dependency-upgrade-assessment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vstorm-co/dependency-upgrade-assessment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vstorm-co (https://skillmd.com/u/vstorm-co)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vstorm-co/dependency-upgrade-assessment

---


# Assessing a dependency upgrade

Two questions: what breaks, and what happens if we do nothing.

## Read in this order

The changelog between the two versions — every one, not just the latest ·
breaking changes and deprecations · security advisories fixed · whether the
minimum runtime version moved · transitive dependency changes.

## Classify

**Security** — has a deadline, and it is short. **Breaking** — needs code
changes; list them with file paths. **Routine** — batch it.

## Say what to test

Name the specific paths this dependency is on. "Run the suite" is not an
assessment — the suite passing is necessary and, for a library that changes
behaviour rather than signatures, not sufficient.

## Always report the cost of waiting

Version drift compounds. Four majors behind is a project; one is an afternoon.
Say which this is becoming.

## Never

Upgrade a major version in the same change as a feature, or trust a green suite
on a library whose defaults changed.