Code review prompts: catch bugs before you merge

Use this after you or Claude change some code and before you commit it.

You are a senior engineer reviewing a change before it is merged. Your only job in this review is correctness: code that does the wrong thing, crashes, loses data or breaks something that used to work. The change is meant to do this: [ONE OR TWO SENTENCES ON WHAT THE CHANGE IS FOR]. Process: 1. Run `git diff` to see the uncommitted changes. If there are none, run `git diff HEAD~1` to see the last commit. 2. Read every changed file in full, plus any file that calls the changed code. Never comment on code you have not opened. 3. For each problem you find, work out a concrete input or sequence of steps that makes it fail. Output a numbered list of findings. For each one give: - Severity: high (breaks for real users), medium (breaks in a rare case) or low (wrong but harmless today) - File and line - What goes wrong, in one or two sentences - The input or steps that trigger it - The smallest fix - Your confidence: certain, likely or a guess Leave out style, naming and formatting. If you find no real problems, say so plainly. An empty review is a good result when the code is sound. Do not change any files.

Swap the highlighted parts for your own words.

Tips

• Claude Code also has a built in review command. Type /code-review to check your current changes for bugs. Add --fix, as in /code-review --fix, if you want Claude to apply what it finds.
• Ask "write a test that proves finding 2" for any finding you doubt. A failing test settles it.

Use this when a change touches logins, payments, user input, files, or anything that talks to the internet.

You are an application security reviewer. Review my current changes for security problems. Context: this project is [WHAT THE PROJECT IS AND WHO USES IT]. Data it handles that must stay private: [FOR EXAMPLE EMAILS, PAYMENT DETAILS, NOTHING SENSITIVE]. Process: 1. Run `git diff` and read each changed file in full. 2. Trace every piece of outside input (forms, URLs, uploaded files, API requests, environment variables) from where it enters to where it is used. 3. Check each of these: injection (SQL, shell commands, HTML), missing or broken login and permission checks, secrets or keys written in the code, private data sent to logs or the browser, unsafe file paths, new packages added and what they can do. Output a table with columns: Risk, Where (file and line), How someone could exploit it, How likely it is (high, medium, low), Fix. Under the table, list anything you could not check, such as server settings that live outside the code. Report only real risks you can point to in the code. If the change is safe, say so. Do not change any files.

Swap the highlighted parts for your own words.

Tips

• Claude Code has a /security-review command that checks the changes on your branch for security problems. It compares your branch with the main branch on origin, the online copy of your project (for example on GitHub), so it needs one set up.
• Treat this as a first pass. For anything that handles money or health data, get a security professional to review it too.

Use this when a feature works for the normal case and you want to know where it breaks.

Look at [FILE OR FUNCTION NAME]. It is meant to [WHAT IT SHOULD DO]. I want to find the inputs and situations where it breaks. Read the code and every function it calls first. Then go through this list and, for each item that applies, say exactly what the code does today: 1. Empty input, missing fields, null values 2. Very large input (a 10,000 item list, a 5 MB file, a very long string) 3. Unusual text: emoji, accented letters, right to left languages, leading or trailing spaces 4. Numbers: zero, negative, decimals, very large 5. Dates and times: time zones, midnight, leap years, daylight saving changes 6. Two users or requests doing the same thing at the same moment 7. The network or a service it depends on failing or being slow 8. A user doing steps out of order, twice, or pressing back Output a table: Case, What happens now, Is that acceptable (yes or no), Test to prove it. Then write tests only for the rows marked no, run them, and show me the output. Do not fix anything yet.

Swap the highlighted parts for your own words.

Tip

• Cut the list to the items that matter for your feature. A page with no dates does not need the date checks.

Use this on your first day in a project you did not write, or one you have forgotten.

I am new to this codebase and need a map of it. Investigate before you answer: open the files you describe, and do not guess about code you have not read. Give me: 1. What the project does, in three sentences a non programmer could follow. 2. How to run it and how to run its tests, with the exact commands. Check the README and the package or config files. 3. The main folders and what lives in each one. 4. The entry points: where a request, a page load or a command starts. 5. One real journey through the code, such as what happens when a user [A COMMON ACTION, FOR EXAMPLE SIGNS UP], file by file. 6. Where data is stored and how it gets there. 7. The five files I should read first, in order, and why. 8. Anything that looks fragile, unusual or out of date. Mark anything you inferred without confirming as (guess). Keep each section short.

Swap the highlighted parts for your own words.

Tips

• Ask Claude to save the answer to a file such as CODEBASE-MAP.md if you want to keep it. A .md file is a plain text file you can open in any editor.
• Follow up with "how does [PART] work?" for anything that is still unclear.

Use this when one function or file makes no sense to you.

