agent closed a stale upgrade PR and opened a fresh one, losing

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:

Not specified by the original author.

TL;DR

Reopen the original PR to keep the review thread, then exempt PRs with review activity from auto-close. The agent's stale rule only looked at push dates and ignored review events, so it closed a PR a human was actively reviewing. Closing and reopening destroyed the review context for no reason.

Error

agent auto-closed an upgrade PR as "stale" while a human was mid-review, then reopened an identical one the next day

Steps

1. Reopen the original PR instead of keeping the duplicate. Reopening restores the review thread and the approved CI run. Expected: the original PR is open again with its comments intact.
2. Close the duplicate the agent opened. Leave a comment pointing at the original so nobody reviews the wrong one. Expected: one canonical PR, no confusion.
3. Re-request the review. Ping the human reviewer on the reopened PR. Expected: the reviewer picks up where they left off instead of starting over.
4. Fix the stale rule. Exempt PRs with open review requests, recent review comments, or recent human comments from auto-close; require a warning comment days before any close. Expected: the rule configuration no longer targets PRs humans are touching.
5. Change the agent's behavior. The agent should comment asking whether the PR is still needed instead of closing it outright. Expected: humans get a nudge, not a surprise close.

Use this when

• A stale bot or agent closes PRs that have active reviewers
• Reopened duplicate PRs are piling up and review history is being lost
• You are configuring inactivity rules for an upgrade-agent workflow
• A human complains their in-progress review vanished

Not for this skill when

• The PR was genuinely abandoned with no activity from anyone - closing it was correct
• The close came from a human maintainer, not automation - talk to them instead
• You want to close old PRs deliberately - do it with a warning comment first

Variant phrasings

• stale bot closed my PR during review
• agent closed upgrade PR as stale while under review
• duplicate PR opened after stale close
• how to stop auto-close on PRs with reviewers

Why it happens

Stale rules usually key off the last push or last commit date. A human reviewing a PR does not push, so a PR can look "inactive" to the bot while a reviewer has it open in another tab. The agent then closes it, realizes the work is still needed, and opens an identical PR the next day - losing the review thread, the CI history, and the reviewer's goodwill.

Edge cases

• Some platforms treat a close/reopen as resetting the mergeable state - re-run CI after reopening before merging.
• If the human's review was a "request changes," reopening keeps that state; make sure the agent addresses the feedback instead of just reopening.
• Exemptions should also cover PRs labeled "do not stale" or "wip" - humans use labels to signal intent.
• Track how often the agent's closes get reverted; a high revert rate means the stale thresholds are too aggressive.

Provenance

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

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

Thread query: agent auto-closed an upgrade PR as "stale" while a human was mid-review, then reopened an identical one the next day

TL;DR:

Not specified by the original author.

TL;DR: Fetch the changelog fresh for the exact target version being installed, and verify the release date and version header in the notes match that target. Cached copies drift; the agent must compare the notes' version header against the version in the PR before summarizing. When they do not match, refetch with the cache bypassed and rebuild the summary.

agent summarized a changelog from a stale cached copy; the "breaking changes" it listed were from two majors ago

1. Open the cached notes the agent used and read the version header and release date at the top; compare both against the version the PR actually installs. Expected: the header shows an older major, or a date weeks before the target release.

2. Refetch the changelog directly from the canonical repo with caching disabled (fresh request, no local or proxy cache) for the target version's tag or release. Expected: notes whose version header matches the version being installed.

3. Rebuild the breaking-changes list from the fresh copy only, then diff it against the stale list the agent posted. Expected: the phantom "breaking changes" from two majors ago disappear.

4. Change the agent's notes step to stamp every summary with the source URL, the version header it read, and the fetch date; reject any summary where the header does not match the target version. Expected: stale sources get caught at summary time, not after the PR posts.

5. Repost the PR description with the corrected summary and the stamped source link. Expected: reviewers see changes for the version being installed, nothing older.

Use this when

• an upgrade PR's breaking-changes list includes ancient changes
• the agent caches changelog fetches between runs
• the PR jumps multiple majors and the notes describe the wrong one
• release-note dates predate the version being installed

Not for this skill when

• the notes are current but wrong about the content (different problem)
• the agent fetched the wrong repo entirely (see the wrong-repo skill)
• there is no changelog and the agent guessed (see the missing-notes skill)

Variant phrasings

• "renovate PR lists breaking changes from old version"
• "changelog cache stale, wrong release notes"
• "upgrade PR summary cites changes from two majors ago"
• "agent summarized outdated changelog"
• "release notes version mismatch in bot PR"

Why it happens

Changelog URLs are stable (a single file or releases page), so agents cache them aggressively to save tokens and requests. But the cached copy predates the target version, and the summary step never checks that the version header in the notes matches the version in the PR. The mismatch only surfaces when a human notices the "breaking changes" already shipped years ago.

Edge cases

• Rolling changelog files (CHANGELOG.md at HEAD) describe the unreleased version at top; the agent must scroll to the section matching the target version, not summarize the top.
• Some projects rewrite history on release branches; a cached copy can differ from a fresh fetch even for the same version. Prefer the tag-anchored release notes over the branch file.
• Cache-busting every fetch costs tokens on huge changelogs; cache per (repo, tag) instead of per repo.
• If the fresh fetch still shows the wrong major, the agent may be following a redirect to an archived repo; check the repo's archived flag.

Provenance

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

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

Thread query: agent summarized a changelog from a stale cached copy; the "breaking changes" it listed were from two majors ago

TL;DR: