Copy, paste, use. No email signup, no account. Five real prompts from the 30-prompt Power Prompts pack — one per category — to show you the format.
Each of the five prompts below is structured the same way the paid pack is: a category tag, a one-sentence when to use it, the copy-paste prompt body (just fill in the [BRACKETS]), and a TIP box with the gotcha most people miss.
License: these five are CC0 — copy them into your wiki, team docs, or own blog without asking.
1
Code Review
Skeptical Senior Review
When you need a real review, not five paragraphs of generic advice.
Review the diff below as a skeptical senior engineer who has been burned in production.
For every issue you find:
1. Rate severity 1–5 (5 = will page someone, 1 = nitpick).
2. State the failure mode in one sentence — what breaks, and when.
3. Give a minimal one-line fix or a 3-line patch.
Group by severity descending. If there is nothing above severity 2, say so plainly.
Diff:
[PASTE GIT DIFF HERE]
TIP: Run after every git diff before opening the PR. Removes 80% of the round-trip with reviewers.
2
Debugging
Stack Trace Autopsy
When a stack trace looks scary but you suspect the real bug is two frames up.
Below is a stack trace and the function call that produced it. Treat this as an autopsy.
Output in this exact order:
1. **Likely root cause** (one sentence — not a hedged paragraph)
2. **Evidence chain** — bullet each frame from top to bottom with one line explaining its role
3. **First file/line I should open**
4. **One reproduce command** I can paste into a terminal
5. **One-line fix** if you can see it; "needs more info" if you cannot
Stack trace + invocation:
[PASTE STACK TRACE AND THE LINE THAT TRIGGERED IT]
TIP: Paste the full trace, including 'caused by' chains. Truncated traces force Claude to guess.
3
Testing
Coverage Risk Ranker
When you have 200 uncovered lines and 20 minutes before the release.
Here is a coverage report and the source file(s) it refers to.
Rank the uncovered code blocks by *production risk*, not by line count. For each, give:
- A risk score 1–10 (10 = silent data corruption; 1 = log line that never runs).
- The one specific scenario that would trip it in prod.
- A test name (no body needed) that would catch it.
Then: give me the top 5 only. I want to write 5 tests, not 50.
Coverage + source:
[PASTE COVERAGE OUTPUT + RELEVANT SOURCE]
TIP: Combine with git diff main to weight risk toward newly-added code only.
4
Architecture
Feature — 3 Approaches
When the obvious approach feels wrong and you want a third option you haven't considered.
I want to add this feature: [DESCRIBE FEATURE IN 2-3 SENTENCES].
Constraints:
- Stack: [LANGUAGES/FRAMEWORKS]
- Existing patterns to respect: [LIST]
- Things I cannot change: [LIST]
Propose three approaches:
1. **The obvious one** — what most engineers would do. Estimate effort and one downside.
2. **The clever one** — leans on an existing pattern in the codebase or stdlib feature. Estimate effort and the maintenance risk.
3. **The third option** — must be non-obvious. Not just "use a different framework". Either a smaller scope, a different decomposition, or a way to ship 60% of value in 20% of effort.
End with a recommendation and *why* — including which approach you'd pick if speed mattered most vs. if maintainability mattered most.
TIP: The recommendation matters less than option #3. The point is to break out of your first instinct.
5
Documentation
Hook-First README
When the README needs to make a stranger run the code in 30 seconds.
Write a README for the project below. It must follow this exact shape:
1. **Hook (5 seconds)** — one sentence that answers "why would I look at this?" without using "powerful", "comprehensive", or "robust".
2. **Working code (30 seconds)** — the minimum copy-pasteable example that produces visible output. No imports of files I haven't seen. No "[YOUR_KEY_HERE]" without telling me where to get one.
3. **What it does** — three bullets, each starting with a verb.
4. **What it doesn't do** — two bullets. Be honest.
5. **Install + run** — exact commands for the most common OS.
6. **Going further** — three links or sub-headings, no more.
Source / context:
[PASTE PROJECT FILES OR DESCRIPTION]
TIP: The 'what it doesn't do' section is the highest-trust signal in any README. Don't skip it.
🔓 5 more — unlock by tweeting
Five more CC0 prompts (Refactoring · Performance · Security · Onboarding · Commit Messages) are below. Tweet the page to reveal them — no follow needed, no email, no account check. Click the button → Twitter web intent opens → tweet → reload or hit the unlock-anyway link.
When you want to extract a function but keep behavior bit-identical.
Extract the highlighted block into a named function. Hard requirements:
1. No behavior change. Identical inputs must produce identical outputs & side effects.
2. The function name reads like English at the call site (no "processData", no "handleStuff").
3. Parameters in the order the caller would naturally think about them, not the order they happened to appear in the original block.
4. Output: the new function, the updated call site, AND a one-line rationale for the name you chose.
5. If you cannot do this without behavior change, say so and STOP — do not refactor anything else.
Code:
[PASTE FUNCTION OR FILE WITH BLOCK MARKED]
TIP: Use this with a unit test suite running. The "no behavior change" rule is only verifiable if you have green tests on both sides.
7
Performance
Hot Path Audit
When something feels slow but you don't have a profile yet.
Below is a function and the calling pattern. Audit it for performance as if profiler data isn't available.
Output:
1. **Three concrete suspects** — name the line, the data structure, or the syscall. No generic "maybe the loop is slow".
2. For each suspect: complexity in big-O AND a one-sentence explanation a non-PhD can follow.
3. **The cheapest experiment** I can run in 5 minutes to confirm which is the real bottleneck (e.g. log timing around line N, swap structure X for Y on a small input).
4. **The fix you would try** if experiment 3 confirms the top suspect.
Function + call pattern:
[PASTE FUNCTION AND HOW IT'S INVOKED]
TIP: Resist the urge to optimize on theory alone. Step 3 is the one that catches surprises.
8
Security
Pre-PR Threat Pass
5-minute security review before opening a PR that touches input handling or auth.
This diff touches [user input handling | authn/authz | secrets | file IO | network calls — circle one].
Do a focused threat pass. Output exactly four sections:
1. **Inputs that cross a trust boundary** — list each, where it enters, and whether it's validated/escaped before use.
2. **One concrete attack** that this diff makes possible OR easier, written as "an attacker who can [X] can now [Y]". If you cannot construct one, say so.
3. **Existing defenses** — what would have stopped the attack in (2), if anything.
4. **Minimum fix** — 1–3 lines max. If a real fix needs more, say "needs structural change" and stop.
Diff:
[PASTE DIFF]
TIP: The "if you cannot construct one, say so" line is critical — without it Claude will invent attacks to be helpful.
9
Onboarding
First-Hour Map
When someone joins your codebase and needs the right 5 files, not all 500.
You are mapping this codebase for a senior engineer who has 1 hour before standing up their first PR.
Output exactly:
1. **The 5 files they MUST read** — in the order they should read them. One sentence each on why.
2. **The 3 files they should AVOID for now** — too detailed, too historical, or too misleading. One sentence each on why.
3. **The one command that gets the project running locally** — exact command, no "then configure your env".
4. **The one test they should run to confirm setup** — exact command + expected first line of output.
5. **The mental model in 3 sentences** — what this project is, who calls it, where state lives.
Codebase context:
[PASTE README + DIRECTORY LISTING + ANY ARCHITECTURE.md]
TIP: Save the output to ONBOARDING.md at the repo root. Reuse it every time someone joins.
10
Commit Messages
Why-First Commit
When the diff is obvious but the reason is not — and future-you will need the reason.
Write a commit message for the diff below. Hard rules:
1. **Subject line ≤ 60 chars**, imperative mood, no trailing period.
2. **First body line answers WHY**, not WHAT. The diff already shows what changed.
3. If there is a non-obvious tradeoff or alternative considered, mention it in one line.
4. If the change has a deadline, ticket, or external trigger, name it once with the ID — no marketing copy.
5. No "Co-Authored-By", no signature, no "Generated by". Just the message.
Diff:
[PASTE DIFF]
Context I want included:
[OPTIONAL: ticket ID, related PRs, incident link]
TIP: Run this *before* writing your own message, then take whichever is clearer. It usually wins on rule (2).
Like the format? The full pack has 25 more.
The paid Claude Code Power Prompts PDF (8 pages, 30 prompts) extends every category above and adds DevOps & Deployment. Every prompt has a TIP box, every category opens with a "when not to use this" note, and the whole thing is laid out so you can paste your 5–10 favourites into CLAUDE.md — Claude Code auto-loads them every session.
30 prompts across 6 categories (vs. 5 here)
TIP boxes for every prompt — when to use, when not to
The CLAUDE.md trick — once-and-for-all setup so you never re-paste a prompt
Five prompts is enough to prove the format works for you. If you want all 30 (six categories, 8-page PDF, paste-into-CLAUDE.md trick), the full pack is 50p impulse-buy / 50p (was £5) / 30p+ pay-what-you-want.
Can I redistribute these?
Yes — the five prompts on this page are CC0. Copy them into your own docs, blog, or team wiki without asking.
Do they only work in Claude Code?
They work anywhere Claude works — Claude Code CLI, claude.ai, the API directly. The patterns are about how to frame the task, not Claude-Code-specific features.
What's actually different in the paid PDF?
25 more prompts across all six categories, every prompt has a TIP box explaining when not to use it, and the PDF is structured so you can paste the 5–10 you use most into CLAUDE.md at your project root — Claude Code loads them automatically every session.