Twelve specific, reusable Claude Code prompts that consistently outperform vague requests. Copy-paste templates for code review, debugging, testing, refactoring, and documentation.
"Review this code" gets you five paragraphs of generic advice. "Review this code as a skeptical senior engineer; rank every issue 1–5 by severity and give a one-line minimal fix for each" gets you a prioritised action list you can ship. The difference is knowing how to frame the task. Below are twelve prompts that consistently produce useful output in Claude Code.
Review the changes in this branch as a skeptical senior engineer. For each issue:
- assign severity 1 (nit) to 5 (production-breaking)
- name the file:line
- give a one-line minimal fix
Output as a markdown table sorted by severity descending.
Do not propose new features or sweeping refactors.Why it works: the table format forces Claude to commit to severities. The "do not propose features" clause prevents scope creep, which is the most common failure mode in code-review prompts.
Read [FILE]. Do not run tests yet.
Find subtle logic bugs that unit tests would miss:
- off-by-one in loop bounds
- timezone or locale assumptions
- null/undefined paths that "shouldn't happen"
- silent type coercion (== vs ===, truthy checks on 0/"")
- race conditions if any code touches async state
For each bug, quote the exact line, explain the failure case in 1 sentence, then give the patched line. Maximum 7 findings — pick the highest-value ones.Why it works: enumerating the bug categories upfront gives Claude a checklist to scan against. Capping at 7 prevents low-value padding.
Here is a stack trace and the failing input:
[PASTE TRACE]
[PASTE INPUT]
Trace the exact execution path from entry point to the throwing line.
At each frame, show:
- file:line
- the value of the variable that caused the next frame to be invoked
End with: root cause in one sentence, and the minimal patch.Why it works: forcing per-frame variable values makes Claude actually read the code instead of pattern-matching the error message.
I need to add [FEATURE] to this codebase.
Propose three approaches, ranked by your recommendation:
1. The obvious approach
2. A different approach with a clear trade-off
3. A non-obvious approach — something I probably haven't considered
For each: a 3-sentence description, list of files that would change,
and the one biggest risk. Do not write code yet.Why it works: forcing a "non-obvious" third option surfaces alternatives you'd miss. Capping at three keeps the response focused.
Read all files under [DIRECTORY]. Identify the 20% of code paths that are
most likely to cause 80% of production bugs. For each, give:
- file:line range
- why it's risky (complexity, mutation, IO, async)
- the single test that would catch the most regressions
Output as a table, sorted by risk descending.Why it works: explicitly asking for the 80/20 forces ranking. Pairing each risk with a single high-value test gives you an actionable backlog.
Test [TEST_NAME] in [FILE] fails 1 in 5 runs.
Without running it yet, list the top 5 likely causes (timing, shared state,
fs/network, randomness, ordering). For each, the exact code reading you'd
verify it from, and a deterministic fix.Write a README for [PROJECT]. Constraints:
- First sentence must hook a developer in 5 seconds — no "this project is a..."
- Working code example in the first 30 lines
- No marketing words ("powerful", "robust", "best-in-class")
- A "non-goals" section that's at least 3 bullets
- Maximum 250 linesSpend 5 minutes reading the repo structure (don't read all files — sample).
Output:
- The dominant architectural pattern in 2 sentences
- Three places where the pattern is violated (file:line)
- Whether the violations are pragmatic or accidental
- One concrete next refactor that would pay back fastestI want to migrate from [OLD] to [NEW]. Before I start, audit:
- Every file that imports [OLD] (give file:line list)
- API surface differences that aren't drop-in
- Tests that would need rewriting vs reusing as-is
- A two-phase rollout plan (behind a flag, then default)
Do not write code yet.Before writing any code for [TASK], list:
- The 3 hardest sub-problems
- Which existing function/file you'd extend vs write fresh
- The riskiest assumption you're making
- What a quick spike (under 20 lines) could verify first
Wait for my go-ahead before implementing.Why it works: half of bad Claude Code outputs come from jumping to implementation. This prompt forces a planning pause.
Fix [BUG] with the smallest possible diff.
- No refactors
- No renaming
- No formatting changes
- No "while I'm here" cleanup
Show the diff as a unified patch.Read CLAUDE.md if present, then this entire repo's top-level structure.
Propose 5 short rules to add to CLAUDE.md that would have prevented past
mistakes you can see in git history or stylistic drift across files.
Phrase each as "Always X" or "Never X" with one sentence of why.This page covers 12 of them. The Claude Code Power Prompts PDF has 30, grouped into six categories (review, debugging, testing, architecture, docs, devops) with a TIP box for each — paste into CLAUDE.md and Claude loads them every session. £3 launch price tonight (first 10 buyers), £5 standard, instant download after Stripe checkout.