Write a commit message and pull request description from a diff
Turns a diff into a clear commit message and a PR description that tells reviewers what changed, why, and what to look at closely.
By Daniel OkaforVersion 1Updated 7 Oct 2026
Prompt
Write a commit message and a pull request description for the change below.
Why I made this change: {{reason}}
Anything reviewers should know (trade-offs, follow-ups, things I am unsure about): {{notes:nothing extra}}
Commit message:
- Subject line: imperative mood ("Add", "Fix", "Remove"), under 72 characters, no full stop.
- Blank line.
- Body: why the change was needed and what it does at a high level. Do not walk through the diff line by line.
Pull request description:
- Summary: what changes for a user or for the system, in two or three sentences.
- Why: the problem or need behind it.
- What changed: a short list by area, not by file.
- How to test: the steps a reviewer can follow to see it working.
- Risks: anything that could break, any migration or config change, and whether it can be rolled back.
- Review focus: the one or two places where a careful second look matters most.
Rules:
- Describe only what the diff actually does. If the diff does something my stated reason does not explain, point it out.
- Do not claim tests were added or run unless the diff shows them.
- Plain language. No "various improvements" or "minor fixes".
Diff:
{{diff}}Use this prompt
Result
Write a commit message and a pull request description for the change below.
Why I made this change: {{reason}}
Anything reviewers should know (trade-offs, follow-ups, things I am unsure about): nothing extra
Commit message:
- Subject line: imperative mood ("Add", "Fix", "Remove"), under 72 characters, no full stop.
- Blank line.
- Body: why the change was needed and what it does at a high level. Do not walk through the diff line by line.
Pull request description:
- Summary: what changes for a user or for the system, in two or three sentences.
- Why: the problem or need behind it.
- What changed: a short list by area, not by file.
- How to test: the steps a reviewer can follow to see it working.
- Risks: anything that could break, any migration or config change, and whether it can be rolled back.
- Review focus: the one or two places where a careful second look matters most.
Rules:
- Describe only what the diff actually does. If the diff does something my stated reason does not explain, point it out.
- Do not claim tests were added or run unless the diff shows them.
- Plain language. No "various improvements" or "minor fixes".
Diff:
{{diff}}Still to fill in: reason, diff
Test run
Fill in reason, diff to run it. A blank input would spend a test run on a prompt with holes in it.