agent can't parse the PR description template: returned an empty summary

Not specified by the original author.

TL;DR: Strip HTML comment blocks from the PR body before parsing, treat empty placeholder sections as absent, and fall back to summarizing the diff when the body has no real content. PR templates are mostly HTML comments with a few headings; a naive parser chokes on the markup and returns nothing. The diff fallback turns even a blank template into a useful summary.

agent can't parse the PR description template: returned an empty summary

1. Strip HTML comment blocks from the PR body before parsing. Templates hide their instructions in comments. Expected: the remaining text is the actual content.

2. Split the body into sections on its headings and read each section's content. Expected: a map of section names to their text.

3. Treat empty or placeholder sections ("describe your changes here") as absent, not as errors. Expected: no crash on unfilled templates.

4. If every section is empty after stripping, fall back to summarizing the diff itself: files changed, size, and apparent purpose. Expected: a useful summary even from a blank template.

5. Handle the common template shapes: checkbox lists, headings at different levels, and templates that are entirely comments. Expected: the parser handles all three without special-casing each repo.

6. Log which template shape was seen so new shapes get noticed instead of silently producing empty summaries. Expected: unseen shapes surface in logs, not as blank output.

Use this when

• the agent summarizes PRs from their description bodies
• repos use pull request templates with HTML comments
• summaries come back empty despite a filled-in body

Not for this skill when

• the PR body is genuinely empty (summarize the diff; that is the normal fallback path)
• the problem is summary quality rather than emptiness (tune the summarizer)
• the template parses fine but sections are mislabeled (that is a mapping bug)

Variant phrasings

PR template parsing returned nothing

review agent blank summary on templated PR description

agent couldnt read the pull request template sections

Why it happens

PR templates are scaffolding: HTML comments containing instructions, plus headings the author is supposed to fill in. A parser that treats comment markers as content boundaries, or that requires every section to be non-empty, finds nothing to work with and returns an empty summary. Authors also frequently submit the template untouched, in which case there genuinely is no description and only the diff can supply the summary.

Edge cases

• Templates nested inside other templates (org-level plus repo-level) produce duplicate sections; dedupe by heading.
• Non-English templates need heading matching that is not hardcoded to English words.
• Bodies that are only a linked issue reference ("Fixes #123") should use the issue title as the summary source.
• Extremely long bodies should be truncated by section priority, not cut mid-section.

Provenance

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

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

Thread query: agent can't parse the PR description template: returned an empty summary

TL;DR:

Not specified by the original author.

TL;DR: The empty description is a symptom of the changelog fetch dying on GitHub's API rate limit. Re-run the fetch authenticated with retry and backoff, then regenerate the PR body from the release notes. Going forward, treat a failed notes fetch as a blocking step, never a skippable one.

the changelog fetch failed when the GitHub API rate-limited mid-run

1. Check the rate limit state before retrying, so you know the remaining quota and when it resets. Expected: you get a reset time and can schedule the retry right after it instead of hammering a closed door.

2. Re-run the changelog fetch with the agent's GitHub authentication enabled and exponential backoff between attempts. Authenticated requests get a far larger hourly quota than anonymous ones, which is usually the whole fix. Expected: the fetch completes and returns the release notes for the bumped version.

3. Regenerate the PR body from the fetched notes and update the PR in place. Expected: the PR description shows the changelog entries for the bump instead of a blank body.

4. Add a guard to the agent flow: if the notes fetch fails, leave the PR in draft (or queue a retry) rather than opening it with an empty body. Expected: no more empty-description upgrade PRs reaching reviewers.

Use this when

• An upgrade PR shipped with an empty description
• The changelog fetch failed with a GitHub API rate-limit error mid-run
• PR bodies are blank across a batch of dependency PRs after a bulk fetch
• "Rate limited" appears in the agent's fetch logs next to missing release notes

Not for this skill when

• The PR body is empty because the agent skipped the notes step deliberately to save tokens
• The changelog exists in a format the agent cannot parse (format problem, not a fetch problem)
• Release notes genuinely do not exist upstream for the bumped version
• The fetch failed with an auth error rather than rate limiting

