Code review prompt builder
LLMs are surprisingly good code reviewers — but only if you ask precisely. A bare “review this code” tends to produce praise and a few surface nits. The code review prompt builder assembles a structured prompt that fixes the language, sets the review depth, narrows to the areas you actually care about, and pins down the output format, so the model returns ranked, actionable findings with concrete fixes.
How it works
You choose a language, a review depth (quick pass, standard, or deep), the priority areas to focus on — security, performance, readability, correctness, tests, API design — and an output format. The tool composes a prompt that instructs the model to base every comment on the code it can actually see, to explain each issue and give a specific fix, and to format results the way you asked (grouped by severity, a table, inline comments, or JSON). Everything is generated locally; there’s no API key and no network call. You paste your code into the marked block and run it in any LLM.
What the three depth levels actually check
Quick pass is designed for speed — it focuses only on clear correctness bugs and obvious security issues. Think of it as the check you run on a small hotfix or a config change before merging. It skips style, performance micro-optimizations, and API ergonomics.
Standard is the default for most pull requests. It covers correctness (including edge cases the happy path misses), security concerns, readability and naming, and whether the key behaviors appear to be tested. The model is also asked to flag functions that are hard to test, as a signal to refactor.
Deep is a full line-by-line review intended for security-sensitive, performance-critical, or architecturally significant code. In addition to everything in standard, it looks at concurrency and race conditions, memory and resource management, API design decisions, and testability of the overall module. Expect longer, more detailed output.
Choosing a focus area
Selecting specific focus areas does more than narrow the review — it changes the model’s framing. A security-focused review asks “how could this be exploited?” for every function. A performance review asks “what does this do on large inputs?” A readability review asks “would a new team member understand this six months from now without the context you have today?” Choosing all areas at once dilutes all of these framings into a generic pass.
Tips and notes
- Match depth to the moment. A quick pass is right for a hotfix PR; reserve deep reviews for security-sensitive or concurrent code.
- Fewer focus areas, sharper review. Checking everything dilutes attention; pick the two or three areas that matter most for this change.
- Use JSON output for automation. It drops cleanly into a CI annotation step or a dashboard, where free-form prose can’t.
- Keep the code self-contained. Paste enough context that the model isn’t guessing — the prompt explicitly forbids inventing code it can’t see.