TL;DR: Your matchPackagePatterns matched everything, so renovate did exactly what you asked and grouped everything. Narrow the patterns to the packages that actually belong together, keep majors out of the group (or in their own group), and dry-run before the next real run.

```text
renovate grouped 12 unrelated major bumps into one PR - the agent's grouping pattern was too greedy
```

## Steps

1. Find the offending rule in your renovate config - look for a packageRule with a broad matcher like `matchPackagePatterns: [".*"]` combined with a `groupName`.
   Expected: one rule matching far more packages than intended.
2. Replace the greedy pattern with explicit package names or a tight prefix, e.g. `matchPackageNames: ["lodash", "underscore"]` or a pattern scoped to your own org prefix.
   Expected: the rule now names the family it is actually for.
3. Decide what majors do: add `matchUpdateTypes: ["minor", "patch"]` to the group so majors stay out, or give majors their own groupName.
   Expected: majors arrive separately, where their breaking changes are reviewable.
4. Dry-run the config and inspect the planned PR list (renovate supports a dry-run mode; the hosted app also exposes debug logs per run).
   Expected: the 12 packages split into sensible groups or individual PRs instead of one mega-PR.
5. Apply and watch the next run.
   Expected: grouped PRs you can actually review, each with a coherent blast radius.

## Use this when

- One renovate PR bundles unrelated packages together
- A grouping rule uses `*` or `.*` style match-everything patterns
- Major bumps got swept into a group with minors and patches
- CI fails on a grouped PR and nobody can tell which package caused it

## Not for this skill when

- Renovate is not grouping at all (every bump separate) - that is a missing groupName problem, the opposite fix
- The grouping is dependabot's, not renovate's - different config, different fix
- The 12 bumps are genuinely related (one framework's ecosystem) - the grouping is correct, the PR is just big

## Variant phrasings

- renovate packageRules grouped too many packages
- renovate one PR for all major updates - how to split
- matchPackagePatterns too broad renovate

## Why it happens

Renovate's grouping is purely pattern-driven - it has no notion of "related" beyond what your matchers say. A match-everything pattern is a promise that every package belongs together, and renovate keeps that promise literally. Majors make it worse: twelve unrelated breaking changes in one PR means twelve suspects when CI goes red.

## Edge cases

- `matchPackagePatterns` is regex, not glob - `.*` is the "match everything" footgun; scope it or replace it with `matchPackageNames`.
- Grouping interacts with scheduling: a group with mixed schedules waits for the slowest member - keep schedules consistent inside a group.
- Lock-file-only updates can sneak into groups - decide whether they belong or get their own rule.

## Provenance

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