The Dependency Upgrade Risk Assessor: Turn a List of Outdated Packages Into a Ranked Upgrade Plan
Why this prompt matters
Dependency debt compounds silently. Each deferred upgrade doesn't just add one more overdue package — it makes the eventual upgrade riskier, because more changes stack up between your current version and the one you'll be forced onto during a security incident or an end-of-life deadline. Teams that never explicitly prioritize upgrades don't avoid the work; they just do it later, under worse conditions, usually as an unplanned emergency instead of a scheduled sprint task.
What we use it for
Your `npm outdated` output lists 34 packages behind, most flagged for major-version gaps. Your tech lead wants a prioritized upgrade plan before tomorrow's sprint planning, and you don't have time to read every changelog yourself.
Prompt
Act as a senior engineer responsible for dependency management who has run upgrade cycles across dozens of production codebases and knows how deferred upgrades turn into emergency migrations. Context: Project type and stack: [e.g., "Node.js/TypeScript monorepo, ~200k LOC, deployed to production weekly"] Outdated dependencies: [PASTE THE LIST — package name, current version, latest version, e.g. from `npm outdated`, `pip list --outdated`, or `bundle outdated`] Changelog or release-notes excerpts, if you have them: [PASTE RELEVANT EXCERPTS, OR WRITE "NONE PROVIDED" FOR ANY PACKAGE] Team capacity this sprint: [e.g., "limited — can only take on 2-3 low-risk upgrades" or "dedicated tech-debt sprint, can absorb larger changes"] Task: For each dependency listed, assess: 1. How many major and minor versions behind it currently is 2. Its risk category — security-critical, breaking-change-heavy, or routine 3. A specific recommendation: upgrade now, schedule for next sprint, or defer (with a reason) Constraints: - Flag any dependency with a known CVE or security advisory as highest priority regardless of stated team capacity. - Clearly distinguish between "this WILL break something" (based on documented breaking changes you were given) and "this MIGHT break something" (no changelog provided, so assume moderate risk) — never present a guess with the same confidence as a documented fact. - The "upgrade now" shortlist must respect the stated team capacity — do not recommend more work than the team can realistically absorb this sprint. - If changelog excerpts weren't provided for a package, say so explicitly in your reasoning rather than inventing specific breaking changes. Output Format: 1. A ranked table: Package | Current → Latest | Risk Level | Recommendation | Reasoning 2. A "Do This Sprint" shortlist that respects the stated capacity 3. One clarifying question to ask before greenlighting the single riskiest upgrade on the list
Result
| Package | Current → Latest | Risk Level | Recommendation | Reasoning |
|---|---|---|---|---|
| auth-token-lib | 2.3.1 → 2.3.9 | Security-Critical | Upgrade now | Changelog for 2.3.7 lists a fix for CVE-2026-31442, a token-validation bypass. This overrides capacity limits — security fixes are non-negotiable regardless of sprint load. |
| axios | 0.21.4 → 1.7.2 | Breaking-Change-Heavy | Schedule for next sprint | Major version jump (0.x → 1.x). Changelog confirms the default export pattern changed and several config options were renamed. This WILL require code changes across every file that imports axios directly — not a drop-in bump. |
| lodash | 4.17.15 → 4.17.21 | Routine | Upgrade now | Patch-only jump within the same minor version. No changelog excerpt was provided, but the version delta itself (patch-level only) makes breaking changes very unlikely. Low effort, safe to batch with the security fix above. |
| express | 4.17.1 → 4.19.2 | Routine | Upgrade now | Minor version bumps within Express 4.x have historically been backward-compatible. No changelog was provided for this specific range, so this is a moderate-confidence assessment, not a documented guarantee. |
| react | 17.0.2 → 18.3.1 | Breaking-Change-Heavy | Defer | Major version jump requiring the new root API (createRoot) and auditing all components for concurrent-rendering side effects. Given your stated capacity of 2-3 upgrades this sprint, this is too large to absorb alongside the security fix — defer to the dedicated tech-debt sprint. |
Do This Sprint (respecting stated capacity of 2-3 upgrades):
- auth-token-lib (security-critical, mandatory)
- lodash (near-zero risk, low effort)
- express (routine, moderate confidence)
Clarifying question before greenlighting axios 1.x: Do you have integration test coverage on every code path that calls axios directly, or only on the handful of endpoints your team remembers using it? A breaking-change-heavy upgrade is far riskier in code paths without test coverage, since you won't catch a broken call signature until it fails in production.
Every engineering team accumulates a backlog of outdated dependencies, and almost every team handles it the same unsatisfying way: someone glances at the `npm outdated` output, feels briefly guilty, and moves on to feature work. The problem isn't a lack of awareness — it's that turning a list of thirty-plus packages into an actual prioritized plan takes real time, and that time competes directly with shipping. This prompt is built to compress that triage work into a single pass.
Why this prompt is structured the way it is
The constraint requiring the model to treat any known CVE as automatically highest-priority, regardless of stated team capacity, exists because security fixes are the one category of dependency work that isn't actually optional. A prompt that let "limited capacity" silently deprioritize a security patch would be actively dangerous to rely on — the whole point of automating this triage is to make sure nothing important slips through, not to launder a convenient excuse to skip it.
The distinction between "this WILL break something" and "this MIGHT break something" is the most important constraint in the whole prompt, and it's there because the single most common failure mode of AI-assisted planning is false confidence. A model that's given a changelog excerpt confirming a breaking API change is on solid ground. A model asked to guess whether a version bump without documentation is safe is doing something fundamentally less reliable — and if both get presented with the same confident tone, the plan becomes actively misleading. Forcing the model to flag which category each assessment falls into means you know exactly which recommendations to trust at face value and which ones warrant a five-minute changelog check before you commit to them.
The capacity constraint is what turns this from a generic dependency report into an actual sprint-planning tool. A risk assessment that ignores how much work your team can realistically absorb this week is advice for a hypothetical team, not yours. Forcing the "Do This Sprint" shortlist to respect a stated capacity number means the output is something you can hand directly to sprint planning instead of translating yourself.
Why the table format matters
A ranked table, rather than a narrative writeup, is deliberate. Dependency triage is fundamentally a comparison task — you're weighing several packages against each other to decide what fits in limited capacity — and a table lets you scan and re-sort mentally in a way a paragraph-per-package format doesn't. The closing clarifying question about test coverage exists because the biggest hidden risk in any breaking-change upgrade isn't the change itself, it's whether you'll actually notice if it breaks something — and that's a question the model can prompt you to answer but can't answer on your own codebase.
How to adapt it
For a codebase with genuinely poor changelog access (private packages, abandoned open-source projects with sparse release notes), expect more items to land in the "MIGHT break something" category by default — that's the prompt working correctly, not failing. In that situation, it's worth pairing the output with a quick check of each package's GitHub issues for recent bug reports before finalizing the sprint plan.
For teams running this quarterly rather than per-sprint, swap the capacity framing from "this sprint" to "this quarter," and consider asking for a second pass that groups packages by shared underlying framework (e.g., "all React ecosystem packages") since major version bumps in a core framework often force related packages to update in lockstep anyway.