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.
Context7
GitHub
SlackEngineeringResearch & MonitoringNotifications & AlertsWhenever 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.
What does this prompt do?
- 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 do I need to use this?
- 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
How can I customize it?
- 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.
FAQs
Does this work with Dependabot and Renovate?
Will it merge anything for me?
How is this different from just asking an AI chatbot whether an upgrade is safe?
What happens if a library cannot be found in the documentation source?
Can it handle a pull request that upgrades several libraries at once?
Related templates
When your flight moves, your calendar times get corrected automatically and you get a Slack note naming the meetings you're about to miss.
Every 15 minutes, forwarded phishing reports get traced back to the server that really sent them, with a verdict in Slack and the worst senders reported.
Every weekday at 7am, sign in to the tender portals you track, filter new notices against your bid criteria, and open a deal for the ones worth chasing.
When you merge a fix in GitHub, this agent checks the matching dead-letter queue, replays the failed messages, and reports back on the pull request and in Slack.
Every Monday, rank the week's matches by expected demand, put the big ones on your venue calendar, and post a rota-ready summary to Slack.
Every Tuesday we pull your best new reviews, draft social captions, email testimonials and product page quotes, then stage them in Notion for approval.
Stop reading release notes just to approve a version bump.
Every dependency upgrade arrives with its own risk brief, grounded in the documentation for the version you are actually installing.