the agent's one PR per CVE policy created 15 PRs for one shared tra

Not specified by the original author.

TL;DR: Fifteen CVEs in one transitive dependency need one bump, not fifteen PRs. Group fix PRs by the dependency being changed - not by the CVE being closed - so a single upgrade PR resolves every ticket that traces to that root cause.

the agent's "one PR per CVE" policy created 15 PRs for one shared transitive dependency - grouping by root cause instead

Steps

1. Pick one of the 15 PRs and trace its CVE to the actual package being bumped: run npm ls on the suspect package, pipdeptree --reverse, cargo tree --invert, or follow your scanner's "introduced through" chain. Expected: the bump target is a shared transitive dependency, not the direct one named in the ticket.

2. Repeat the trace for a few more tickets. Expected: they converge on the same root package - that is your grouping key.

3. Change the policy: group remediation PRs by root-cause package. In dependabot, use a groups block keyed on that package's pattern; in renovate, a packageRule with matchPackageNames on the root dep and one groupName. Expected: the next scan produces one PR for the shared dep instead of fifteen.

4. Close the 14 duplicate PRs, keeping the one that bumps the shared dependency (or open a fresh single PR that does). Expected: one PR, fifteen linked tickets.

5. Link all fifteen CVE tickets to the single PR and let the merge close them together. Expected: the backlog drains by fourteen tickets with one review.

Use this when

• Many CVE tickets trace to the same transitive dependency
• Your agent opens one fix PR per CVE and they collide
• Reviewers are drowning in duplicate bump PRs
• You want the PR count to reflect the work, not the CVE count

Not for this skill when

• The CVEs genuinely need different fixes (different packages, different version lines) - those stay separate
• The shared dependency cannot be bumped without breaking dependents - that needs an upgrade plan, not a grouping fix
• The tickets are informational (no fix available) - grouping does not create a patch

Variant phrasings

• too many dependabot PRs for the same transitive dependency
• group security PRs by dependency instead of CVE
• one PR per CVE policy created duplicate fix PRs

Why it happens

"One PR per CVE" feels rigorous - every finding gets its own tracked fix. But CVEs are findings and dependencies are the things you change; the mapping is many-to-one. Fifteen tickets for one shared bump means fifteen PRs editing the same lockfile lines, which then conflict with each other. Grouping by root cause aligns the PR with the actual change.

Edge cases

• The shared dep may be pinned by different parents at different version ranges - one bump may not satisfy all fifteen; split by version line, not by CVE.
• Some CVEs in the group may be disputed or already fixed upstream - verify each ticket's fix version before assuming the bump closes it.
• If the root dep is unmaintained, the real fix is replacing it - say so in the group PR instead of bumping forever.

Provenance

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

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

Thread query: the agent's "one PR per CVE" policy created 15 PRs for one shared transitive dependency - grouping by root cause instead

TL;DR:

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR:

Not specified by the original author.

agent remediation pr changed 400 files: ci rejected it - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. The agent's remediation PR touched 400 files and CI rejected it, usually for size limits or merge conflicts. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

agent remediation pr changed 400 files: ci rejected it

Fix it step by step

Step 1

Set a file budget per agent PR: group fixes by rule, one rule per PR, and cap files per PR.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

Split the 400-file change into per-rule or per-directory PRs that reviewers can actually read.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Re-run CI per PR; small PRs pass gates that giant ones trip.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Add the budget to the agent's instructions so the next run chunks itself.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Bulk remediation is fine; bulk pull requests are not.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

Agent workflow guardrail; CI config file-budget or PR-size check.

Variant phrasings

agent remediation pr 400 files ci rejected

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

The agent's remediation PR touched 400 files and CI rejected it, usually for size limits or merge conflicts. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

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

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

Thread query: agent remediation pr changed 400 files: ci rejected it

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. The agent's remediation PR touched 400 files and CI rejected it, usually for size limits or merge conflicts. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.