Use dependency-upgrade-review

Give a merge verdict on a dependency-upgrade pull request (Dependabot, Renovate or a hand-made bump) across npm, pip, Go, Cargo and Maven lockfiles and GitHub Actions…

Give a merge verdict on a dependency-upgrade pull request (Dependabot, Renovate or a hand-made bump) across npm, pip, Go, Cargo and Maven lockfiles and GitHub Actions pins. Reads the release notes for every skipped version, lists what the lockfile changes beyond the PR title (transitive bumps, new and removed packages, install scripts, registry changes), checks each SHA pin against its release tag and against the PR's other pins, checks raised runtime floors against the images and runners that install it, says whether CI ran the changed code, traces what each caller of a changed API now does and writes the rollback. The reply leads with MERGE, MERGE AFTER CHECKS or DO NOT MERGE and the reasons that decide it.

Reach for it when the user says "review this Dependabot PR", "is this Renovate bump safe to merge", "can I merge this dependency upgrade", "check this lockfile diff", or "is this action SHA pin right".

Install it

npx skilldrop-cli install dependency-upgrade-review                 # Claude Code, your user folder
npx skilldrop-cli install dependency-upgrade-review --project       # Claude Code, this repo
npx skilldrop-cli install dependency-upgrade-review --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Dependabot wants to bump express from 4.19 to 5.0, can I merge the PR?"
• "review this Renovate PR, it updates 14 packages in package-lock.json"
• "is this actions/checkout SHA pin in the dependabot PR actually the v4.2.2 commit?"
• "I bumped pydantic and regenerated poetry.lock, anything in the lockfile diff I should worry about before merging?"
• "check this go.mod / go.sum diff from the deps update PR, CI is green"

Requests like these belong to a different skill, so it shouldn't answer them:

• "review my PR that adds rate limiting to the checkout API before I merge"
• "write the release notes for our 3.2.0 release from the merged PRs"
• "plan our migration from React 17 to React 19 across the four frontend apps"

If another skill answers instead, ask for this one by name: "use dependency-upgrade-review".

Check what you get

A good result:

• The first line is the verdict and the reasons that decide it, one verdict per PR, following from the checks. Any unverified SHA, added install script, or removed API still in use rules out MERGE.
• Every release between old and new is accounted for: read, with its breaking changes, runtime drops, deprecations, security fixes and licence changes, or named as unread.
• Everything the lockfile changes beyond the title is listed, in one line: transitive bumps, added and removed packages, install scripts, native code, source and runtime changes.
• Every changed API has a search result and every hit is traced: what the caller does now and the fix, or the search command when there is no repo.
• Every raised runtime floor is compared with the base image, the CI runtime, the runners and the lockfile tool's runtime.
• Every changed SHA pin is verified or given as the git ls-remote command, and the PR's pins are compared with each other.
• CI coverage is named per changed package: the job and test that exercise it, or "nothing does", and how each workflow installs.
• A rollback with the exact command and what a revert does not undo.
• Nothing reads as checked that was not run, and nothing describes the session's tools or network.
• No invented versions, advisories, APIs, files or test names; version numbers are copied from the notes.

See a worked example

• ledgerline tidyparse

Use something else when

• Reviewing a PR whose substance is the repo's own code change: use pre-merge-review
• Writing the release notes or changelog for this project's next version: use release-notes
• Planning a multi-step framework or runtime migration (a major framework version across many services): use migration-plan
• Scanning installed skills for supply-chain patterns: that is the skilldrop scan command
• Choosing which library to adopt in the first place: this reviews a version change, not a selection

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: migration-plan, pre-merge-review, release-notes

Edit this page on GitHub · View source