What makes a PR description get read
Reviewers do not read descriptions in order. They scan for three things, and a description that buries them does not get read at all.
A reviewer opening a pull request is answering three questions, usually in this order: what changed, why it changed, and what to look at. A description that answers them in that order gets used. One that answers them in the wrong order gets skipped, and the reviewer then has to reconstruct the answers from the diff.
What changed
Not a list of files — the diff already shows that. The change described in behaviour: the endpoint now rejects X, the retry logic moved to Y. One or two sentences, written for someone who has not been in the branch.
Why
The part most often omitted, and the part a reviewer most needs. Not the ticket number — the reason. A reviewer who knows why can tell whether the implementation fits the intent; one who does not can only check style.
What to look at
Where the risk is. The migration, the concurrency change, the part you are unsure about, the trade-off you made deliberately. Naming it focuses the review; leaving it out means the reviewer spends their attention evenly instead of where it matters.
PrGen drafts these three sections from the commit history and the diff, then shows you what it inferred. It does not know why you made the change — that section stays yours.