Explain this code to me. I understand [YOUR LEVEL, FOR EXAMPLE BASIC JAVASCRIPT] but this part loses me. <code> [PASTE THE CODE, OR IN CLAUDE CODE WRITE THE FILE PATH AND FUNCTION NAME] </code> 1. Say what it does in one sentence. 2. Walk through it in order, a few lines at a time, saying what each part does and why it might be written that way. 3. Explain any term or pattern I may not know the first time it appears. 4. Show what it returns for one realistic example input. 5. Point out anything that looks like a bug or a trap. If the code depends on other code I have not shown you, say what you are assuming about it.

Swap the highlighted parts for your own words.

Use this when a project has grown and you suspect parts of it are never used.

Find code in this project that is never used: functions, files, components, exports, settings and packages that nothing calls. Process: 1. List candidates by searching for every place each one is referenced. 2. Check for uses that a plain search misses: names built from strings, routes loaded by file name, things called from config files, tests or scripts, and anything exported for other projects to use. 3. Sort every candidate into one of three groups: - Safe to delete: no references anywhere, with the search you ran as evidence - Probably unused: no direct references, but it could be loaded dynamically - Looks unused but is not: explain what uses it Output the three groups as tables with columns: Item, File, Evidence. Do not delete anything. I will choose what goes.

Tip

• Delete the safe group in one commit, run your tests and the app, then deal with the probably unused group one item at a time.

Use this on a finished branch, just before you merge it into your main code.

You are reviewing a finished branch before it is merged. Judge it against what it was meant to do. What it was meant to do: [PASTE THE TASK, THE ISSUE, OR WRITE "READ PLAN.md"]. Process: 1. Run `git diff main...HEAD` to see everything this branch changes. Use the right name if the main branch is not called main. 2. Run the tests and the build, and show me the commands and their output. 3. Check each item below and mark it pass, fail or not relevant: - Every requirement is done - Nothing was added that the task did not ask for - Tests cover the new behaviour and they pass - Nothing that used to work is broken - Database or settings changes are included and can be undone - No secrets, debug logs or leftover test code 4. Give a verdict: merge, fix first (list what), or do not merge (say why). Flag only problems that affect correctness or the stated requirements. List style suggestions separately as optional. Do not change any files.

Swap the highlighted parts for your own words.

Tip

• If the verdict is fix first, paste the list back into a new session and ask Claude to fix those items only.

Use this straight after Claude says a task is done, before you trust it.

Assume the change you just made is wrong, and try to prove it. 1. Write the three strongest arguments that this code is incorrect, incomplete or will cause trouble later. Make each one specific, with a file and line. 2. For each argument, test it: read the code again, run it, or write a quick test. Show the evidence. 3. Say which arguments held up and which fell apart. 4. Fix only the ones that held up, then run the tests and show the output. Be honest. If all three fall apart, say the code survived and stop there. Do not make changes to win the argument.

Tip

• This works best in a fresh session or a subagent, a helper Claude that starts with no memory of writing the code. Try: "Use a subagent to review this change and try to prove it is wrong."

Use this when a teammate asks you to review their work and you want to leave useful comments.

Help me review a teammate's pull request, a proposed change waiting to be merged. I am on their branch now. What the pull request says it does: [PASTE THE DESCRIPTION]. 1. Run `git diff main...HEAD` and read the changed files in full. 2. Find real problems: bugs, missing cases, security risks, and places where it does not match the description. 3. Note one or two things that are done well, if there are any. 4. Draft review comments I can post. Each comment should name the file and line, explain the problem in a sentence or two, and suggest a fix. Keep the tone friendly and direct. Ask a question where you are unsure. Output the comments grouped as: must fix, should fix, optional. Do not post anything or change any files. I will post the comments myself.

Swap the highlighted parts for your own words.

Tip

• /code-review followed by a pull request number, such as /code-review 1234, reviews that pull request directly. Add --comment to post the findings on the pull request for you.

Use this when you only have the Claude app and want a second opinion on a file.

Review this code for bugs. It is written in [LANGUAGE] and it is meant to [WHAT IT SHOULD DO]. <code> [PASTE THE CODE] </code> 1. List real bugs first, with the line, what goes wrong and an example input that triggers it. 2. Then list edge cases it does not handle. 3. Then list anything risky for security. 4. Show a corrected version of only the lines that need changing. You can only see this code, so say what you are assuming about the rest of the project. If the code looks correct, say so.

Swap the highlighted parts for your own words.

Tip

• Paste the error message too if there is one. It narrows the review.

Use this after any review above, once you have a list of problems.

Here are review findings for this project: <findings> [PASTE THE FINDINGS] </findings> 1. Check each finding against the code first. Mark any that are wrong and explain why. 2. For the real ones, fix them one at a time, most severe first. 3. After each fix, run the tests and show the output before moving to the next one. 4. Make the smallest change that fixes each problem. Leave the surrounding code alone. At the end, give me a short list: finding, what you changed, test result.

Swap the highlighted parts for your own words.

Tip

• A reviewer asked to find problems will report some even in good code. Step 1 stops Claude fixing problems that are not there.