What this prompt does
This prompt generates a pull request review checklist tailored to a [language]/[framework] project, scoped to the kind of change in [pr_type]. It produces sections for code quality (naming, SOLID, DRY, complexity), security review items, performance items like N+1 queries and indexing, testing requirements tied to your [coverage_target] percentage, documentation checks, and database migration safety. It also includes accessibility and i18n checks where relevant and a Markdown PR template the team can adopt.
The structure works because it encodes the predictable, recurring problems of a stack into a shared artifact. In Laravel or Next.js work the usual culprits are the same: N+1 queries, unsafe migrations, and auth gaps. By asking for framework-specific anti-patterns to watch for, the prompt makes the checklist sharp rather than generic, which is what keeps review quality consistent across different reviewers on a team. It also includes documentation checks and, where applicable, accessibility and i18n items, so the review covers more than just whether the code runs. Tying the testing section to a concrete [coverage_target] gives reviewers a number to hold the line on instead of a vague sense that there should be "enough" tests.
When to use it
- You want a consistent review standard instead of every reviewer checking different things.
- You are reviewing a
[pr_type]that touches the database and need migration safety checks. - You want security and performance items baked into reviews, not remembered ad hoc.
- You are enforcing a
[coverage_target]threshold and want it on the checklist. - You need a Markdown PR template the whole team can adopt at once.
- You want framework-specific anti-patterns for
[framework]surfaced for reviewers.
Example output
Expect a structured checklist grouped into sections: code quality, security, performance, testing against your [coverage_target], documentation, and migration safety, plus accessibility and i18n where applicable. It closes with a ready-to-paste Markdown PR template and a list of [framework]-specific anti-patterns, all shaped by the [pr_type] you specified so the emphasis matches the kind of change being reviewed.
Pro tips
- Set
[pr_type]accurately; a checklist for a database-changing feature looks different from one for a docs-only PR. - Pick a realistic
[coverage_target]your team can sustain, because an unenforceable threshold gets ignored and undermines the whole checklist. - Lean on the
[framework]-specific anti-pattern section, since that is where the most stack-relevant value lives. - Adopt the generated Markdown template into your repository so every PR starts from the same structure.
- Trim the checklist to what your team will actually use; an overlong list gets skimmed rather than followed.
- Iterate by feeding back issues that slipped through recent reviews and asking it to add targeted checks for them.
