From commit log to review narrative
A commit history is a record of what happened. A PR description is an argument for a change. The gap between them is editorial, not mechanical.
The instinct is that a good commit log should produce a good PR description automatically. It usually does not, because the two documents have different readers and different purposes.
What the commit log is good for
Sequence and scope: what was touched, in what order, and which changes belong together. That is the raw material for the what-changed section, and it is genuinely useful — reconstructing it by hand from a large diff is tedious and error-prone.
What it cannot provide
Intent. "fix: handle null case" tells you a null case is handled and not why it came up or what the caller should expect now. Motive lives outside the repository, in the ticket, the incident, or the conversation.
It also cannot provide emphasis. A commit history is flat; every change looks equally important. Deciding what the reviewer should look at first is a judgement about risk.
How to use generated output
Treat the draft as a first pass at the what-changed section, then write the why and the risk yourself. PrGen marks the sections it inferred from the diff so you can see which parts are grounded and which are placeholders waiting for you.