TL;DR: Stop automerging the two packages and put them in one Renovate group so they land as a single PR. The pair can never settle independently because A's range requires B 2.0 or newer while B's range requires A older than 3, so alternating merges are the only possible outcome. Find one pair of versions that satisfies both constraints, merge it once by hand, then re-enable automerge on the group.

```text
A needed B>=2 but B needed A<3, and the agent merged them alternately all day
```

1. Pause automerge for both packages. Add a packageRule matching the two packages with automerge turned off, or apply a manual-approval label the bot respects.
   Expected: no new automerge runs pick up either package; the flipping stops immediately.
2. Put both packages in one Renovate group (same groupName in the packageRule) so the bot opens a single PR instead of two competing ones.
   Expected: one PR appears touching both A and B, replacing the two flip-flopping PRs.
3. Resolve a compatible pair by hand: pick a version of A older than 3 and a version of B at 2.0 or newer such that each satisfies the other's peer range. Read both packages' peerDependencies to confirm.
   Expected: one concrete version pair that satisfies both ranges at once.
4. Push the pinned pair on the grouped branch and merge it manually with CI green.
   Expected: CI passes, the flip-flop stops, and no new PRs appear for either package.
5. Re-enable automerge only after confirming both packages' constraints stay satisfiable, and keep them grouped going forward.
   Expected: future bumps arrive as one grouped PR that can actually merge.

## Use this when
- Renovate automerge merges two PRs back and forth, each undoing the other
- Two dependencies constrain each other's version ranges (A needs B newer, B needs A older)
- The agent "merged them alternately all day" with no progress
- Peer ranges that cannot both float independently

## Not for this skill when
- Dependabot PRs are flipping (different tool, different grouping model)
- npm fails at install time with an ERESOLVE peer conflict (install-time resolution, not PR scheduling)
- A single upgrade PR fails CI for an unrelated reason
- Lockfile churn with no version-range coupling between the packages

## Variant phrasings
- renovate merged A then B then A again, undoing itself each time
- two renovate PRs undoing each other in a loop
- automerge loop between interdependent packages
- peer range conflict spread across two renovate PRs

## Why it happens
Automerge treats each PR as independent, but the version constraints couple them: merging A's bump invalidates B's range and merging B's bump invalidates A's. Without a group, the scheduler has no way to see the pair as one decision, so it just keeps alternating. This is a planning problem, not a test problem: no amount of green CI fixes mutually exclusive ranges merged separately.

## Edge cases
- If no version pair satisfies both ranges, the dependencies are genuinely incompatible: one must be replaced or a range widened upstream. Grouping cannot fix that.
- Keep the group to exactly the coupled packages; grouping unrelated majors recreates the "which bump broke CI" problem.
- Check the grouped branch name is stable so CI caches survive across the bot's rebases.
- If other open PRs depend on either package, sequence them after the grouped merge lands.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_y79NTbKB-0HsGxb6umT9Lg