12 Claude Prompts for Coding, Debugging and Code Review

Explain this code to me. My level: [BEGINNER / I KNOW ANOTHER LANGUAGE / EXPERIENCED BUT NEW TO THIS CODEBASE]. Language or framework: [LANGUAGE].

<code>
[PASTE CODE]
</code>

1. Big picture first: in two or three sentences, what does this code do and why would someone write it?
2. Walk through it in order, a line or small block at a time. Say what each part does and why it's there. Explain any syntax, library call or pattern someone at my level might not know, and move quickly past what's obvious at my level.
3. Trace one concrete example: pick a realistic input and show how the key values change as it runs.
4. Point out anything surprising, risky or unidiomatic, labelled as an observation rather than a required fix.
5. Finish with 3 short questions I can answer to check my understanding, with the answers at the very end.

If the code depends on something not shown, like an imported function or a config value, tell me what you're assuming about it rather than assuming silently.

Help me debug this.

<error>
[PASTE THE FULL ERROR MESSAGE AND STACK TRACE]
</error>

<code>
[PASTE THE RELEVANT CODE, INCLUDING THE FUNCTION NAMED IN THE TOP STACK FRAME]
</code>

<context>
Language, framework and versions: [E.G. FROM YOUR LOCKFILE]
What I was doing: [ACTION OR COMMAND]
What I expected: [EXPECTED RESULT]
What I've already tried: [ATTEMPTS AND WHAT HAPPENED]
</context>

Please:
1. Explain what the error actually means, in plain terms.
2. List the most likely causes, ranked, with the evidence in my code for each.
3. For the top cause, give the fix as a minimal change to my code and explain why it works.
4. Tell me how to confirm the diagnosis: a print statement, a breakpoint, or a one-line test.

If you need more code or config to be confident, ask for the specific file or value rather than guessing. Keep the fix limited to this bug and leave unrelated code as it is.

Review this code the way a senior [LANGUAGE] engineer would in a careful code review.

<context>
What it's for: [ONE OR TWO SENTENCES]
Where it runs: [E.G. API HANDLER UNDER HEAVY LOAD, ONE-OFF SCRIPT, MOBILE APP]
What I'm most worried about: [E.G. CORRECTNESS, SECURITY, READABILITY, OR NOTHING SPECIFIC]
</context>

<code>
[PASTE CODE]
</code>

Check in this priority order: correctness and edge cases, error handling, security, performance where it matters for the context above, then readability and naming.

For each finding give:
- Severity: Bug, Risk, Improvement or Nit
- Where: line or function
- What's wrong, with a concrete input or scenario that triggers it
- The fix, as a small code snippet

Order findings by severity. Be direct: if something is wrong, say so plainly. If an area is fine, leave it out rather than padding the list. End with a one-line overall assessment and the single most important change to make.

Write a SQL query to answer this question: [QUESTION, E.G. WHICH 10 CUSTOMERS SPENT THE MOST IN THE LAST 90 DAYS, AND HOW MANY ORDERS DID EACH PLACE?]

Database: [POSTGRESQL / MYSQL / SQLITE / BIGQUERY / SNOWFLAKE / SQL SERVER]

<schema>
[PASTE CREATE TABLE STATEMENTS, OR TABLES AND COLUMNS WITH TYPES AND KEYS]
</schema>

<business_rules>
[E.G. EXCLUDE REFUNDED ORDERS, AMOUNTS ARE STORED IN CENTS, TIMESTAMPS ARE UTC]
</business_rules>

Please:
1. State how you're interpreting the question, including any ambiguity (does "spent" include tax? are cancelled orders counted?). If an ambiguity would change the result significantly, ask me before writing the query.
2. Write the query in my dialect: formatted for reading, with CTEs for multi-step logic and short comments on non-obvious lines.
3. Explain how it works, step by step.
4. Flag pitfalls: NULL handling, duplicate rows from joins, time zones, ties, and performance on large tables, including any index that would help.
5. Give me a quick sanity-check query to confirm the result looks right.

This query is too slow. Help me make it faster without changing its results.

Database and version: [E.G. POSTGRESQL, VERSION]
Current runtime: [E.G. 8 SECONDS]. Target: [E.G. UNDER 200 MS]
Table sizes: [ROW COUNT FOR EACH TABLE]

<query>
[PASTE QUERY]
</query>

<plan>
[PASTE EXPLAIN ANALYZE OUTPUT, OR PLAIN EXPLAIN IF ANALYZE IS TOO EXPENSIVE TO RUN]
</plan>

