API Review Checklist Prompt
Architecture review for the public surface: abstractions that earn their place, dependency direction, seams, and the patterns the codebase already has.
Coding Workflows
"Review this code" gets you shallow comments. Pick the review focus — security, performance, correctness, production readiness — and get a review contract: real criteria, a dynamic checklist, a severity standard, and verdict rules.
What is being reviewed, and what is at stake? E.g. "Review the authentication middleware before the release."
Paste the snippet, file, or diff here and the prompt carries it; leave empty and the prompt ends with a paste-here placeholder.
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.
"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.
Review JWT usage for the known traps — alg confusion, missing signature/expiry checks, secrets in the token, and the revocation problem stateless tokens create.
Mentoring-style maintainability review: what makes the next change expensive, explained with corrected examples — teach, don't just judge.
Allocations in hot loops, N+1 queries, complexity against real input sizes — the performance review that thinks about production load.
Find the path from user to admin — audit for vertical and horizontal escalation: mass-assignment of roles, unchecked elevation, and operations that trust client-supplied privilege.
SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.
Review the change as it will land: cross-file impact, deployment risk, migration safety — plus whether the PR does what its description says.
AI wrote it; review it with extra suspicion: strict correctness review of the diff, because generated code fails confidently.
Correctness review with C#'s own traps: async deadlocks, undisposed IDisposables, double-enumerated LINQ, silenced nullability.
Best-practices review with JavaScript's own traps added: equality coercion, floating promises, this-binding, shared-object mutation.
Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.
Review the session lifecycle for the classic holes — fixation, weak expiry, missing rotation, insecure cookies, and sessions that outlive a logout or password change.
Design an API on its contract instead of discovering it endpoint by endpoint — model the resources, design the endpoints and payloads, pin the contract, then review it before code locks it in.
Design access control before you build it, not after a breach — choose the authentication approach, model the roles and permissions, review the design for gaps, then document the identity model.
A complete AI-assisted review pass — not one prompt — that ends with ranked findings, tests guarding behavior, and a refactor plan when one is warranted.
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.
Update old, risky code you didn't write — safely — by understanding and pinning its behavior in tests before you change a single line.
Restructure code you own without breaking it — change only what's worth changing, and prove with tests and a diff that behavior held.
Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.
Cross the gap between 'tests pass' and 'safe in production' — assess release readiness, plan the deploy and its rollback, and set up the monitoring and launch checks before you ship, not after.
Structure a UI so it stays consistent as it grows — inventory the screens, break them into reusable components, specify the component system and its rules, then review the structure for drift.
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 taming an inherited codebase — understand it, document its architecture, pin its behavior with tests, then refactor, modernize, review, speed up, and ship it without breaking what works.
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.
State the review objective — what is being reviewed and what's at stake — then pick the review focus: Correctness, Security, Performance, Maintainability, Readability, Architecture, Best Practices, or Production Readiness. Each focus swaps in its own real criteria set and a 10–12 item checklist (Security checks injection vectors and privilege paths; Performance checks allocations and N+1 queries) — the live preview shows exactly which checks your prompt will enforce. Set the review scope (Diff adds breaking-change and regression criteria; Pull Request adds cross-file, deployment, and migration risk), the language (each adds its own traps — async deadlocks for C#, mutable defaults for Python), and the review style — Production Gate asks one question of every finding: would you approve this for production? Optionally paste the code so the prompt carries it. Click Generate Review Prompt for the full contract: objective, scope, criteria, severity rules, checklist, output format, and verdict rules. Nothing leaves your browser.
Direction. Review JUDGES the code: it reports findings with severities and a verdict, and the generated prompt explicitly says "report findings; do not rewrite the code". Refactoring CHANGES the code — that's the Refactor Prompt Builder in this category. Review first, refactor second: you want to agree on what's wrong before anything gets rewritten.
It swaps the entire criteria set and checklist. Security reviews check authentication on every entry point, injection vectors, secrets in code, privilege escalation, SSRF — twelve checks. Performance reviews check hot-loop allocations, N+1 queries, algorithmic complexity, resource leaks — ten different checks. The live preview shows the exact list before you generate.
It forces every finding to carry exactly one tag — [CRITICAL], [MAJOR], [MINOR], or [NIT] — with defined meanings (CRITICAL = must fix before merge; NIT = optional style preference) and one calibration rule: severity reflects impact, not effort to fix. Tagged findings are triageable; without tags, a review is just opinions in a row.
The criteria. A snippet is judged on its own terms; a file adds structure and ownership; a Diff adds breaking changes, backward compatibility, regression risk, and whether the diff does one thing; a Pull Request adds cross-file impact, deployment risk, and migration risk. Reviewing a diff with snippet criteria misses exactly the things diffs break.
Optional. Paste it and the prompt carries it in a fenced block — one artifact to copy into the AI. Leave it empty and the prompt ends with a paste-here placeholder. Either way the code is never executed or rendered — it travels as plain text.
For review, yes — the SQL language mode adds review-perspective checks: SELECT * in production paths, indexes implied by WHERE clauses, scan-forcing predicates. Deep query optimization — execution plans, schema context, rewrites — is a different job with different inputs: that's the SQL Optimization Prompt in this category.