Back to cookbook

ChatGPT Prompt to Review Code for Bugs, Style, and Security Issues

8 views Updated

Make this prompt yours

Share

This code review prompt turns ChatGPT, Claude, or Gemini into a thorough reviewer that checks a diff or file for bugs, style problems, and security issues before it reaches a human reviewer or gets merged. It's built for developers, tech leads, and teams who want a consistent first pass on pull requests, especially when review bandwidth is tight or a change touches unfamiliar code.

Instead of a vague "check my code" request, the prompt sets explicit review categories (correctness, security, readability, performance, test coverage) and asks the model to cite specific line numbers or code snippets for each finding, rather than giving general praise or vague warnings. This makes the output something a developer can act on directly, and it keeps the model from skipping categories it finds less interesting.

Because review quality depends heavily on how the instructions are structured, running this template through the Prompt Optimizer in Coding mode before using it on a large or unusual codebase can tighten the constraints and catch ambiguity that would otherwise lead to shallow feedback.

Prompt template

Make this prompt yours

prompt-template
323 tokens
You are an experienced software engineer performing a code review. Review the following code change for issues a careful human reviewer would catch before approving a pull request. Context: - Language/framework: [LANGUAGE AND FRAMEWORK] - Style guide or conventions to follow: [STYLE GUIDE, e.g. PEP 8, Airbnb JS, or "none specified"] - Purpose of this change: [ONE-SENTENCE DESCRIPTION OF WHAT THE CHANGE DOES] Code to review: [PASTE DIFF OR FULL FILE CONTENTS HERE] Review the code across these categories, in this order: 1. Correctness β€” logic errors, edge cases, off-by-one errors, null/undefined handling 2. Security β€” injection risks, unvalidated input, broken access control, exposed secrets 3. Readability β€” unclear naming, missing comments where logic is non-obvious, overly complex functions 4. Performance β€” unnecessary loops, redundant computation, inefficient queries 5. Test coverage β€” missing tests for new logic or edge cases Constraints: - Cite the specific line number or exact code snippet for every finding - Label each finding as Blocking, Should-fix, or Nitpick - Do not rewrite the code β€” describe the issue and suggest a fix in words - If a category has no issues, state that explicitly rather than skipping it Output format: For each category, list findings as: [Severity] Line/snippet: [code reference] Issue: [what's wrong] Suggested fix: [brief description] End with a one-line overall verdict: Approve, Approve with comments, or Request changes.

Want it sharper? Optimize this prompt with Prompt Optimizer, check it with the Prompt Debugger or shorten it with the Token Optimizer.

Example input

example-input
96 tokens
Language/framework: Python, Flask Style guide: PEP 8 Purpose: Add an endpoint that lets users update their email address Code: @app.route('/update-email', methods=['POST']) def update_email(): user_id = request.form['user_id'] new_email = request.form['email'] query = "UPDATE users SET email = '" + new_email + "' WHERE id = " + user_id db.execute(query) return 'OK'

Example output

example-output
338 tokens
  1. Correctness [Blocking] Line: db.execute(query) Issue: No validation that new_email is a well-formed email address before writing it to the database. Suggested fix: Validate the email format (e.g. with a regex or a validation library) before running the update.

  2. Security [Blocking] Line: query = "UPDATE users SET email = '" + new_email + "' WHERE id = " + user_id Issue: SQL injection vulnerability β€” user_id and new_email are concatenated directly into the query string with no sanitization. Suggested fix: Use parameterized queries, e.g. db.execute("UPDATE users SET email = %s WHERE id = %s", (new_email, user_id)).

[Should-fix] Line: user_id = request.form['user_id'] Issue: No check that the requesting user is authorized to update this specific user_id β€” any authenticated (or unauthenticated) request could update an arbitrary account. Suggested fix: Verify user_id matches the authenticated session's user before applying the update.

  1. Readability [Nitpick] Function: update_email Issue: Function has no docstring explaining what it does or what parameters it expects. Suggested fix: Add a short docstring describing the endpoint's purpose and expected form fields.

  2. Performance No issues found β€” this is a single lightweight update operation.

  3. Test coverage [Should-fix] Issue: No tests included for invalid email formats, missing fields, or unauthorized update attempts. Suggested fix: Add tests covering a valid update, an invalid email format, a missing field, and an unauthorized user_id.

Overall verdict: Request changes.

When to use it

  • Before opening a pull request, to catch obvious bugs and style issues the author missed
  • As a first-pass reviewer on PRs from junior developers or contractors before a senior engineer reviews them
  • When reviewing unfamiliar code you inherited, such as a legacy module or a teammate's work while they're out
  • When a CI pipeline doesn't run a linter or static analysis tool and you need a quick manual check for common issues

Best practices

  • Paste the actual diff or full file contents, not a description of the change, so the model can cite real line numbers
  • Tell the model the language, framework, and any style guide you follow (e.g. PEP 8, Airbnb JS) so it doesn't flag non-issues
  • Ask for findings ranked by severity (blocking, should-fix, nitpick) so you can triage quickly instead of reading a flat list
  • For security-sensitive code (auth, payments, user input handling), ask the model to specifically check for injection, access control, and data exposure risks rather than relying on a generic pass

Common mistakes

  • Pasting only the changed lines without surrounding context, which makes it impossible for the model to spot issues caused by how the change interacts with the rest of the function
  • Not specifying the language or framework, leading to generic feedback that doesn't account for framework-specific conventions
  • Treating the review as final instead of verification β€” the model can miss issues that depend on runtime behavior or data it can't see
  • Asking for a review and a rewrite in the same prompt, which often produces a rewritten version that silently fixes issues instead of explaining them, so you don't learn what was wrong

FAQs

What's the best ChatGPT prompt for reviewing a pull request?

The most effective prompts give the model explicit review categories (correctness, security, readability, performance, test coverage), ask it to cite specific line numbers for each finding, and request a severity label for every issue. A vague "review this code" request tends to produce generic praise instead of actionable feedback, so structure matters more than wording.

Can AI code review catch security vulnerabilities like SQL injection?

Yes, for common patterns like string-concatenated SQL queries, unvalidated user input, or missing authorization checks, a model reviewing the actual code can flag these reliably. It's less reliable for vulnerabilities that depend on how the code behaves at runtime or interacts with infrastructure it can't see, so it should supplement rather than replace a security-focused review or scanning tool.

Should I use ChatGPT or Claude for code review?

Both can perform structured code review well when given the same category-based prompt; the meaningful difference tends to be context window size for reviewing large diffs or multi-file changes rather than which model is "better" at spotting bugs. Test the same prompt on a known problematic snippet in each to see which catches more of your team's common issues.

How do I get consistent code review feedback across different PRs?

Reuse the same structured prompt template for every review rather than writing a new ad hoc request each time, and keep the category list and severity labels identical. This is also what makes AI review output comparable across PRs and easier for a team to standardize on.

Which Cuelara tool can help me strengthen this code review prompt before using it on a large codebase?

Prompt Optimizer β€” its Coding mode is built to tighten vague or loosely structured instructions into the kind of explicit, category-based prompt that produces specific, line-cited findings instead of generic feedback.

Found this prompt useful? Share it.

Share

More in Code Generation & Software Engineering

Code Generation & Software Engineering

Prompt to Generate Unit Tests From a Function

This prompt turns an existing function into a set of unit tests covering its normal behavior, edge cases, and error handling, built for deve…

You are a senior software engineer writing unit tests.

Function to test:
[PASTE THE FUNCTION CODE]

Language and test framework: [E.G. TYPESCRIPT WITH VITEST, PYTHON WITH PYTEST]

Instructions:
1. Write tests covering normal, expected inputs.
2. Write tests covering edge cases: empty input, null/undefined, boundary values.
3. Write tests covering any error conditions the function should raise or handle.
4. Use clear, descriptive test names that state what is being verified.
5. Return only the test code, in a single code block, ready to run.

Output format: one fenced code block containing the complete test file.

Make this prompt yours

Code Generation & Software Engineering

Claude Prompt to Refactor Legacy Code for Readability and Maintainability

This Claude prompt for refactoring legacy code is built for developers who've inherited a function or module that works but is hard to read,…

Role: You are a senior software engineer specializing in code readability and maintainability.

Context:
Language/framework: [LANGUAGE_AND_VERSION]
Style guide or conventions to follow: [STYLE_GUIDE_OR_LINTING_RULES]
What this code does: [BRIEF_DESCRIPTION_OF_FUNCTIONALITY]
Constraints (things that must not change): [PUBLIC_API_SIGNATURES_OR_OTHER_CONSTRAINTS]

Code to refactor:
[PASTE_FULL_FUNCTION_OR_FILE_HERE]

Instructions:
1. Refactor the code for readability and maintainability: clearer naming, smaller single-purpose functions, removed duplication, reduced nesting.
2. Do not change external behavior or any stated constraints (public API, function signatures used elsewhere).
3. List each change you made, one by one, with a short reason for it.
4. Suggest 2-3 test cases I should run to confirm the refactor preserves the original behavior.
5. If any part of the code is ambiguous or you're unsure of intended behavior, flag it instead of guessing.

Output format:
1. Refactored code in a fenced code block
2. A numbered list of changes with a one-line reason for each
3. Suggested test cases

Make this prompt yours

Code Generation & Software Engineering

ChatGPT Prompt to Debug an Error From a Stack Trace

A debug stack trace prompt gives ChatGPT, Claude, or Gemini the exact error message, the stack trace, and the relevant code so it can find t…

ROLE: You are an experienced [PROGRAMMING LANGUAGE] developer helping debug a runtime error.

CONTEXT:
- Language/runtime: [LANGUAGE AND VERSION, e.g. Python 3.11, Node 20]
- Framework/libraries involved: [FRAMEWORK NAMES AND VERSIONS]
- What the code is supposed to do: [BRIEF DESCRIPTION OF THE FEATURE OR FUNCTION]
- Error message and full stack trace:
[PASTE FULL ERROR MESSAGE AND STACK TRACE HERE, TOP TO BOTTOM, UNEDITED]

- Relevant source code (include every function/file named in the trace):
[PASTE CODE FOR EACH FRAME IN THE STACK TRACE]

- What I've already tried: [LIST ANY FIXES OR CHECKS ALREADY ATTEMPTED, OR WRITE "NOTHING YET"]

CONSTRAINTS:
- Do not suggest a fix until you've identified the specific line and condition that triggers the exception
- If the trace doesn't contain enough information to be certain, say so and list what additional information (logs, input values, config) would confirm the cause
- Do not assume framework defaults that weren't stated β€” ask if a detail is missing rather than guessing

OUTPUT FORMAT:
1. Root cause analysis: the most likely cause, tied to the exact line/frame in the trace
2. Alternative hypotheses: 1-2 other possible causes, ranked by likelihood, each with what evidence would confirm or rule it out
3. Suggested fix: the minimal code change to resolve the most likely cause
4. Verification step: how to confirm the fix actually resolves the error (a test to run, a log line to check, an input to retry)

Make this prompt yours