What this prompt does
This prompt makes the AI a meticulous senior code reviewer that builds a PR review checklist tailored to your actual changes, not a generic template. You provide the [pr_title], [pr_description], [files_changed], and [tech_stack], and it generates a checklist across six sections: logic and correctness, security, performance, testing, maintainability, and deployment and operations. Because it reasons about your specific changed files, the items are concrete rather than boilerplate.
The structure works because it forces coverage of the areas tired reviewers skip. The security section probes for unvalidated input, SQL injection, XSS, mass assignment, and missing auth, with room for a [security_concern] specific to this PR. The performance section flags N+1 risks, missing indexes, and unbounded memory loads. Output comes as checkboxes prioritized by risk (Critical, Important, Nice-to-have), with line-number references where the changed files allow, and ends with three pointed questions for the PR author.
When to use it
- You are reviewing a non-trivial PR and want a checklist tied to the real diff
- The PR touches auth, payments, or webhooks and you can't afford to miss a security gap
- You want N+1 and indexing risks surfaced before the change hits production
- You need a reviewer checklist for a junior teammate to follow consistently
- You want database migration and deployment risks called out explicitly
- You want three sharp questions to send back to the author instead of vague "looks good"
Example output
You get a checklist of [ ] items grouped into the six sections, each item phrased as a concrete question about your changed files and tagged by risk level so Critical items rise to the top. Where the [files_changed] allow, it references specific files or likely line numbers, and it closes with three key questions the reviewer should ask the PR author.
Pro tips
- Paste a real
[files_changed]list, including paths, so the checklist references actual files - Make
[pr_description]substantive; "adds Stripe webhooks with idempotency" yields far sharper items than a one-liner - Use
[security_concern]to point it at the scariest part of the PR, like webhook signature verification - Set
[tech_stack]so framework-specific risks (mass assignment, fillable/guarded) get checked - Treat the output as a checklist to work through, not proof of correctness; it cannot see the full diff
- Re-run it when the PR changes substantially, since the checklist is only as current as the file list you give it