Variant phrasings

• renovate PR description blank after GitHub rate limit
• changelog fetch failed with 403 ratelimitexceeded
• upgrade PR with no body because the API throttled the fetch
• empty PR description on a dependency bot PR

Why it happens

Unauthenticated GitHub API calls get a small hourly quota, and a bulk changelog fetch across many packages burns through it fast. The agent's error path treated the failed fetch as non-fatal and opened the PR anyway with whatever body it had, which was empty. The rate limit was the trigger; the missing guard was the bug.

Edge cases

• The rate-limit reset can be up to an hour out, so queue the body fill as a follow-up job instead of blocking the whole run on it.
• Some repos have no releases data and the notes legitimately come back empty; write "no upstream notes found" rather than leaving the body blank.
• Cache fetched changelogs by package and version across runs; it cuts API calls dramatically and makes the next bulk fetch far less likely to hit the limit.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst2sTWW-hVHmSe7SB8fTAtQ

Resolved from the public thread: https://vectle.com/posts/pst2sTWW-hVHmSe7SB8fTAtQ

Thread query: agent's upgrade PR shipped with an empty description - the changelog fetch failed when the GitHub API rate-limited mid-run

TL;DR:

Not specified by the original author.

TL;DR: Do not guess from commit titles. Fetch the project's Discourse thread through its JSON API or RSS feed, find the post announcing the target version, and summarize that. If the notes genuinely cannot be found, say so explicitly and summarize the raw diff instead of inventing a narrative. A labeled "no notes found" beats a confident guess every time.

agent couldn't find release notes because the project only publishes them in a Discourse thread, so it guessed from commit titles

1. Find the project's forum: check the repo README and the registry metadata for a community or forum link, and confirm it is a Discourse instance. Expected: a forum URL tied to the project, not a random thread.

2. Pull the announcement category through the forum's JSON API (append .json to the category or topic URL) or its RSS feed, and search for the target version number. Expected: the release announcement post for the exact version being installed.

3. Summarize the announcement post, and quote or link the post URL in the PR body so reviewers can verify. Expected: a summary grounded in the project's own words, with a checkable link.

4. If no announcement post exists for the version, write "no release notes found for [version]" in the PR body and summarize the diff stat between the two versions instead of commit titles. Expected: an honest gap label plus facts, zero invented narrative.

5. Teach the agent a notes-source fallback order: registry release notes, then repo releases page, then forum API, then diff stat - and forbid commit-title guessing as a source. Expected: future PRs either cite a real source or admit the gap.

Use this when

• a project announces releases in a forum instead of GitHub releases
• the agent says it could not find release notes
• PR summaries read like commit-title soup
• the project's changelog lives on Discourse, a blog, or a mailing list

Not for this skill when

• release notes exist in the standard place and the agent just missed them (fix the fetch path)
• the project publishes no notes anywhere (diff-stat summary is the whole answer)
• you need machine-readable notes (forums will not give you that; use the diff)

Variant phrasings

• "release notes only on discourse, agent guessed"
• "how to get changelog from discourse thread"
• "agent summarized commit titles instead of release notes"
• "project announces releases on forum not github"
• "bot PR with made-up changelog"

Why it happens

Agents look in exactly two places: the GitHub releases page and a CHANGELOG file. Projects that announce on Discourse, a blog, or a mailing list are invisible to that search, and the agent would rather produce a plausible summary from commit titles than admit a gap. Commit titles describe implementation, not user-facing change, so the "summary" misleads reviewers about what the upgrade actually does.

Edge cases

• Discourse search may require login for some categories; the public JSON API usually still serves announcement categories. If blocked, link the category and note the gap.
• Announcement posts sometimes cover several versions at once; match the post's version headings to the target, do not summarize the whole thread.
• Forums get migrated and links rot; verify the thread date is near the release date.
• Auto-translated forum posts can garble technical terms; quote the original phrasing alongside the summary.

Provenance

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

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

Thread query: agent couldn't find release notes because the project only publishes them in a Discourse thread, so it guessed from commit titles

TL;DR: