super-good-pr
Super Good PR Descriptions
Give reviewers the context they need to evaluate the final change. Lead with the concrete problem and resulting behavior, explain the design choices that matter, and support validation claims with actual evidence. The body should work for someone who did not watch the session.
A small fix may need two paragraphs and validation. A migration may need ordering, compatibility, and rollout detail. Match the explanation to reviewer uncertainty; a long section checklist does not make a small PR more credible.
Establish the source of truth
Read the live PR body, title, base branch, head commit, and repository template before an update. Read the actual diff against that base; do not assume every PR targets main. For an existing PR:
gh pr view NUMBER --json title,body,baseRefName,headRefName,headRefOid,url
Fetch or refresh the relevant refs before deriving the local diff. A three-dot comparison uses the merge base and matches the usual PR comparison model. A stacked PR targets its preceding branch, so a diff against main would describe other layers too. GitHub documents these distinctions in its PR reference.
Gather the original requirement, final behavior, decisive files, and checks that actually ran. Separate observed evidence from expected behavior. Avoid universal claims such as "safe" or "fully covered" when the evidence establishes only a narrower property.