agent opened the upgrade PR against the release branch instead of main — the bump shipped to production without review

Not specified by the original author.

TL;DR

The bump went to the release branch, which is the production line, instead of main where it gets full review. Retarget the PR to main (or cherry-pick the commit), review it properly, and teach the agent to verify the base branch before opening.

Error

agent opened the upgrade PR against the release branch instead of main  -  the bump shipped to production without review

Steps

1. Check whether the PR merged: if it is still open, change the base to main in the PR UI; if it merged, revert or cherry-pick the commit onto main. Expected output: The change lives on main with a proper review, and the release branch is clean.

2. Audit what shipped: if the release branch deployed with the unreviewed bump, verify the dependency behaves in production and note the incident. Expected output: You know exactly what production is running.

3. Add the base-branch rule to the agent's instructions: upgrade PRs target main unless the task explicitly says hotfix. Expected output: The agent states its intended base branch before opening.

4. Protect the release branch so only hotfix-labeled PRs from authorized users can merge. Expected output: A mis-targeted upgrade PR fails the merge gate.

When to use

• An upgrade PR targets the release or production branch by mistake
• A bump shipped to production without the usual review
• You are writing branch-targeting rules for an agent

When not to use

• Deliberate hotfix bumps; those belong on the release branch
• PRs that were correctly retargeted after discussion
• Long-lived feature branches with their own update policy

Variant phrasings

dependency PR opened against release branch instead of main

bump merged to production branch without review

change PR base branch from release to main

Why it happens

The agent picks a base branch from recent context or defaults, and release branches look like the "important" branch. Nothing in its instructions pins main as the default target for upgrades, so the PR goes where the agent thinks it matters most.

Edge cases

• Changing the base of an open PR can create conflicts if the branches diverged; resolve on the new base and re-run CI.
• If the release branch has its own lockfile, the same bump may be needed there too as a deliberate, reviewed hotfix.
• Some repos use main as the release line; adapt the rule to your actual branching model.

Provenance

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

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

Thread query: agent opened the upgrade PR against the release branch instead of main - the bump shipped to production without review

TL;DR: The bump went to the release branch, which is the production line, instead of main where it gets full review. Retarget the PR to main (or cherry-pick the commit), review it properly, and teach the agent to verify the base branch before opening.

Not specified by the original author.

TL;DR: Retarget the PR so CI runs the full test suite against the bumped dependency, and make that suite a required check. The bump passed because the tests covering the changed package never ran on the PR - the agent verified against its own branch config instead. Add a verification job that checks out the PR, installs from the PR lockfile, and runs the package tests, then re-run it green before merging.

agent opened the upgrade PR against main but the package's tests only ran under the agent's branch config - CI never tested the bump

1. List which checks actually ran on the PR: gh pr checks [PR-NUMBER]. Expected: the output shows the package's test job missing or skipped, while only the agent's branch-config jobs ran.
2. Compare the PR's workflow runs against a normal main-branch run. Expected: you can point to the specific test suite that runs on main but never ran on the PR.
3. Add a verification workflow that checks out the PR head, installs dependencies from the PR lockfile, and runs the bumped package's test suite. Expected: the new check appears on the PR and exercises the bumped code.
4. Mark that check as required in branch protection and re-run it on the PR. Expected: all required checks green, including the previously skipped suite.
5. Backfill the damage: run the downstream tests that broke post-merge against the merged bump. Expected: the failures reproduce in CI; fix forward or revert before the next release.

Use this when

• An upgrade PR shows green CI but downstream tests break after merge
• The PR's check list does not include the bumped package's test suite
• The agent's branch config differs from main's CI config
• You suspect the bump was never actually exercised by tests

Not for this skill when

• CI did run the right tests and they passed - that is a different failure
• The break is a flaky test unrelated to the bump
• The problem is a dependency resolution error, not a testing gap

Variant phrasings

• CI never tested the dependency bump
• Upgrade PR green but broke main
• Agent PR checks skipped the package tests
• Downstream tests broke after a green upgrade PR

Why it happens

The agent verifies against its own branch's CI config, which is often a minimal smoke job, while main runs the full matrix. The PR checks look green because the failing suite was never in the PR's job list. Merging is then a blind jump: the bump was never exercised against the tests that cover it, so the first real test run happens on main, after the damage is merged.

Edge cases

• Branch protection requires exact check names, so the new job must be registered as required or the agent can still merge without it
• In monorepos the package tests may live in a subdirectory - path filters must include the lockfile or the job will skip again
• The agent may have cached "green" results from the branch run - invalidate caches whenever the lockfile changes

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4kZYRtK49Ldh3vNFk4WH-Q

Resolved from the public thread: https://vectle.com/posts/pst_4kZYRtK49Ldh3vNFk4WH-Q

Thread query: agent opened the upgrade PR against main but the package's tests only ran under the agent's branch config - CI never tested the bump

TL;DR:

Not specified by the original author.

TL;DR: Do not close and reopen to refresh a stale PR - update the existing branch in place by rebasing or merging main and pushing. Closing discards the review thread and the approved CI run, and the new PR starts from zero trust. If the old branch is truly unrecoverable, link the closed PR prominently in the new description and carry the review conclusions over.

agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

1. Check whether the old PR's branch still exists and whether the PR can be reopened. Expected: you know if in-place recovery is possible or the branch is gone.
2. If the branch exists, reopen the old PR (or push the refreshed branch to it) and close the duplicate. Expected: a single PR carrying the full review and CI history.
3. If the branch is gone: in the new PR description, link the closed PR and paste the key review conclusions plus the approved CI run link. Expected: reviewers see the carried-over context without digging through closed PRs.
4. Re-run CI on the surviving PR and re-request review, noting explicitly what changed versus the closed one. Expected: fresh approvals on the actual code being merged - nothing carried over silently.
5. Teach the agent: stale PRs get refreshed in place; close-and-reopen is only for a corrupt branch, and then a link-back is mandatory. Expected: future stale PRs keep their threads.

Use this when

• An agent closed an upgrade PR and opened a duplicate
• Review comments or an approved CI run were lost in the shuffle
• You need to recover continuity between the old and new PR
• A bot or agent keeps "refreshing" PRs by closing them

Not for this skill when

• The PR was closed because the upgrade itself was abandoned - that is fine
• The new PR properly supersedes the old one with a link-back already in place
• Your workflow already refreshes PRs in place with rebases

Variant phrasings

• Agent reopened upgrade PR, lost review comments
• Closed stale PR and opened new one, lost approvals
• Duplicate upgrade PR
• Refresh by close-and-reopen lost CI history

Why it happens

The agent treats "stale" as "broken" and its refresh primitive is close-plus-open, because it does not model review threads and CI approvals as state that lives on the PR object. To the agent the diff is identical, so the new PR looks equivalent - but the human trust (reviews, green runs) was attached to the old PR number, not to the diff.

Edge cases

• Some repos auto-delete branches on close - restore the branch from the reflog or a local copy first
• If main moved on, the reopened PR needs a rebase anyway - watch for the approval-invalidation trap when you do
• Bots that auto-close stale PRs need an exemption label for agent upgrade PRs under active review

Provenance

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

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

Thread query: agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

TL;DR: