How do I judge the risk of a dependency upgrade…

An automated pull request lands with fourteen version bumps and a green check. The check only tells you that the tests passed. It does not tell you whether the tests cover the thing that just changed.

The useful question is: which of these upgrades could break something we actually use, and in what order should we merge them? That takes reading release notes, which nobody wants to do for fourteen packages. An assistant can do the reading, if you hand it the notes and make it quote them.

What you need

The list of bumps: the diff of your package.json and lockfile, or your pyproject.toml, or the pull request description.
The release notes or changelog for the packages that jumped a major version. Paste the relevant section.
A rough idea of which of these libraries your code uses heavily.

What the version numbers tell you

Many projects use semantic versioning, which the semver.org specification describes as MAJOR.MINOR.PATCH. Increase the major version for incompatible API changes, the minor for functionality added in a backward compatible way, and the patch for backward compatible bug fixes. Version 0.y.z is for initial development, and anything may change at any time. That is a convention, not a guarantee, and plenty of projects do not follow it strictly. Read the spec here: https://semver.org/

The prompt

Paste this into a new chat, then paste the bumps and the release notes.

I am reviewing a dependency upgrade. Work only from the text below. Never invent a breaking change, a version or a link.

1. Table of every change: package, old version, new version, and the kind of bump (major, minor, patch, or 0.x, where anything may change). Mark added and removed packages.
2. For each major or 0.x bump, quote the breaking-change lines from the release notes I pasted. If I pasted none, write "no notes provided". Do not summarise from memory.
3. Tell me which of my code to search for each quoted breaking change (names of functions, options or config), so I can grep for it.
4. Rate each package high, medium or low risk and give the reason. Never say an upgrade is safe.
5. Suggest an upgrade order (smallest risk first, related packages together), a test plan and a rollback step.

THE BUMPS:
[paste here]
RELEASE NOTES:
[paste here]

How to check the result

Check the table against the real diff. Then check every quote against the release notes. If a quote is not in the notes, remove it.

Run the searches the assistant suggests in your own code. This is where the risk becomes real: a breaking change in a function you never call costs nothing.

Merge in small steps, in the order suggested, and run your tests between steps. Keep the rollback step where you can find it.

What good output looks like

This is an invented illustration of the shape. A table row reads: "example-lib, 3.4.1 to 4.0.0, major." The quoted line reads: "The parse option is removed; use parseMode instead." The search suggestion reads: "grep for parse: in calls to example-lib." The rating reads: "High: your code uses the removed option in two places, if the grep finds them."

Notice that the rating depends on a search you run, not on the assistant's opinion. A package with a scary changelog can be low risk for you, and a quiet one can hit a feature you rely on.

Merge the lowest-risk bumps first, together if they are patch updates in related packages, and keep each major bump in a change of its own. When something breaks, you will know which upgrade did it.

Limits

It only knows the notes you paste. It cannot read the package's source or browse for you.
A patch bump can still break you. The rating is a reading, not a promise.
It cannot see how your code uses a library, only what you tell it.
It does not run your tests.

Browse all skills in the catalog