Read this code and explain what it does in plain English. 
Assume I understand the product context but not the implementation details. 
Tell me: what problem is this code solving, what are its inputs and outputs, 
and what would break in the product if this file disappeared?

[paste code]

When to use it: Before any review. You need a baseline understanding before you can judge quality.

What to look for in the response: If the explanation is vague or circular ("it handles data processing"), the code probably has a naming or structure problem. Good code explains itself when described honestly.

Look at this code and list every external dependency it relies on: 
libraries, environment variables, database tables, API endpoints, other files or functions. 
For each one, tell me whether this code would fail silently or loudly if that dependency 
were unavailable or changed.

[paste code]

When to use it: After shipping a contractor's work or after an AI tool generated a full module.

What to look for in the response: Silent failures are the dangerous ones. If a dependency goes missing and your code returns an empty array instead of throwing an error, you won't know until a user notices something missing.

Identify every entry point into this code (where it gets called) 
and every exit point (what it returns or mutates). 
For each exit point, describe the exact shape of the output and any conditions 
that would change that shape. Flag any exit point that returns different types 
depending on conditions.

[paste code]

When to use it: Functions that get called from many places, or any code that feeds data into your UI.

What to look for in the response: Functions that return null in some conditions and an object in others are a common source of frontend bugs. This prompt surfaces that before it surfaces in production.

Read this code and list every assumption the author made about the environment, 
the data, or the caller. For each assumption, tell me what would happen 
if that assumption were wrong.

[paste code]

When to use it: Reviewing code written by someone else, or code you wrote more than two weeks ago.

What to look for in the response: Assumptions aren't bugs by default. Undocumented assumptions are. If the model finds five assumptions and none of them are in a comment or a test, that's a problem.

Does this code do more than one thing? List every distinct responsibility 
this file or function has. Then tell me which responsibilities belong together 
and which should be separated. Be specific about what you would split out and why.

[paste code]

When to use it: Any file over 200 lines. Any function that takes more than four parameters. Any function with the word "and" in its name.

What to look for in the response: If the model lists four or more distinct responsibilities, that file will be painful to modify without breaking something. That's not a style preference. That's a maintenance cost you'll pay repeatedly.

Review the variable names, function names, and file names in this code. 
For each one that is ambiguous, generic, or misleading, tell me: 
what does the name suggest, what does it actually do, 
and what would be a more honest name?

[paste code]

When to use it: Whenever you find yourself needing to trace through logic to understand what a variable holds. Good names make that tracing unnecessary.

What to look for in the response: Pay particular attention to boolean names. isValid, flag, temp, data are almost always signs of rushed code. This matters more in a small codebase where there's no institutional knowledge to fill the gaps.

Identify every place in this code where something could go wrong: 
network calls, parsing, database queries, external API calls, user input. 
For each one, describe how the error is currently handled. 
Flag any that swallow errors silently, return undefined, or fail without logging.

[paste code]

When to use it: Before releasing any feature that touches external data or user input.

What to look for in the response: Empty catch blocks and bare try/catch without logging are the most common issues. If your error handling doesn't tell you what broke and where, you'll be debugging blind when something goes wrong in production.

Find every hardcoded value in this code: strings, numbers, URLs, credentials, 
configuration values, timeouts, limits. For each one, tell me whether it should 
be an environment variable, a constant, a config value, or a database-driven value. 
Explain why.

[paste code]

When to use it: Before your first production deployment. Again before any contractor submits a PR.

What to look for in the response: Hardcoded API keys are the obvious red flag, but hardcoded business logic values are the sneaky ones. A timeout of 30 seconds hardcoded in three places means changing it requires finding all three places. You won't find all three.

Look at this code and identify any logic that appears more than once, 
either within this file or that seems like it might exist elsewhere in a typical codebase. 
For each duplicated pattern, describe what it's doing and suggest a single place 
it could live instead.

[paste code]

When to use it: When reviewing code that was written quickly or by multiple people over time.

What to look for in the response: Duplication is a debt multiplier. Every bug you fix in one copy, you'll forget to fix in the other. The model won't catch duplication across files it can't see, but it will catch it within what you paste.

In this code, identify every place where data crosses a trust boundary: 
user input entering the system, data coming from an external API, 
values read from a database, or parameters passed from a client. 
For each one, tell me whether the data is validated before use 
and what an attacker could do if it's not.

[paste code]

When to use it: Any code that handles forms, API routes, or data fetching.

What to look for in the response: The model will often surface SQL injection risks, unvalidated query params, and missing auth checks. These aren't exotic attack vectors. They're the most common ones for early-stage products.

Scan this code for any place where sensitive data might be exposed: 
logged to the console or a logging service, returned in an API response, 
stored in a client-accessible location, or included in an error message. 
List each instance and rate the severity.

[paste code]

When to use it: Before shipping any auth-related code, payment flows, or user data APIs.

What to look for in the response: Console.log statements with user objects are extremely common in fast-shipped code. They don't feel dangerous in development. They feel dangerous when your logs are forwarded to a third-party service and someone queries them.

Does this code involve any async operations, shared state, or sequential steps 
that depend on each other completing in order? If so, identify every scenario 
where those operations could complete out of order or fail partway through. 
Describe the user-visible consequence of each scenario.

[paste code]

When to use it: Any code with async/await, concurrent operations, or multi-step writes.

What to look for in the response: The most dangerous class here is partial writes: step one succeeds, step two fails, and your data is now in a half-updated state with no cleanup logic. That scenario is almost never covered in happy-path testing.

Imagine you are a new engineer joining a team and this is the first time 
you are seeing this code. What would you need to know before you could 
safely make a change to it without breaking something? 
List every implicit contract, every undocumented constraint, 
and every hidden side effect you found.

[paste code]

When to use it: Before handing any module to a new developer, a contractor, or an AI coding tool.

What to look for in the response: If the list is long, the code is fragile. Not necessarily buggy today, but one confident change away from breaking. This prompt makes the hidden fragility visible.

Review this code and identify technical debt: shortcuts taken, 
patterns that won't scale, missing abstractions, workarounds, 
or things that work now but will cause pain when the system grows. 
For each item, categorize it as: fix now, fix before scaling, or acceptable trade-off. 
Explain each categorization.

[paste code]

When to use it: End-of-sprint reviews, before major feature additions, or any time the code "works but feels wrong."

What to look for in the response: The distinction between "fix before scaling" and "acceptable trade-off" is where judgment lives. A shortcut in a feature nobody uses is different from a shortcut in your auth flow. Use the model's output as a starting point, then apply your own product context.

Assume this codebase is 10x larger in six months. 
What breaks first? What becomes the hardest to change? 
What decisions made in this code will constrain future decisions the most? 
Be specific about which lines or patterns create those constraints.

[paste code]

When to use it: Quarterly architecture reviews, or any time you're about to make a pattern choice that will be copied across the codebase.

What to look for in the response: The patterns that get copied are the dangerous ones. A singleton pattern, a direct database call inside a component, or an auth check copy-pasted into twelve routes: these start as one-off decisions and end up as architectural constraints. This prompt surfaces those before they replicate.