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.
View Resource →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. Runs entirely in your browser.
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.
View Resource →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.
View Resource →"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.
View Resource →Review JWT usage for the known traps — alg confusion, missing signature/expiry checks, secrets in the token, and the revocation problem stateless tokens create.
View Resource →Mentoring-style maintainability review: what makes the next change expensive, explained with corrected examples — teach, don't just judge.
View Resource →Allocations in hot loops, N+1 queries, complexity against real input sizes — the performance review that thinks about production load.
View Resource →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.
View Resource →SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.
View Resource →Review the change as it will land: cross-file impact, deployment risk, migration safety — plus whether the PR does what its description says.
View Resource →AI wrote it; review it with extra suspicion: strict correctness review of the diff, because generated code fails confidently.
View Resource →Correctness review with C#'s own traps: async deadlocks, undisposed IDisposables, double-enumerated LINQ, silenced nullability.
View Resource →Best-practices review with JavaScript's own traps added: equality coercion, floating promises, this-binding, shared-object mutation.
View Resource →Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.
View Resource →Review the session lifecycle for the classic holes — fixation, weak expiry, missing rotation, insecure cookies, and sessions that outlive a logout or password change.
View Resource →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.
View Playbook →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.
View Playbook →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.
View Playbook →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.
View Playbook →Update old, risky code you didn't write — safely — by understanding and pinning its behavior in tests before you change a single line.
View Playbook →Restructure code you own without breaking it — change only what's worth changing, and prove with tests and a diff that behavior held.
View Playbook →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.
View Playbook →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.
View Playbook →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.
View Playbook →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.
View Blueprint →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.
View Blueprint →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.
View Blueprint →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.
View Blueprint →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.
View Blueprint →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, coming soon 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, and nothing leaves your browser.
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, coming soon in this category.