Dev.to AI 🤖 Ai 👁 0 📖 4 min read

Writing a review-ready PR body from a short diff, no install required

My pull request descriptions used to be two words and a shrug. "fixes stuff", "cleanup", sometimes nothing at all. Then I would watch a reviewer spend the first ten minutes of a review reconstructing what the change was

My pull request descriptions used to be two words and a shrug. "fixes stuff", "cleanup", sometimes nothing at all. Then I would watch a reviewer spend the first ten minutes of a review reconstructing what the change was for, which is work I had already done in my head and failed to write down. The code was usually fine; the missing context was the bottleneck.

The fix was not more discipline. It was a template that asked me the questions a reviewer always asks anyway, and a way to fill it from the diff I already had. Four headings: Summary, What changed, How to test, Notes. That is it. Once the shape exists, I stop staring at an empty textarea.

The four headings a reviewer actually reads

Summary is one or two sentences of intent, not a restatement of the diff. "Make the retry path idempotent so a duplicate webhook cannot create a second order" tells a reviewer what to check; "changes retry.py" does not.

What changed is the short mechanical list: which modules, which behaviour, whether anything is deliberately out of scope. I want this separate from the intent, because a reviewer compares the two and the interesting bugs live in the gap between them.

How to test is the section that earns its keep. Exact commands, the state to set up, the edge case to try, what "correct" looks like. When I leave it blank, a reviewer either guesses or asks, and both cost a round trip.

Notes is where the awkward stuff goes: a migration that needs a follow-up, a flag that is off by default, a known limitation, a decision I want someone to push back on. Putting it in writing means it survives the merge instead of living in a thread nobody reopens.

PrGen turns commits or a short diff into exactly that structure: a structured PR body with Summary, What changed, How to test, and Notes, review-ready as a draft. No installation, no repo permissions, nothing to configure.

Why no GitHub App is a real design decision

The feature I am most asked about is a GitHub App, and the answer is no, on purpose. An App would pull the branch, the linked issues, the CI status, and the file list without me pasting anything. It would also need an OAuth grant, a permission scope, a place to run, and a security review before anyone on the team could install it. For a tool whose whole job is producing a paragraph of text, that is a lot of machinery and a lot of trust.

The cost is real and I will not pretend otherwise. No App means no automatic issue linking, no branch name, no CI result, no diff stats pulled on my behalf. If I want those in the body, I type them. Nothing syncs, nothing updates when I push another commit, and the tool has no idea a PR exists after I close the tab. This is a trade-off, not a victory lap: I am trading automatic context for a smaller trust surface and zero setup.

The test notes are still mine to verify

Here is the honest limit. The PR body is a draft, and the "How to test" section is the part most likely to be confidently wrong if I stop paying attention. A generated set of steps can describe the happy path and miss the one state that actually breaks: an existing user with a null field, a clock skewed by a day, a feature flag half-rolled-out. Those come from knowledge of the system, not from the diff.

So I read the draft, correct the test steps against what I actually ran, and confirm the Notes section does not claim a decision the team has not made. A reviewer should treat the body as a starting point, not as evidence the change was verified. It is decision-support for writing the description, not a live audit of the branch, a review approval, or a certification that the change is safe. The sign-off still belongs to a human who ran the code.

If your PR descriptions are still a blank box and a silent prayer, pasting a commit range into PrGen and editing the resulting four sections is a five-minute change that moves the review conversation forward. Then do the part it cannot: run the steps and mean them.

FAQ

Does it open the PR or post to GitHub for me?

No. It produces a structured PR body from what you paste. It does not open PRs, post comments, read GitHub, or check CI. There is no App to install.

Is the generated How to test section verified?

No. It is a draft. Confirm the steps against what you actually ran; a reviewer's sign-off still belongs to a human.

Why no GitHub App?

Fewer permissions and zero setup, at the cost of no automatic issue linking, branch context, or CI status. It is decision-support, not a live audit of your branch.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.