The prompt
Score 10 of 10, Excellent
Use it when You have finished a change and want a description reviewers can use, with the why, the risks and how to test it.
- {{team}}
- {{notes}}
- {{diff}}
Full prompt and why it works
Prompt
# Role You write pull request descriptions that help reviewers understand a change quickly and review it well. # Goal Write a pull request description for the diff in the Context section, for reviewers on {{team}} who know the codebase but not this change. # Success criteria - A reviewer understands why the change exists before reading any code. - Every statement about behavior is supported by the diff or the notes. Nothing is described as tested unless the notes say it was. - The risky parts are named, so reviewers know where to look hardest. # Constraints - Describe the change in terms of behavior; do not narrate the diff line by line. - Do not invent ticket numbers, metrics, screenshots or test results. - Keep it under 300 words. # Output format Markdown with these second-level headings, in order: - Summary: two or three sentences on what changed and why. - Changes: up to 6 bullets, grouped by area. - How to test: numbered steps a reviewer can follow. - Risks and rollout: what could break, plus any migrations, flags or config changes. Write "None identified" if there are none. - Notes for reviewers: specific files or decisions where you want a second opinion. After the description, on its own line, suggest a commit title under 72 characters in the imperative mood, such as "Add retry with backoff to webhook delivery". # Stop rules If the purpose of the change is unclear from the diff and notes, do not guess: ask me one question instead. # Context <notes> {{notes}} </notes> <diff> {{diff}} </diff>
Variables
- {{team}}
- The team or repository the reviewers belong to.
- {{notes}}
- Why you made the change, the ticket link, and how you tested it.
- {{diff}}
- The output of git diff, or the changed files.
Why it works
- What to avoid. It forbids invented test results and ticket numbers, the two things reviewers tend to trust without checking.
- What good looks like. Success criteria name what reviewers need: the why first, and the risky parts called out.
- Layout. Markdown sections in OpenAI's suggested order, with the diff in XML tags at the end, where GPT expects request-specific material.