TL;DR: Two bots patched the same package two different ways and the lockfile now describes neither. Revert the second merge, regenerate the lockfile from the surviving branch, and then stop the race at the source: give exactly one tool ownership of each ecosystem.

```text
snyk and dependabot both opened PRs for the same lodash CVE - the agent merged both and the lockfile broke
```

## Steps

1. Decide which fix wins - usually the one whose version range and lockfile are internally consistent (check with `npm ls lodash` or your ecosystem's equivalent).
   Expected: one clear winner, one PR to revert.
2. Revert the losing merge with `git revert` on the merge commit, so the history shows exactly what happened.
   Expected: the tree is back to the single-fix state.
3. Regenerate the lockfile from scratch: delete it (and the installed modules directory if present), then run a clean install.
   Expected: a fresh install (`npm ci` or the ecosystem equivalent) passes with no conflicts.
4. Run the test suite.
   Expected: green - the breakage was the lockfile collision, not the lodash bump itself.
5. Stop the next race: pick one owner per ecosystem. Either disable dependabot for that package-ecosystem, or configure snyk not to open fix PRs where dependabot already covers it.
   Expected: the next lodash CVE produces exactly one PR.

## Use this when

- Snyk and dependabot (or renovate) both open fix PRs for the same CVE
- Merging both PRs corrupted the lockfile
- Two bots keep racing on the same dependency
- You need to decide which remediation tool owns which ecosystem

## Not for this skill when

- Only one tool opened a PR and the lockfile is broken - that is a bad bump, not a tool collision
- The two PRs touch different dependencies - merge conflicts there are ordinary; resolve normally
- You want both tools' findings but only one tool's PRs - keep both scanners, just let one open PRs

## Variant phrasings

- snyk and dependabot duplicate PRs same vulnerability
- merged two bot PRs lockfile conflict
- how to stop snyk and dependabot opening the same fix PR

## Why it happens

Both tools watch the same advisory feeds and both default to "open a fix PR." Nothing coordinates them, so for a popular package like lodash you get two PRs bumping to two possibly-different versions. Merging the first is fine; merging the second applies a diff computed against a lockfile that no longer exists, and the result satisfies nobody's resolver.

## Edge cases

- The two PRs may target different fixed versions (one bumps to 4.17.20, the other to 4.17.21) - pick the higher fixed version that your tests pass on.
- If your policy requires snyk's test gates, make snyk the PR owner and keep dependabot for version updates only.
- Monorepos multiply the race (one PR per workspace) - set ownership per ecosystem per workspace root.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AiQT3E_oWYu_m5q6bihtew