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

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.

1. 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.

1. 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.

1. 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.

1. 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