A curated library of Claude Code prompts organised by workflow: review, debug, test, refactor, document, deploy. Open-source examples, plus the 30-prompt premium PDF.
A prompt library is only useful if it's organised by when you'd reach for it. This page groups Claude Code prompts by workflow — open the section that matches what you're doing right now, paste, fill brackets, ship.
Review [DIFF or git diff main...HEAD] as a skeptical senior engineer.
Output a table: | file:line | severity 1-5 | category | one-line fix |.
Categories: correctness | security | performance | readability | testing.
Max 12 issues. If clean, say so and stop.You're the on-call engineer who'll be paged if this PR breaks at 3am.
Read the diff. For each line that could page you:
- file:line
- runtime failure mode (timeout, OOM, panic, partial write)
- symptom in logs/metrics
- rollback complexity (clean revert vs migration-required)
Sort by probability of paging.Trace execution path for this error: [TRACE]
Per frame: file:line + value of the variable that caused the next frame.
End: root cause in 1 sentence, minimal patch.Read [FILE]. Don't run tests yet. Find subtle logic bugs unit tests miss:
- off-by-one in loop bounds
- timezone or locale assumptions
- null/undefined "shouldn't happen" paths
- silent type coercion (== vs ===)
- race conditions in async state
For each: line, 1-sentence failure case, patched line. Max 7.Test [NAME] fails 1 in 5. Without running, list top 5 causes:
timing, shared state, IO leakage, randomness, ordering.
Per cause: the code reading to confirm/rule out (file:line),
deterministic fix, fix cost. Rank by likelihood.For [FN] in [FILE], write 8 tests using [FRAMEWORK]:
- 2 happy-path with distinct inputs
- 2 boundary (smallest/largest valid)
- 2 invalid (each raising expected error)
- 1 idempotence/invariant
- 1 regression for [KNOWN-BUG]
Do NOT mock [FN] or its module-internal calls. Mock only external IO.Read [FILE] and [TEST_FILE]. For each branch:
| branch | tested (yes/no/partial) | suggested test | priority |
Priority: High = reachable from user input, Medium = internal/critical,
Low = defensive code unlikely to trigger.Rename [OLD] to [NEW] across imports, definitions, tests, comments, README.
Touch no other code. Don't reformat. Don't remove "unused" imports.
After: run tests. Confirm green.Function [FN] in [FILE] has complexity [N]. Reduce to under 10 without
changing behaviour. Approach order: early returns → extract predicates →
lookup map for pure data → split function. Show diff. Run tests.Find dead code in [DIR]: never-called functions, unused imports,
zero-importer exports. Per finding: file:line, evidence, confidence
(high/med/low). Output as table. Do NOT delete — I'll review first.Write a README for [PROJECT]:
- First sentence hooks in 5 seconds (no "this project is a...")
- Working code in first 30 lines
- No marketing words ("powerful", "robust", "best-in-class")
- Non-goals section, at least 3 bullets
- Max 250 linesRead this diff. Output 5 lines: WHY (motivation), WHAT (user change),
HOW (approach), RISK (what breaks), TESTS (what verifies it).
Plain English. No "this PR aims to".Read commits between [TAG_A] and [TAG_B]. Generate a CHANGELOG entry:
- ### Added (new user-visible features)
- ### Changed (behaviour changes)
- ### Fixed (bug fixes)
- ### Removed (deprecations gone)
- ### Security (CVE-style)
One line each, in past tense, no commit hashes. Skip purely internal commits.Audit [DOCKERFILE]. Output a table of issues:
| line | severity | issue | minimal fix |
Check for: root user, latest tags, multi-stage absence, secret in env,
unnecessary packages, no HEALTHCHECK, no .dockerignore reference.
Then propose the smallest patch.To migrate [SYSTEM] from [OLD] to [NEW], output a 5-phase plan:
1. Behind a flag (default off)
2. Dark traffic (new path runs, old serves)
3. Canary (1% real traffic on new)
4. Full ramp
5. Remove old path
Per phase: success criteria, rollback steps, observability signals.Read .github/workflows/. For each workflow file:
- Triggers (push, PR, schedule, workflow_dispatch)
- Secrets used
- Runner type
- Caching configured? (yes/no)
- Approximate minutes consumed per run
Flag: workflows without caching, workflows triggered on every push to forks
(security risk), workflows running on costly runners when smaller would do.For [FEATURE], propose 3 approaches: obvious, different trade-off,
non-obvious. Each: 3-sentence description, files touched, biggest risk.
Rank by recommendation with 1-paragraph justification.
Do NOT write code yet.Before any code for [TASK], list:
- 3 hardest sub-problems
- Which existing function to extend vs write fresh
- Riskiest assumption
- A <20-line spike that could verify the riskiest assumption
Wait for "go".Pick 5–10 prompts you reach for weekly. Paste them into CLAUDE.md under workflow headings. Now in any session you can say "use the Stack-Trace Autopsy prompt on this error" and Claude pulls it from CLAUDE.md. No re-pasting.
This page is a curated selection. The full Claude Code Power Prompts library has 30 prompts across the same six categories, each with a TIP box explaining when to use it and which words matter most. 8-page PDF, instant Stripe download, £3 launch tonight (first 10 buyers), £5 standard. CC BY 4.0 licensed — share with your team, paste into CLAUDE.md, modify freely.