Build a code review prompt that asks for bug, security, performance, maintainability, test, and patch guidance without exposing private code unnecessarily. The builder runs locally in your browser.
Direct answer: A strong code review prompt includes the language, change context, code excerpt, risk areas, project constraints, and desired output format. Ask the model to separate confirmed issues from hypotheses, rank severity, cite evidence from the code, and propose the smallest safe fix.
Interactive engineering prompt builder
Replace the examples with sanitized engineering context. The generated prompt updates locally in your browser; Omellody does not receive these inputs.
Copy-ready base prompt
Act as a senior software engineer doing a careful code review.
Language and runtime: {language}
Change context: {change_context}
Code excerpt or sanitized diff: {code_excerpt}
Risk focus: {risk_focus}
Constraints: {constraints}
Output format: {output_format}
Return:
1. A direct summary of whether this change looks safe to merge.
2. A severity table with issue, evidence from the code, impact, confidence, and suggested fix.
3. Security and data-handling risks, including secrets, injection, authorization, validation, and logging risks.
4. Performance, reliability, concurrency, and edge-case concerns.
5. Missing tests with concrete test names and fixtures.
6. A smallest-safe-patch suggestion or pseudocode diff.
7. Questions for the author if the code context is insufficient.
Rules: do not invent files that were not provided; distinguish confirmed problems from hypotheses; prefer minimal changes; flag anything that requires a human reviewer or production context.
TypeScript on Node 22, React 19, Python 3.12, Go service, SQL migration
{change_context}
Change context
pull request adds payment retry logic and updates webhook handling
{code_excerpt}
Code excerpt or sanitized diff
paste only the relevant function, test, or diff; remove secrets and customer data
{risk_focus}
Risk focus
security, data loss, race conditions, performance, accessibility, maintainability
{constraints}
Constraints
must keep public API stable, no new dependency, patch should stay under 30 lines
{output_format}
Output format
severity table, annotated findings, minimal patch, and tests to add
Engineering use cases
Need
How to tune the prompt
Pull request triage
Ask for severity, merge-blockers, and tests that must pass before approval.
Security-sensitive change
Prioritize input validation, authorization boundaries, data exposure, logs, secrets, and dependency risk.
Performance review
Request complexity analysis, hot-path concerns, caching tradeoffs, and benchmark ideas.
Refactor review
Ask whether behavior is preserved, which tests prove it, and where readability improved or regressed.
Review rubric
Use this rubric before copying the generated prompt into any AI tool. It keeps the output practical instead of vague.
Dimension
What good output should cover
Correctness
Does the code satisfy the stated behavior, handle edge cases, and avoid regressions?
Security
Are auth, validation, secret handling, dependencies, and data exposure reviewed?
Maintainability
Is the fix understandable, small enough, and consistent with project style?
Tests
Are unit, integration, regression, and negative tests clearly named?
Privacy and safety checklist
Remove passwords, API keys, private certificates, customer records, and unreleased business-sensitive details.
Prefer small sanitized excerpts over whole repositories or production dumps.
Ask the model to label assumptions, confidence, and human-review requirements.
Run tests, type checks, security checks, or staging validation before shipping suggested changes.
Safety note: Do not paste secrets, private keys, proprietary source that your policy forbids, confidential customer data, regulated personal data, or production credentials into public AI tools.
Paste the smallest sanitized function, diff, test, or stack trace that explains the change. Remove credentials, tokens, customer data, internal URLs, and unreleased business logic if your policy forbids sharing it.
Can this replace a human code review?
No. Use it as a second reviewer that produces a checklist and questions. A qualified human still needs to verify context, architecture, security, and production impact.
How do I make the review less generic?
Add runtime, user impact, recent incidents, known risky areas, test expectations, and the exact output table you want. Generic code produces generic feedback.
Should I ask for a patch?
Yes, but ask for the smallest safe patch and require the model to explain assumptions. Treat the patch as a suggestion that must compile and pass tests.
Source snapshot
This page is an Omellody original utility page refreshed during Red Mode quality recovery on 2026-05-23. It uses first-party prompt structures, local browser generation, developer review checklists, and internal peer links. It does not copy external repositories; public demand signals are used only to understand search intent.
Snapshot fields: title, canonical, direct answer, local builder, variable table, use-case table, review rubric, FAQ, related links, JSON-LD, robots index,follow.