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.
Additional information
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
New roof inspection requests from your website form land in JobNimbus within a minute, with no duplicate records and nothing retyped by your team.
Every new customer request gets a priority, triage labels, a friendly reply with the right help article, and a Slack ping only when it is truly urgent.
The moment a deal hits Closed Won, the right contract starts in Ironclad, the link lands on the deal, and your sales channel hears who owns the next step.
When someone asks a library or framework question in your help channel, they get a straight answer with working code and a source link, right in the thread.
Every Monday, find contracts renewing or expiring in the next 90 days, post a ranked digest to Slack, and open Asana tasks for the ones that need a decision now.
Every Friday, spot the questions your team keeps answering by hand and get a ready-to-review help article drafted from real fixes.
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.