Audit outdated dependencies for upgrade risk before touching anything
Category: Audit · Updated 2026-09-22 · Tools: Both
Use this before a dependency-upgrade push, especially on a repo that's been pinned for a while and has several majors behind. Helps you sequence upgrades by risk instead of doing them in whatever order the lockfile lists them. Medium usage — it involves reading changelogs, which can be a lot of text per dependency.
Full prompt
List every dependency in this project that's behind its latest stable version. For each one that's more than a patch version behind, check its changelog or release notes between the current pinned version and latest for breaking changes, deprecations, or notable behavior changes relevant to how this project actually uses it (not just a generic "breaking changes exist" flag — check whether the specific APIs this project calls are affected). Rank each dependency's upgrade risk as low/medium/high with a one-line reason. Do not change any dependency versions or lockfiles — this is a report only. Present it as a table sorted highest-risk first, plus a separate “safe to batch-upgrade now” list for the low-risk ones.
Tips
- Ask it to check whether the APIs *this project actually calls* are affected, not just whether the changelog mentions breaking changes somewhere — that's what keeps the risk ranking meaningful instead of generic
- The "safe to batch-upgrade now" list is the actually actionable output — use it to knock out the easy wins immediately and spend more careful attention on the high-risk ones separately
- Re-run this periodically rather than once — the risk picture for a specific dependency shifts as new versions ship
Still waiting on a reset? See what to do when you hit the limit, or check Codex / Claude time since last reset.
Back to the prompt library · Subscribe: all-products feed