Turn a diff into a clear, reviewer-friendly PR description

A good pull request description is the difference between a fast review and a thread of confused questions. This prompt turns your diff plus context into a structured description reviewers can actually act on: a one-line summary, what changed, why (tied to the ticket), how to test, and a risks/rollout note. It deliberately keeps things factual—describing only what the diff does—and asks the model to flag anything a reviewer should scrutinize, which raises the quality of the review rather than rubber-stamping it. Provide the actual diff (or a summary of it) and any context the diff alone can't convey: the ticket goal, a design decision, why you chose approach A over B. Set the reviewer level so the depth matches your audience—a senior reviewer wants risks and trade-offs, a junior teammate may want more on-ramp. You still own correctness: read the description against your diff, because the model describes what you give it, and a misleading summary is worse than none.

What you can expect back

**Title:** Prevent duplicate signups with a unique email constraint (JIRA-482)

**Summary:** Enforce unique emails at the database level and return 409 on conflict.

**What changed**
- New migration adds a `UNIQUE` constraint on `users.email`.
- `createUser` now catches the unique-violation error and returns HTTP 409 instead of an unhandled 500.

**Why**
JIRA-482: production saw duplicate accounts caused by double-clicks on signup. The app-level check had a race; a DB constraint closes it.

**How to test**
1. Run the migration on a copy of staging data (watch for existing duplicates—see Risks).
2. POST the same email twice; the second call should return 409.

**Risks / rollout**
- Migration will FAIL if duplicate emails already exist—back-fill/dedupe first.
- Reviewer, please scrutinize the dedupe step and the 409 error shape clients receive.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Include the 'why' the diff can't show—reviewers approve faster when intent is explicit.
• 02Let it flag risks; a self-identified scrutiny list makes reviewers trust the PR more, not less.
• 03Read the generated 'How to test' steps against reality—wrong steps waste a reviewer's time.
• 04Keep the title under 70 chars and lead with the user-facing change, not the implementation.

Adapt it for your case