Pull request description prompt

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You write pull request descriptions that let a busy reviewer understand a change in two minutes.

<context>
The ticket or task:
<ticket>
{{ticket}}
</ticket>

How the author tested it:
<testing>
{{testing}}
</testing>

The diff:
<diff>
{{diff}}
</diff>
</context>

<constraints>
- Describe behaviour changes, not a file-by-file tour.
- Only state testing that the author described. If testing is missing or thin, say what is untested.
- Call out anything risky: migrations, config changes, changed public APIs, new dependencies, feature flags.
- Point reviewers at the one or two places that most need careful review.
- Keep it under 250 words. Reviewers skim.
</constraints>

<output_format>
Markdown with these headings:
## What and why
## How to test
## Risks
## Review focus
</output_format>

<task>
Write the description for this pull request.
</task>

You write pull request descriptions that let a busy reviewer understand a change in two minutes.

<constraints>
- Describe behaviour changes, not a file-by-file tour.
- Only state testing that the author described. If testing is missing or thin, say what is untested.
- Call out anything risky: migrations, config changes, changed public APIs, new dependencies, feature flags.
- Point reviewers at the one or two places that most need careful review.
- Keep it under 250 words. Reviewers skim.
</constraints>

<output_format>
Markdown with these headings:
## What and why
## How to test
## Risks
## Review focus
</output_format>

<context>
The ticket or task:
<ticket>
{{ticket}}
</ticket>

How the author tested it:
<testing>
{{testing}}
</testing>

The diff:
<diff>
{{diff}}
</diff>
</context>

<task>
Write the description for this pull request.
</task>

{{ticket}}

The issue or task text, or a sentence on the goal. Include the ticket ID if your team links PRs to tickets.

{{testing}}

What you ran and saw: unit tests added, manual steps, screenshots taken. Be honest; “not tested yet” is a valid value.

{{diff}}

The PR’s diff, or git diff main...HEAD. For large PRs, the stat summary plus the important hunks.

{{ticket}}

PAY-412: Customers want to download all their invoices at once as a ZIP.

{{testing}}

Added unit tests for the ZIP builder. Manually downloaded a ZIP of 30 invoices locally. Not tested with accounts that have more than 1,000 invoices.

{{diff}}

+ app/invoices/export.ts        (new, 84 lines: streams invoices into a ZIP)
+ app/routes/invoices.zip.ts    (new route, GET /invoices.zip)
~ app/invoices/list.tsx         (adds a "Download all" button)
+ app/invoices/export.test.ts   (new tests)

What to look for. The useful output names the untested case (very large accounts) under Risks and points review at the streaming code in export.ts, where memory use and timeouts would show up. A generic description would just list the four files.

You write pull request descriptions that let a busy reviewer understand a change in two minutes.

<context>
The ticket or task:
<ticket>
PAY-412: Customers want to download all their invoices at once as a ZIP.
</ticket>

How the author tested it:
<testing>
Added unit tests for the ZIP builder. Manually downloaded a ZIP of 30 invoices locally. Not tested with accounts that have more than 1,000 invoices.
</testing>

The diff:
<diff>
+ app/invoices/export.ts        (new, 84 lines: streams invoices into a ZIP)
+ app/routes/invoices.zip.ts    (new route, GET /invoices.zip)
~ app/invoices/list.tsx         (adds a "Download all" button)
+ app/invoices/export.test.ts   (new tests)
</diff>
</context>

<constraints>
- Describe behaviour changes, not a file-by-file tour.
- Only state testing that the author described. If testing is missing or thin, say what is untested.
- Call out anything risky: migrations, config changes, changed public APIs, new dependencies, feature flags.
- Point reviewers at the one or two places that most need careful review.
- Keep it under 250 words. Reviewers skim.
</constraints>

<output_format>
Markdown with these headings:
## What and why
## How to test
## Risks
## Review focus
</output_format>

<task>
Write the description for this pull request.
</task>

• OpenAI GPT

  Reasoning models skip Markdown by default from o1-2024-12-17 on, OpenAI notes. Because this format needs headings, put “Formatting re-enabled” on the first line of the developer message when you call one through the API.

• Claude

  Anthropic notes that the formatting of the prompt tends to influence the formatting of the reply. Since this template uses Markdown headings in the format line, Claude will usually match them without extra instructions.

• All models

  Save the filled template as a GitHub pull request template or an agent command so every PR on the team uses the same headings.

• Commit message from a diffTurn a staged diff into a Conventional Commits subject and a body that explains why, not what.
• Code reviewReview a diff for bugs, risky changes and missing tests, ranked by severity with line references.
• Release notes from commitsTurn a list of commits or PRs into user-facing release notes, breaking changes first.

Building this into an app that sends the same instructions with every request? Start from a system prompt instead; each comes with design notes, failure modes and a monthly cost. In the system prompt library: Pull request description writer.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.