Add

Coding & Software

Write a Pull Request Description

Turns a diff and a ticket into a pull request description with context, changes, risk and a test plan that reviewers can follow.

Designed for general-purpose AI assistantsPublished November 2026

Customize

Fill in the fields and the prompt updates. What you type stays in this page and is never saved or sent.

Preview

Write a pull request description for the change below. Base it only on the diff and the context I give you.

Project: {{project}}
Ticket or goal: {{ticket or goal}}
Reviewers: teammates who know the codebase
Tests I have run: none yet

Diff or list of changes:
{{diff}}

Use this structure:
## Why
Two or three sentences on the problem and why it is worth solving now.
## What changed
Bullets grouped by area, behavior first. Mention a file name only where it helps a reviewer find something.
## How to review
Where to start, what deserves the closest look, and which parts are mechanical (renames, formatting) and can be skimmed.
## Risk and rollout
What could break, who is affected, whether it is behind a flag, and how to roll it back.
## Test plan
A checkbox list. Tick only the steps I said I ran; leave the rest unticked.

Rules: never say a test passed unless I told you it did, do not describe changes that are not in the diff, and keep the whole description under 300 words. If the diff does not reveal why the change exists and I gave no ticket, ask me one question instead of guessing the motivation.

3 required fields are empty and will stay as a {{placeholder}} in the copied text.

How to use it

  1. Paste the diff (or the output of git diff) and a one-line ticket or goal. A diff with no goal gives a description of what changed but not why.
  2. State honestly which tests you ran. The prompt will not tick boxes you did not report, so an empty list is a useful reminder.
  3. Read the Risk and rollout section first. If it says nothing specific, the diff probably lacked context; add the missing detail and regenerate.
  4. For very large diffs, paste one logical area at a time and ask for the sections to be merged afterwards.

Example output

Illustrative only. Real answers depend on your input and the assistant you use.

## Why
Retried webhook deliveries were processed twice, which created duplicate invoices for a small number of customers (ticket BILL-212). We need an idempotency check before the handler writes anything.

## What changed
- Webhook handler: reads the event id and skips events already recorded.
- New table webhook_events with a unique constraint on event id.
- Handler tests: duplicate delivery now returns 200 without a second write.

## How to review
Start with handler.ts. The migration is a plain table creation. The snapshot updates in tests/ are generated and can be skimmed.

## Risk and rollout
The migration must run before the new handler is deployed. Rollback: redeploy the previous handler; the table can stay.

## Test plan
- [x] Unit tests for the handler
- [ ] Replay a real duplicate event in staging
- [ ] Confirm the migration on a copy of production data

Tips

Keep the "How to review" section even for small changes. It is the part that saves a reviewer the most time, and it forces you to say which files are the real change.

If your team has a pull request template, paste it under the diff and tell the assistant to use that structure instead of the one above.

The assistant only sees the diff you paste. It cannot know about a flaky test, a deploy freeze or a verbal agreement, so add those to the "Ticket or goal" field when they affect the review.

Back to the Prompt Library

Related prompts

  • Coding & Software

    Code Review Checklist Prompt

    A structured review prompt that checks correctness, failure handling, security and tests, and labels every finding by severity.

    Customizable fields
    3 fields

  • Coding & Software

    Write a Commit Message From a Diff

    Writes a Conventional Commits style message from a diff, and tells you when the diff is really two commits that should be split.

    Customizable fields
    5 fields

  • Coding & Software

    Document an API Endpoint

    Writes reference documentation for one API endpoint from its code, covering parameters, responses, errors and a working example.

    Customizable fields
    6 fields