Specific Claude Code prompt templates for reviewing pull requests, finding security issues, ranking severity, and producing minimal-diff fixes. Copy, fill the brackets, paste.
The default "review this code" produces generic advice. The prompts below force Claude into specific, actionable output you can ship from. Pick the template that matches your context, fill the bracketed slots, paste.
You are a skeptical senior engineer reviewing this PR before merge.
Diff: [PASTE DIFF or PATH]
For each issue you find:
- File:line
- Severity 1 (nit) to 5 (production-breaking)
- Category: correctness | security | performance | readability | testing
- One-line minimal fix
Output as a markdown table sorted by severity descending.
Constraints:
- No more than 12 issues (pick the most valuable)
- Do NOT propose new features
- Do NOT request sweeping refactors
- If the PR is fine, say so in one sentence and stopWhy it works: the table format forces commitment. The constraints prevent the two most common failure modes — feature creep and the dreaded "consider rewriting this in a more idiomatic way" suggestion. The escape clause ("if the PR is fine, say so and stop") prevents Claude from inventing issues to look thorough.
Audit this diff for security issues only. Ignore style and architecture.
Diff: [PASTE]
Check for:
- Injection (SQL, command, template, XSS, prototype pollution)
- AuthZ/AuthN bypass (missing checks, broken role logic)
- Secrets exposure (logs, error messages, response bodies)
- Crypto misuse (weak algos, fixed IVs, predictable randomness)
- IDOR (user IDs in URLs without ownership checks)
- File upload paths (unrestricted MIME, path traversal)
- Race conditions in state mutation
- Trust boundary violations (user input reaching shell/eval/SQL)
For each finding: file:line, attack scenario in 1 sentence, minimal patch.
Cap at 8 findings.Read this diff and produce a 5-line PR summary for a busy reviewer:
- WHY (1 line — the motivation)
- WHAT (2 lines — the user-visible change)
- HOW (1 line — the implementation approach)
- RISK (1 line — what could break)
Diff: [PASTE]
No marketing language. No "this PR aims to". Plain English only.Use this on your own PRs before opening them. If Claude can't extract a clean 5-line summary, your diff is doing too much and should be split.
This PR touches multiple files. Don't review file-by-file.
Instead:
1. In 3 sentences, describe what the PR is trying to do across the system.
2. List the 3 architectural decisions implicit in the diff (e.g. "introduces a queue between X and Y", "moves validation from controller to service").
3. For each decision: is it consistent with existing patterns in this repo? Cite a file:line of an existing example or counter-example.
4. Then — and only then — flag any concrete file:line issues, max 7.
Diff: [PASTE]Imagine you're the on-call engineer who will be paged if this PR breaks
production at 3am. Read the diff:
[PASTE]
For each line that could page you:
- file:line
- the runtime failure mode (timeout, OOM, panic, partial write, etc.)
- the symptom that would appear in logs/metrics
- the rollback complexity (clean revert vs requires migration)
Output sorted by probability of paging you.This prompt is uncomfortable in the right way. It surfaces operability concerns that "is this code good" prompts miss.
Paste Prompt 1 into your CLAUDE.md at the project root under a heading like ## Code Review. Claude Code loads CLAUDE.md every session — you'll never re-paste the prompt. Combine with git diff main...HEAD as the input and you have a one-line review workflow: claude -p "use the Code Review prompt on the current diff".
The Claude Code Power Prompts pack bundles 30 prompts across six categories — review, debugging, testing, architecture, docs, devops — each with a TIP box explaining when to use it. £3 tonight (first 10 buyers), £5 standard, 8-page PDF, instant Stripe checkout. Same idea as the prompts above, but covering every workflow you hit weekly.