TL;DR: Reproduce the conflict locally with bundler, find which gem's requirement blocks the bump, then split the group so the conflicting gems update separately. Grouped updates ask bundler to satisfy every gem's constraints at once, and one overly tight pin breaks the whole set. Smaller groups resolve cleanly.

```text
Bundler::VersionConflict
```

1. Reproduce it where you can see the full message. In the repo, run `bundle lock --update` on the group members, or `bundle update` naming the gems dependabot tried to bump.
Expected: bundler fails with the same VersionConflict, and the output names the gem whose requirement cannot be satisfied. That gem is your culprit.
2. Read the conflict: find which gem declares the pin and what version range it demands.
Expected: you can point at one declaration, like gem A requiring gem B below some version, that contradicts the bumped version.
3. Split the group in your dependabot config. Move the pinning gem (or the blocked gem) into its own group so they resolve independently, or schedule the pinning gem's own update first.
Expected: each smaller group resolves on its own; the security bump lands without dragging the conflicting constraint along.
4. Let dependabot re-run the groups.
Expected: the grouped PRs open with clean lockfiles instead of the conflict error.

## Use this when
- a dependabot group of Ruby gems fails with Bundler::VersionConflict
- the same gems update fine individually but not together
- the conflict names a gem you did not intend to hold back

## Not for this skill when
- a single-gem update fails the same way; that is a genuine unsatisfiable constraint in your Gemfile, not a grouping problem
- the error is a network or registry failure during the bundler run
- your lockfile is fine and CI fails later; that is a test failure, not a resolution failure

## Variant phrasings
### dependabot group bundler could not resolve dependencies
### grouped dependabot PR fails version conflict ruby
### dependabot security group Bundler::VersionConflict
### split dependabot group to fix bundler conflict

## Why it happens
Bundler resolves the entire dependency graph as one constraint problem. A group tells dependabot to bump several gems in a single resolution, so every gem's version requirements must hold simultaneously. One gem pinning a shared dependency below the version another gem's security fix requires makes the whole set unsatisfiable, even though each bump would resolve fine on its own.

## Edge cases
- The bundler version dependabot uses may differ from yours; if you cannot reproduce locally, check the bundler version in the dependabot job log before trusting your local result.
- Platform-specific gems in the lockfile can make a resolution that works on your machine fail in dependabot's environment; keep the platforms block in the lockfile current.
- Updating the pinning gem first often dissolves the conflict, but watch for that gem's own breaking changes before merging it just to unblock the group.
- If the pin comes from a transitive dependency you do not control, the split-group approach is the durable fix; waiting for upstream to loosen the pin can take months.

## Provenance

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