<schema_and_indexes>
[PASTE TABLE DEFINITIONS AND EXISTING INDEXES]
</schema_and_indexes>

1. Read the plan and tell me where the time goes: the most expensive nodes, full scans on large tables, row estimates that are far off, sorts or hashes spilling to disk.
2. Explain the root cause in plain language.
3. Propose fixes ranked by expected impact: indexes (the exact CREATE INDEX statement and its cost on writes), query rewrites, or schema changes. For each rewrite, explain why it returns identical results.
4. Tell me how to verify: what the new plan should look like and what to measure.

If the plan is missing, or the data distribution matters, ask me for what you need.

Write a regular expression for this.

Goal: [WHAT IT SHOULD MATCH, E.G. UK POSTCODES INSIDE FREE TEXT]
Flavour: [JAVASCRIPT / PYTHON / PCRE / GO / JAVA / GREP]
Use: [VALIDATE A WHOLE FIELD / FIND MATCHES IN TEXT / EXTRACT CAPTURE GROUPS / SEARCH AND REPLACE]

Should match:
[EXAMPLES, ONE PER LINE]

Should not match:
[EXAMPLES, ONE PER LINE]

Give me:
1. The regex, plus the exact line of code to use it in my flavour, with any flags.
2. A breakdown of each part and what it does.
3. A test table of at least 12 cases: my examples plus tricky ones you add (empty string, surrounding whitespace, near misses, unicode, very long input), each marked match or no match, with captured groups where relevant.
4. Limitations: valid input it would reject or invalid input it would accept, and whether a regex is the right tool here at all.

Keep it as readable as the problem allows, prefer patterns that run in linear time, and flag any risk of catastrophic backtracking.

Write a Python script that [WHAT IT SHOULD DO, E.G. RENAMES EVERY PHOTO IN A FOLDER BY THE DATE IT WAS TAKEN].

<requirements>
Input: [WHERE DATA COMES FROM: FILE, FOLDER, CSV, API, STDIN]
Output: [WHAT IT PRODUCES AND WHERE]
Runs on: [OPERATING SYSTEM, PYTHON VERSION, ONE-OFF OR SCHEDULED]
Dependencies: [STANDARD LIBRARY ONLY / PACKAGES ARE FINE]
</requirements>

<edge_cases>
[AWKWARD CASES YOU KNOW ABOUT, E.G. FILES WITH NO DATE, DUPLICATE NAMES, VERY LARGE FILES]
</edge_cases>

Before writing, list your assumptions and ask me about anything that would change the design.

Then write the script with:
- command-line arguments via argparse, with helpful --help text
- a --dry-run flag if it changes or deletes anything, printing what it would do
- clear error messages for bad input instead of raw tracebacks, and a non-zero exit code on failure
- small functions with type hints and a main() entry point
- comments only where the reason isn't obvious

After the code, give: install and run instructions, two example commands, and how each edge case is handled. Prefer the standard library unless a package makes the script much simpler.

Build a React component: [COMPONENT, E.G. A SEARCHABLE TEAM MEMBER LIST WITH AN INVITE BUTTON].

<stack>
[E.G. REACT WITH TYPESCRIPT, NEXT.JS, TAILWIND, TANSTACK QUERY]
</stack>

<behaviour>
[WHAT IT DOES, WHAT DATA IT NEEDS AND WHERE FROM, WHAT THE USER CAN DO]
</behaviour>

Requirements:
1. States: loading (a skeleton that matches the final layout), empty (a helpful message and the next action), error (a plain-language message with retry), success, and stress cases like very long names or 1,000 items.
2. Accessibility: semantic HTML first, labelled controls, full keyboard operation with a visible focus style, sensible focus placement after actions, and status changes announced to screen readers. WCAG AA contrast.
3. Props: a small, typed API. Explain each prop and its default.
4. Responsive down to 320px wide.
5. Use only what's in the stack above; ask before adding a dependency.

Output the component, a usage example, and a short list of the decisions you made and why. If the behaviour description is ambiguous in a way that changes the component's structure, ask first.

