Code Review Prompt — the Review Contract
"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.
Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.
Generic reviews miss security issues because security needs its own questions: not "is this clean?" but "is authorization checked per resource, not just per login? do any outbound requests use user-controlled URLs?". This setup runs the security focus — twelve attacker-minded checks covering injection vectors, XSS encoding, hardcoded secrets, logging leaks, weak crypto, insecure deserialization, path traversal, and SSRF — under Strict style: every finding flagged, no praise padding, APPROVED or CHANGES REQUIRED.
Run it on the scary paths first
Auth middleware, payment handlers, file uploads — the places where a missed finding costs the most.
Treat CRITICALs as merge blockers
The severity rules already say it: vulnerabilities are CRITICAL, and CRITICAL means fixed before merge.
Re-review after the fix
Same prompt, fixed code — security fixes have a habit of introducing their own findings.
It runs twelve attacker-minded checks: authentication on every entry point, per-resource authorization, injection (SQL, command, template, path), XSS output encoding, hardcoded secrets, log leaks, weak crypto, privilege escalation via user-controlled IDs, insecure deserialization, path traversal, and SSRF. Each failing item is one bullet tagged [CRITICAL], [MAJOR], [MINOR], or [NIT], grouped CRITICAL-first, ending in APPROVED or CHANGES REQUIRED.
Treat it as a floor, not a ceiling. It runs twelve static checks against pasted code wherever you run the prompt and ends in CHANGES REQUIRED or APPROVED, but a live pen test probes a running system, chained exploits, and network paths this file-level read never touches. Run both, and keep the ship decision yours.
No — an APPROVED verdict means nothing on the twelve checklist items failed for the file you pasted, not that the code is proven secure. The review reads the way an attacker would but still misses logic flaws, cross-file interactions, and runtime state a real attacker exploits. Its verdict is a structured signal for your own judgment; fixing findings stays a separate step you own.
"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.
Architecture review for the public surface: abstractions that earn their place, dependency direction, seams, and the patterns the codebase already has.
Hunt the broken-access-control bug — review code for missing per-resource checks, IDOR, and 'logged in' mistaken for 'allowed', the vulnerability class that tops the OWASP list.
"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.
getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.
A side-by-side way to decide between two ChatGPT prompt drafts — scored on clarity, specificity, output control, and risk instead of gut feeling.
Generate code review prompts for any scope — snippet, file, diff, or full pull request — with focused review rules.
The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.
The full path to a support agent you can put in front of customers — write its instructions, ground it in your docs, route and handle tickets, then evaluate and cost-control it before it goes live.
The full path to an AI content moderation system — define the policy and label taxonomy, extract signals from user content, classify it against policy, emit structured decisions, evaluate false positives and negatives, wire enforcement and review queues, review abuse risks, then ship.
The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.
The full path to a support operation, not just a bot — stand up the knowledge base, route the tickets, add the AI agent, integrate your stack, close the feedback loop, evaluate, and deploy.
The full path to an applicant tracking system — model jobs, candidates, and hiring stages, generate job descriptions and screening prompts, parse résumés into structured data, design the hiring API, set roles, review security, then ship.
The full path to a booking and reservation system — model resources, availability, and reservations, design the booking API, set customer accounts, wire calendar and notification integrations, design the UI, review security, then ship.
The full path to an inventory management system — model products, stock, locations, and movements, design the inventory API, set roles, plan supplier and POS integrations, design the UI, review data-integrity risks, then ship.
The full path to an internal admin panel — model the operational data it manages, design the management API, define RBAC and admin permissions, design the tables and forms, review risky admin actions, then ship to trusted internal users.
The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.
The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.
The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.
Review code for what an attacker would do, not just what tests catch — anchor the model as a security engineer, run a threat-focused review, then back the findings with auth and input tests.
AI-written code usually compiles and passes a quick test while hiding the real risks — a missing auth check, a destructive update, an untested edge case. Here's a review path that surfaces them before you merge.
Threat model a feature while it is still a design: name what it protects, follow the data until it crosses a trust boundary, and write abuse cases against the real flow rather than a list of security-sounding nouns.