Risk-check every dependency upgrade pull request in GitHub

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.