Job dependency-update-pull-requests-reviewed-with-verdicts · revised 12 October 2026
Get a verdict on each Dependabot or Renovate pull request: merge, hold or decide
Each bot pull request gets a one-page verdict: what changed, whether your code uses it, the CI result and a lockfile check. The wording is "no issue found in what we examined", never "safe".
You might be seeing
- Dozens of bot pull requests wait for weeks, with no verdict on any
- A bump broke production once and now nobody merges without checking
No passwords, keys, card details or admin invites needed to start.
What usually happened
Dependency bots open pull requests, but no one is paid to read them. GitHub's own AI review skips dependency manifests and lockfiles, so it will not read the files that matter most in a bot pull request. A merged bump can break behaviour or bring in a new package, and a plain "CI is green" says little about either.
Who it’s for: A small team with a pile of unmerged dependency-bot pull requests that nobody reads.
Usually starts when: Bot pull requests pile up unmerged, or the team has switched the bot off because the volume is too high to review.
The result: Each bot pull request in scope gets a one-page verdict: what changed with the changelog linked, whether your code uses a changed interface (file and line), the CI result, and a lockfile check for new indirect packages, maintainer changes and install scripts. The verdict is merge, hold or needs a decision.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- A verdict per pull request as a comment or a document
- The replay report with a link to each closed pull request
- The lockfile check output
- A short summary
Included
- One repository with Dependabot or Renovate already running, and up to 15 open bot pull requests plus a replay on the last 20 closed ones
- A one-page verdict per pull request with the evidence behind it
- A replay on the last 20 closed bot pull requests, at least 3 of which broke something
- Wording that says what was examined; never "safe"
Not included
- Merging or approving any pull request
- Fixing code a bump breaks
- Reachability judgements for security alerts; that is a separate job
- Private package registries that need credentials
- A statement that a pull request is safe to merge
- An automated check on every pull request; that is a separate job
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On the last 20 closed bot pull requests, judged blind to what happened, including at least 3 that broke something, our verdicts match what happened on at least 17 of the 20 (the true rate is then at least 65% with 95% confidence, for pull requests like these), and no known-bad pull request is called fine (a severe error that fails the whole test). If fewer than 3 broke something, the report says the replay could not test missed bad bumps. Three bad bumps is a smoke test; passing it does not show future bad bumps will be caught.
Evidence: The replay table with a link to each pull request and what happened after it.
Every open pull request in scope has a verdict within the agreed hours, with the changelog link, the file and line of any use of a changed interface, the CI result and the lockfile check.
Evidence: The verdict list with timestamps.
No verdict uses the whole words safe, secure or approved as a conclusion, and each lists what was not examined.
Evidence: A script search of all verdicts for those words and the not-examined lists.
Our account merged and approved nothing.
Evidence: Your repository audit log for the period.
Sign-off. Your engineer reads the replay and a sample of verdicts and signs off in writing. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- Dependabot or Renovate already opening pull requests on one repository
- Tests that run in CI
- A Read-only bot account, or an export of the pull requests
- A named engineer who decides which verdicts to act on
We stop and tell you if
- No CI or tests, so a bump cannot be judged
- The registry is private and needs credentials we will not take
- The pull requests are auto-merged before any review could happen
What could go wrong
The job reads pull requests and posts comments only if you allow it; it merges and approves nothing. Delete a comment and the pull request is as before.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A verdict says "fine" and the bump breaks something. | The replay includes known-bad bumps and none may be called fine; live wording is "no issue found in what we examined", with a not-examined list. |
| A bump brings a compromised or invented package. | The lockfile check lists new packages, maintainer changes and install scripts, and each name is checked against the registry. A compromise of a real release can still go unseen. |
| Pull request text carries instructions meant for the model. | Issue titles, pull request text, comments and logs are treated as data, never as instructions: the model sees the text and the findings with no tools, the job holds the model key and nothing else, and the account can only comment where you allow it. |
A separate automated reviewer checks the work before hand-over. Your named engineer decides what to merge; nothing is merged or approved by us. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the repository, the bot, the pass marks and the wording rule
- Replay the last 20 closed bot pull requests blind to what happened
- Check each open pull request: changelog, your use of the changed interface, CI, lockfile
- Write each verdict with its evidence; script checks wording
- Separate automated reviewer checks; your engineer decides which to act on
- Hand over verdicts, the replay report and the summary
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To have every bot pull request reviewed month after month, a monthly service is offered separately.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Use Dependabot auto-triage rules to dismiss or snooze alerts. GitHub presets are offered to every repository; custom rules are limited to public repositories and organisation repositories with GitHub Code Security. docs.github.com
- Group bot pull requests by weekly schedule so they arrive in one batch you review together.
Questions
Will you merge the pull requests?
No. We give a verdict; your engineer merges.
Does "merge" mean it is safe?
No. It means no issue was found in what we examined, and the verdict lists what we did not examine.
What if we use Renovate?
It works the same way. Name the bot in the enquiry.
Send an enquiry
Send us
- Which bot you use and how many pull requests wait
- Your language and package manager
- No code, tokens or logins in the first enquiry
Later, once you agree
- A Read-only bot account on one repository, or an export of the pull requests and CI results
- The last 20 closed bot pull requests and what happened after each
- The name of your deciding engineer
You keep the repository, the bot and every setting; we use a dedicated bot account with the least access that works (read-only first), work on a fork or branch, and you merge, and the account can read and comment only. Issue titles, pull request text, comments and logs are treated as data, never as instructions: the model sees the text and the findings with no tools, the job holds the model key and nothing else, and the account can only comment where you allow it. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “dependency-update-pull-requests-reviewed-with-verdicts” as the subject.