Design a REST API for [WHAT IT'S FOR, E.G. BOOKING FITNESS CLASSES].

<context>
Clients: [WHO CALLS IT: OUR WEB APP, A MOBILE APP, THIRD-PARTY DEVELOPERS]
Core entities and rules: [E.G. CLASSES HAVE A CAPACITY; MEMBERS CAN CANCEL UP TO 2 HOURS BEFORE]
Auth: [E.G. SESSION COOKIES, API KEYS, OAUTH]
Scale and constraints: [EXPECTED VOLUME, EXISTING SYSTEMS TO INTEGRATE WITH]
</context>

Give me:
1. Resources and relationships, with fields for each (name, type, required, notes).
2. An endpoint table: method, path, purpose, auth required, success status code.
3. Example request and response JSON for the 3 most important endpoints.
4. One consistent error format, and which status codes you'll use when (400 vs 422, 401 vs 403, 404, 409).
5. Pagination (cursor or offset, and why), plus filtering and sorting conventions.
6. Idempotency for create and payment requests, handling of concurrent writes such as double booking, and rate limits.
7. A versioning approach and what counts as a breaking change.

Use plural nouns, consistent casing and standard HTTP semantics. Where the design forces a business decision I haven't specified, call it out and ask me.

Write a README.md for my project.

<project>
What it does and for whom: [ONE OR TWO SENTENCES]
Stack: [LANGUAGES, FRAMEWORKS, SERVICES]
How I install and run it today: [COMMANDS]
Configuration: [ENVIRONMENT VARIABLES AND WHAT EACH DOES]
Anything else: [DEPLOYMENT, CONTRIBUTING RULES, LICENCE]
</project>

[OPTIONAL: PASTE YOUR PACKAGE MANIFEST AND MAIN ENTRY FILE]

Structure:
1. Name and a one-line description of what it does, stated plainly.
2. Quick start: the fewest steps to run it locally, as copyable commands, with prerequisites and versions.
3. Usage: the 2 or 3 most common tasks, with real examples and expected output.
4. Configuration: a table of environment variables with required, default and description. Use placeholder values only.
5. Project structure: key directories, one line each.
6. Development: running tests, lint and build.
7. Troubleshooting: the errors people are most likely to hit, and the fixes.

Write for a developer who has never seen the project: concise and concrete. Use only commands and facts from what I've given you, and mark anything you had to assume with [TODO: CONFIRM].

Write unit tests for this function using [TEST FRAMEWORK, E.G. PYTEST / JEST / VITEST / JUNIT / GO TESTING].

<code>
[PASTE THE FUNCTION AND ANY TYPES OR HELPERS IT USES]
</code>

<intended_behaviour>
[WHAT IT SHOULD DO, INCLUDING RULES THAT AREN'T OBVIOUS FROM THE CODE]
</intended_behaviour>

1. First list the test cases as a table: case name, input, expected result, and why it matters. Cover the normal path, boundaries (empty, zero, one, maximum, off-by-one), invalid input, error handling, and any state changes or side effects.
2. Then write the tests: one behaviour per test, descriptive names, arrange-act-assert layout, and parametrised tests where cases share a shape. Mock only external things such as network, clock and randomness.
3. Take expected values from the intended behaviour above, not from what the code currently returns. Where the code disagrees with the intended behaviour, write the test for the intended behaviour and flag it to me as a probable bug.

End with any behaviour you couldn't test without changing the code, and the smallest change that would make it testable.

Review my system design as a skeptical principal engineer. I want honest critique rather than reassurance, because I'd rather find the problems now than in production.

<design>
[DESCRIBE OR PASTE THE DESIGN: COMPONENTS, DATA STORES, HOW REQUESTS FLOW, EXTERNAL SERVICES]
</design>

<requirements>
Users and load: [E.G. 50,000 DAILY USERS, PEAK 300 REQUESTS PER SECOND]
Data: [VOLUME, GROWTH, RETENTION]
Latency and availability targets: [E.G. P95 UNDER 300 MS, 99.9% UPTIME]
Team and budget: [TEAM SIZE, OPS EXPERIENCE, COST LIMITS]
</requirements>

Analyse:
1. Bottlenecks: what saturates first as load grows 10x, and roughly when.
2. Failure modes: what happens when each dependency is slow or down, retries that could cascade, data that could be lost or duplicated.
3. Consistency and data integrity.
4. Security and multi-tenancy risks.
5. Operational burden: what this team will find hard to deploy, monitor or debug.
6. Over-engineering: parts more complex than the requirements justify.

For each issue: severity, the scenario where it bites, and the simplest fix. Then list the 3 riskiest assumptions and a cheap way to test each. End with a verdict (ship as is, ship with changes, or rethink) and why.