What this prompt does
This prompt writes a complete pull request description for a [change_type] in a [project_type], covering [files_changed] files across [modules_affected]. It produces the full document a reviewer needs — title, summary, categorized changes, testing steps, risk assessment, and a checklist — so the PR explains itself instead of forcing the reviewer to reverse-engineer intent.
The structure works because it answers the reviewer's real questions in order. The title follows your [commit_convention] and stays under 72 characters; the summary ties the change to [ticket_reference] and the business context, not just the code. The Changes section groups bullets as Added, Modified, Removed, and Refactored so scope is obvious at a glance. A Testing section gives exact reproduction steps and edge cases, and a Risk Assessment rates the change Low/Medium/High while calling out [risk_areas] reviewers must scrutinize. The closing checklist enforces tests, docs, migrations, and backward compatibility — turning a vague PR into a reviewable one.
When to use it
- You are opening a PR touching
[files_changed]files and want fast, focused review. - The change spans
[modules_affected]and reviewers need the scope made explicit. - You have sensitive
[risk_areas]like payments or migrations to flag honestly. - Your team enforces a
[commit_convention]and a structured PR format. - You want testing steps written so a reviewer can verify without asking.
- You need a consistent checklist covering tests, docs, and backward compatibility.
Example output
Expect a ready-to-paste PR body, formatted and structured so a reviewer can act on it immediately. It opens with a [commit_convention]-formatted title under 72 characters, then a two-to-three sentence summary that references [ticket_reference] and explains the business context, not just the technical change. A Changes section groups bullets into Added, Modified, Removed, and Refactored, each explaining what and why. A Testing section gives exact reproduction steps, expected outcomes, and the edge cases you checked, while a Risk Assessment rates the change Low, Medium, or High and highlights the [risk_areas] reviewers should scrutinize. It closes with a placeholder for screenshots or a before/after comparison and a checklist covering tests, docs, migration, feature flags, and backward compatibility.
Pro tips
- Name your real
[risk_areas]so the risk section stays honest — payment logic and migration rollbacks deserve explicit callouts. - Tie the summary to
[ticket_reference]and the business reason; reviewers move faster when they know why, not just what. - Keep the Changes grouping accurate; mislabeling a behavior change as a refactor is how subtle bugs slip through review.
- Write testing steps a reviewer can actually run, including the edge cases you checked, not just the happy path.
- Match
[commit_convention]exactly if your CI enforces it, or the title will fail a lint check. - Fill the checklist truthfully — an unchecked migration or compatibility box is a useful signal, not a formality to game.
