TL;DR: Do not revert the whole PR and do not guess - bisect it. Check out the branch, reproduce the failing CI job locally, and binary-search across the dependency changes until one bump is left standing. Merge everything else, quarantine the breaker.

```text
the grouped security-update PR failed CI with 200 changed files - the agent couldn't tell which bump broke the build
```

## Steps

1. Identify the failing CI job and reproduce it locally on the PR branch (same test command, clean install first).
   Expected: the failure reproduces outside CI - if it does not, the problem is the CI environment, not the bumps.
2. List the dependency changes in the PR by diffing the lockfile, grouped by package.
   Expected: a finite suspect list, far shorter than 200 files once each bump is collapsed to its package.
3. Bisect: check out the base, apply half the bumps, install, run the failing test; repeat on the failing half. With a lockfile this means editing the manifest in halves and reinstalling each step.
   Expected: after a handful of iterations, one bump remains that reproduces the failure alone.
4. Confirm the culprit by applying only that bump on a clean base and running the test.
   Expected: red with the bump, green without - proof, not suspicion.
5. Merge the PR minus the culprit (revert just that bump's manifest change), and open the culprit as its own PR with the CI failure linked.
   Expected: the security updates land now; the breaking bump gets its own review and timeline.

## Use this when

- A grouped update PR fails CI and the diff is too large to read
- Multiple bumps landed together and one of them breaks tests or the build
- You need to decide between revert-all and finding the culprit
- Renovate or dependabot grouped PRs keep going red as a unit

## Not for this skill when

- CI fails identically on the base branch - the breakage predates the PR; fix the base first
- The failure is a lockfile merge artifact (two bots collided) - regenerate the lockfile instead
- Only one dependency changed - test that bump directly, no bisect needed

## Variant phrasings

- how to find which dependency update broke CI in a grouped PR
- bisect renovate grouped PR failure
- dependabot grouped security update failed tests which package

## Why it happens

Grouping trades review cost for blast radius: twenty bumps in one PR means twenty suspects when CI goes red, and lockfile diffs hide which package actually changed behavior. Teams then either revert everything - losing the security fixes - or merge blind. Bisection is the mechanical way out: it treats the bumps as a suspect list and halves it until one remains.

## Edge cases

- Two bumps can interact (A breaks only with new B) - if single-bump tests all pass, test pairs from the failing half.
- Flaky tests poison bisection - verify the failing test is deterministic on the base before you start, or every bisection step lies.
- Native modules and lockfile-only changes reinstall slowly - budget the time; a 6-step bisect with slow installs still beats guessing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sWEv9tYvkWsHOkZs6V-R7g