Most LLM code reviews are polite and useless — "looks good, consider adding error handling." This prompt forces structured, actionable output. Every finding includes a severity, a location, and a concrete fix. Style preferences are explicitly excluded.

The prompt

Review the following code. For each issue found, provide:

1. **Severity** (critical / warning / suggestion)
2. **Location** (file and line reference)
3. **Issue** (what's wrong)
4. **Fix** (concrete code change)

Focus on:
- Bugs and logic errors
- Security vulnerabilities (OWASP top 10)
- Performance issues
- Readability and maintainability

Do NOT comment on style preferences or formatting. Only flag issues that affect correctness, security, or performance.

How to use it

In Claude Code (best): Run this in the project directory so Claude can read the actual files, follow imports, and understand the full context. Point it at specific files or a diff:

Review the changes in `git diff main...HEAD` using this approach: [paste prompt]

With pasted code: If you're using a chat interface, paste the code after the prompt. Less effective because the LLM can't follow imports or see the broader codebase.

When to use it

• Before opening a PR — catch issues before a human reviewer sees them
• During self-review when no other reviewer is available
• After a large feature branch — review the full diff against main
• When reviewing unfamiliar code you've inherited

Tips

• For large diffs, review file by file rather than the entire diff at once. LLMs lose focus on large inputs.
• If the review comes back clean, try following up with: "Now focus specifically on edge cases and error paths." A second focused pass often catches things the first pass missed.
• Pair this with the Critical Product Review Prompt — code review catches implementation issues, product review catches UX issues.