# Risk-check every dependency upgrade pull request in GitHub

> When a bot opens a version bump pull request, we read the real documentation for that exact version and tell you whether it is safe to merge.

- Workflow type: agent
- Services: Context7, GitHub, Slack
- Categories: Engineering
- Published: 2026-08-04

## What it does

- Watches for the automated version bump pull requests your dependency bots open, and picks out every library being upgraded along with its old and new version.
- Looks up the actual documentation for the new version of each library, focused on breaking changes, removed features and migration steps.
- Grades each upgrade low, medium or high risk based on what the documentation really says, not on guesswork.
- Posts the full brief as a comment on the pull request, and alerts your engineering channel whenever something grades high risk.

## What you'll need

- A GitHub account with access to the repository where your upgrade pull requests land
- Automated dependency updates already switched on, such as Dependabot or Renovate
- A Context7 account for up to date library documentation
- A Slack workspace and the channel your engineering team watches

## Prompt

Whenever a new pull request is opened in GitHub, I want an agent to tell me whether it is safe to merge. Use a webhook trigger on new GitHub pull requests. First work out whether the pull request is a dependency upgrade, which is normally one raised by Dependabot or Renovate with a title like "bump react from 18.2 to 19.0" or "chore(deps): update dependency lodash to v4.17.21". If it is not a dependency upgrade, stop and do nothing.

For dependency upgrade pull requests, call the GitHub Get a Pull Request operation to read the full title, body and diff statistics. From that content, extract every library being upgraded along with its old version and its new version. A single pull request often bumps several libraries at once, so build a list and handle each one separately.

For each library on the list, resolve it in Context7 before researching it. Call Search for Libraries with the package name to get the Context7 library ID, which is path shaped, for example /vercel/next.js. Pick the best matching result rather than assuming the ID. Then call Get Documentation Context against that library, pinning the new version by appending it to the ID as a version suffix, for example /vercel/next.js/v15.1.8. Ask specifically about breaking changes, removed or renamed APIs, deprecations and the migration steps between the old version and the new version.

Grade every library upgrade as low, medium or high risk, and base that grade on what the documentation actually returned rather than on general knowledge about the package. Low means no breaking changes that affect normal usage. Medium means deprecations or behavior changes that probably deserve a look. High means removed or renamed APIs, required migration steps, or changes that will break a build. If Context7 cannot resolve a library, or returns nothing useful for that version, mark it as unreviewed and say so plainly instead of inventing a grade.

Post the finished brief back onto the pull request with the GitHub Create an Issue Comment operation, using the pull request number. The comment should list each library with its old and new version, its risk grade, a short summary of the relevant breaking changes and migration steps drawn from the documentation, and an overall recommendation on whether it is safe to merge. Keep it tight enough that a reviewer reads the whole thing in under a minute.

If any library in the pull request grades as high risk, also send a message to our engineering Slack channel using the Slack Send a Message operation. That message should name the repository, link to the pull request and say which library is the problem, so a human looks at it before anything gets auto merged. Do not send a Slack message when everything came back low or medium risk.

The whole point is that the risk call is grounded in real version specific documentation rather than a model guessing from memory, so never grade an upgrade without having pulled the documentation for that version first.

## How to customize

- Change what counts as high risk, for example treat every major version jump as high risk automatically.
- Pick which Slack channel gets the alert, or only escalate for your most important repositories.
- Narrow the review to the libraries that ship in production and skip developer only tooling.

## FAQ

### Does this work with Dependabot and Renovate?

Yes. It reacts to pull requests opening in your repository, so whichever bot raises your version bumps, the review runs the same way. It also covers upgrade pull requests a person opens by hand.

### Will it merge anything for me?

No. It only reads the pull request and leaves a comment with its recommendation. A person still clicks merge, which is exactly the point when something grades high risk.

### How is this different from just asking an AI chatbot whether an upgrade is safe?

A chatbot answers from memory, so it can be out of date or simply wrong about a version released after it was trained. This reads the current documentation for the exact version in the pull request before it makes a call.

### What happens if a library cannot be found in the documentation source?

That upgrade is flagged as unreviewed in the comment rather than guessed at, so you know to check that one yourself instead of trusting a made up grade.

### Can it handle a pull request that upgrades several libraries at once?

Yes. Every library in the pull request is researched and graded separately, and the comment lists them all along with one overall recommendation.

Use this prompt in General Input: https://www.generalinput.com/prompts/risk-check-every-dependency-upgrade-pull-request-in-github