10 Claude Prompts for Coding, Debugging & Code Review

Debug this with me. Do NOT propose a fix yet.

The bug: [what happens vs. what should happen]
When it started: [and what changed around then, if known]
Error output / stack trace:
[paste]

Relevant code:
[paste]

Step 1 only: list the 4–5 most likely root causes, ranked by probability given the evidence. For each: what additional evidence (log line, test, inspection) would confirm or eliminate it, cheapest evidence first.

Wait for my results before proposing any fix.

Review this code as a skeptical senior engineer who has to maintain it at 3am during an incident.

[paste code or diff]

Context: [what it does, traffic/scale, what's downstream of it]

Review in this order:
1. Correctness: inputs or states that produce wrong behavior. Give the concrete failing input, not "might have edge cases".
2. Failure modes: what happens when the network call fails, the list is empty, the same request arrives twice?
3. Security: injection, authz gaps, secrets, unsafe deserialization — only if actually present.
4. Maintainability: what will the next person misunderstand?

Rank findings by severity. Skip style nits unless they hide bugs. If it's solid, say so — don't invent findings.

I want to refactor this, but safely and incrementally.

Code: [paste, or describe the module + its worst parts]
Why now: [what pain triggered this]
Constraints: [test coverage state, deploy frequency, can't break API, etc.]

Produce a refactoring plan, not refactored code:
1. The target design in a short paragraph — what good looks like.
2. Ordered steps where EACH step leaves the code working and shippable (no big-bang rewrites).
3. For each step: risk level, and the test to add BEFORE making it.
4. The steps I should skip because their cost exceeds the pain they cure.
5. Where to stop: what "good enough" looks like so this doesn't become a rewrite.

Write tests for this code — but design them to FIND bugs, not to confirm it works.

[paste code]

Test framework: [jest / pytest / go test / etc.]

Cover, in priority order:
1. Boundary values: empty, one, maximum, unicode, negative, zero.
2. The error paths: every throw/return-error branch, exercised.
3. Concurrency or ordering issues if any state is shared.
4. The "two features interact" cases — the bugs unit tests usually miss.

For each test, a one-line comment: what bug it would catch. If you spot a probable bug while writing tests, STOP and report it before continuing.

Help me make an architecture decision and write the ADR.

Decision: [e.g. "queue: SQS vs. Redis streams vs. Postgres SKIP LOCKED"]
System context: [scale, team size, existing stack, ops maturity]
Requirements: [throughput, latency, durability, budget — the real numbers]

1. Kill any option that fails a hard requirement — show why.
2. Compare survivors on: operational burden (who gets paged?), failure modes, cost at 10x scale, and how hard each is to migrate AWAY from later.
3. Recommend one. State the conditions under which you'd reverse this recommendation.
4. Write the ADR: context, decision, consequences (good AND bad), revisit trigger.

Explain this legacy code I inherited. No judgment, just archaeology.

[paste code — or in Claude Code, point at the directory]

1. What does it actually do? Walk the main flow in plain English.
2. Reconstruct the history: which parts look original vs. bolted on? What requirements can you infer from the weird parts? (Weird code usually encodes a forgotten requirement.)
3. Where are the load-bearing walls — the parts everything depends on that I must not touch casually?
4. What's genuinely dead vs. only looks dead?
5. If I must modify [the thing you need to change], what's the smallest safe intervention?

This is slow and I want to know WHY before optimizing anything.

What's slow: [operation, current timing, target timing]
Scale: [data sizes, request rates]
Code / query:
[paste]

1. Where does the time most plausibly go? Rank the candidates (algorithmic complexity, I/O waits, N+1 queries, allocation churn, lock contention...).
2. For the top 3 candidates: the measurement that would confirm each (specific profiler, EXPLAIN ANALYZE, timing harness) — measurements first, always.
3. For the likely winner: the fix, its expected gain, and its cost in complexity.
4. Tell me plainly if the honest answer is "this is fast enough, spend your time elsewhere."

Design the API for [feature/service] before any implementation.

Consumers: [who calls it — internal services, public devs, a frontend team]
Operations needed: [the use cases, not the endpoints]
Constraints: [REST/GraphQL/gRPC, auth model, existing conventions]

Deliver:
1. The resource model and endpoints/operations, with example requests and responses (realistic payloads, not foo/bar).
2. The hard 20%: pagination, partial failure, idempotency, versioning, rate limits — decided, not deferred.
3. Three future requirements this design should survive, and one it deliberately doesn't (and why that's fine).
4. The mistake most APIs in this domain make, and how this design avoids it.

Security review this before I ship it. Assume a motivated attacker, not a scanner.

[paste code/diff — auth flows, input handling, and anything touching money or PII are highest value]

Context: [what it protects, who the users are, internet-facing or internal]

Check specifically:
1. Input trust: every place external data reaches a query, command, path, template, or deserializer.
2. AuthN vs AuthZ: not just "is someone logged in" but "can THIS user do THIS to THIS resource?" (IDOR is the one everyone misses.)
3. Secrets, tokens, and what leaks into logs or error messages.
4. The abuse case: how would someone use this feature exactly as built to do harm?

Report: severity, the attack scenario in one sentence, the fix. No theoretical findings without a plausible path.

Turn this diff into a reviewable pull request.

[paste diff, or in Claude Code just say "the current branch vs main"]

Write:
1. PR title: imperative, under 65 characters, says what changed not how.
2. Description: the WHY in two sentences, then what changed (grouped logically, not file-by-file), then how it was tested.
3. Call out for reviewers: the risky part, the part you want scrutiny on, and any decision you want validated.
4. If this diff is really 2+ unrelated changes, say so and propose the split.