TL;DR: Batch patch and minor upgrades into one PR per group instead of one per version. Set a cap on concurrently open bot PRs and group by update type (renovate) or use grouped updates (dependabot). Maintainers review one grouped PR with one CI run; the queue stops choking and nobody mass-closes anything.

```text
dependabot-style agent opened one PR per patch version: 30 PRs in a day, the CI queue choked and maintainers mass-closed them
```

1. Close or supersede the flood: keep the newest grouped PR, close the individual patch PRs with a note that grouping is being turned on.
   Expected: one open upgrade PR per group instead of 30.
2. Add grouping by update type. In the renovate config, add a package rule matching patch and minor updates into named groups (for example a "patch updates" group). In the dependabot config, use groups for the same effect.
   Expected: the next scheduled run opens at most one PR per group.
3. Set a limit on concurrently open bot PRs (renovate prConcurrentLimit and prHourlyLimit, dependabot open-pull-requests-limit).
   Expected: even a misconfigured rule cannot open more than N PRs.
4. Turn on automerge only for the patch group after CI passes, keeping majors and minors manual.
   Expected: patches land silently; reviewers only see what matters.
5. Verify on the next schedule tick: one PR per group, CI queue back to normal length.
   Expected: CI minutes drop and there are zero mass-closes.

## Use this when
- your agent or bot opens a separate PR per dependency version
- maintainers close bot PRs without reviewing them
- CI queue times spike on upgrade days
- patch and minor bumps drown out majors that need human eyes

## Not for this skill when
- the problem is merge conflicts in a single PR, not PR count
- CI is slow on every PR regardless of bot activity (fix CI capacity, not grouping)
- you need per-version test matrices for security patches (grouping may hide a bad patch version)

## Variant phrasings
- "renovate opened 40 PRs overnight and CI fell over"
- "dependabot spam: one PR per patch version"
- "how to group dependabot updates into a single PR"
- "bot PR flood choking CI queue"
- "too many upgrade PRs, reviewers closed them all"

## Why it happens
Default bot configs optimize for granularity: one PR per dependency per version, because isolated changes bisect cleanly. That works until the schedule fires and 30 patch releases drop at once. Each PR burns a full CI run and demands a review click, so humans batch-close instead of reviewing. Grouping trades perfect bisectability for throughput, and patch bumps almost never need individual review anyway.

## Edge cases
- Grouping patch with minor in one PR means a bad minor release hides among clean patches; keep patch and minor in separate groups if you bisect failures often.
- Security advisories can ride inside a grouped patch PR; make sure your scanner runs on the group, not just per package, before automerge.
- Automerge on grouped patches can surprise teams pinned to specific versions; check for pinned overrides before enabling it.
- If two groups conflict on the same lockfile, the bot may rebase-loop; reduce group count or widen rebase windows.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2LNMztyTJe7PM8N-E61PiQ