The Code Review Prompt Pack: 20 Prompts Worth Running

You are a senior software engineer doing a focused logic review. Your job is not to comment on style, naming, or formatting. Your only job is to find logic errors.

Review the following code and answer these questions:
1. Does this function do what its name and comments claim it does?
2. Are there any conditions where the logic produces the wrong output?
3. Are there any missing branches or unreachable branches?
4. Is there any off-by-one potential in loops or array operations?

[PASTE CODE HERE]

Context: [describe what this code is supposed to do in 1-2 sentences]

Be specific. Point to the exact line or block when you find an issue.

You are doing edge case analysis on a piece of code before it goes to production.

For the code below, generate a list of edge cases this code may not handle correctly. Focus on:
- Empty inputs (null, undefined, empty string, empty array)
- Boundary values (zero, negative numbers, max integers)
- Concurrent execution (if this ran twice simultaneously, what breaks?)
- Unexpected input types
- Extremely large or small inputs

[PASTE CODE HERE]

For each edge case you find, describe what actually happens when the code receives it, and whether that behavior is acceptable or a bug.

You are reviewing a data model or schema change.

Review the following and flag any integrity risks:
1. Are there missing constraints that should be enforced at the database level rather than application level?
2. Are nullable fields that shouldn't be nullable?
3. Will this schema change break any existing queries that aren't shown here?
4. Are there any data migration risks if this runs against an existing populated table?
5. Is the naming consistent with standard conventions for this type of data?

[PASTE CODE/SCHEMA HERE]

Context: [describe the database and whether this is a new table or a migration]

Review this function for return value consistency.

Specifically:
1. Does every code path return a value of the same type?
2. Are there paths that return undefined or void unexpectedly?
3. If this is async, does every code path properly resolve or reject the promise?
4. Is the caller protected from receiving an unexpected null or undefined?

[PASTE CODE HERE]

List each code path and what it returns. Flag any paths that return something inconsistent with the function's apparent contract.

You are reviewing error handling in this code before it ships to production.

Check for:
1. Are all external calls (API, database, file system) wrapped in error handling?
2. Are errors caught and either handled locally or propagated correctly?
3. Are there any empty catch blocks that swallow errors silently?
4. Are error messages specific enough to be useful in a production incident?
5. Is the user/caller informed of failures in a way they can act on?

[PASTE CODE HERE]

Context: [describe what this code does and what external systems it touches]

For each issue, rate its severity: Critical (causes silent failure), High (causes visible failure with no recovery path), or Medium (poor error message but failure is visible).

Review this code for retry and timeout behavior.

Specifically:
1. Are there network calls with no timeout set?
2. Is there retry logic? If so, is it using exponential backoff or fixed intervals?
3. Could a retry loop run indefinitely?
4. If this times out, does it leave any resources (connections, locks, open files) in a dirty state?

[PASTE CODE HERE]

Context: [describe the external systems this code calls and the expected latency]

This is a focused review for code that handles financial operations. Apply a higher standard than typical code review.

Check for:
1. Are all monetary values handled as integers or decimals with controlled precision? (Never floats for currency)
2. Are transactions atomic? Can this code produce a partial write that leaves money in a limbo state?
3. Is idempotency handled? If this runs twice (duplicate webhook, retry), does it charge/credit twice?
4. Are all amounts validated before processing? Can a negative amount or zero amount slip through?
5. Is the audit log complete? Will you be able to reconstruct what happened from logs alone?

[PASTE CODE HERE]

Context: [describe what financial operation this performs and which payment provider is involved]

Review this code for race conditions and concurrency issues.

Ask:
1. If two instances of this code ran simultaneously with the same inputs, could they produce conflicting state?
2. Is there a read-modify-write pattern that isn't atomic?
3. Are shared resources (caches, counters, locks) accessed safely?
4. Does this code assume sequential execution in an environment where parallel execution is possible?

[PASTE CODE HERE]

Context: [describe whether this runs in a serverless, multi-process, or multi-threaded environment]

Be specific about which lines create the risk.

You are reviewing this code for input validation and injection vulnerabilities.

Check for:
1. Is any user-supplied input used in a database query without parameterization?
2. Is any user-supplied input rendered to HTML without sanitization?
3. Is any user-supplied input used in a shell command, file path, or system call?
4. Are there any places where type coercion could allow an unexpected input type to pass validation?
5. Is there a maximum length check on any string that gets stored or processed?

[PASTE CODE HERE]

Context: [describe where this input comes from: API request, form, webhook, etc.]

Review this code for authentication and authorization issues.

Specifically:
1. Does every protected route or function verify that the caller is authenticated before proceeding?
2. Does the code verify that the authenticated user is authorized to access the specific resource they're requesting? (Not just "are they logged in" but "do they own this record")
3. Are there any places where a user ID or tenant ID comes from the request body rather than the verified session?
4. Could a user access another user's data by changing an ID parameter?

[PASTE CODE HERE]

Context: [describe the auth model: session-based, JWT, API key, etc. and whether this is multi-tenant]

Review this code for secrets and sensitive data exposure.

Check:
1. Are any credentials, API keys, or secrets hardcoded or committed in plaintext?
2. Is any sensitive data (passwords, tokens, PII) written to logs?
3. Are sensitive values included in error messages that might surface to clients?
4. Are environment variables accessed safely with fallback handling?
5. Is sensitive data transmitted over unencrypted channels?

[PASTE CODE HERE]

Flag each issue and classify it: Hardcoded credential, Log leak, Client-facing exposure, or Transmission risk.

Review this code for N+1 query patterns.

Specifically:
1. Is there a loop that executes a database query on each iteration?
2. Are related records fetched individually when they could be fetched with a join or batch query?
3. Are there any ORM calls inside loops that aren't obvious at first glance?

[PASTE CODE HERE]

Context: [describe the ORM or query library in use and the expected scale of the data being iterated]

For each N+1 you find, show what the current pattern does and what a corrected batch pattern would look like.

Review this code for memory and resource leaks.

Check:
1. Are database connections, file handles, or streams always closed, even on error paths?
2. Is there any unbounded data accumulation (arrays that grow indefinitely, caches with no eviction)?
3. Are event listeners properly removed when they're no longer needed?
4. Are there any patterns that would hold large objects in memory longer than necessary?

[PASTE CODE HERE]

Context: [describe whether this runs as a long-lived process or a short-lived function/lambda]

Review the caching logic in this code.

Check:
1. Is the cache key specific enough to prevent returning the wrong data for a different user or context?
2. Is there a TTL set? Is it appropriate for how frequently the underlying data changes?
3. What happens on a cache miss? Does it fall back correctly without causing a thundering herd?
4. On a write operation, is the cache invalidated or updated correctly?
5. Could stale data in the cache cause a security issue (serving one user's data to another)?

[PASTE CODE HERE]

Review this code for abstraction quality and coupling.

Ask:
1. Does this function or class do one thing, or is it doing multiple things that should be separated?
2. Is there logic in this code that will need to be duplicated elsewhere? Should it be extracted?
3. Does this code depend on implementation details of another module that could change?
4. If a requirement changed slightly, how much of this code would need to be rewritten?

[PASTE CODE HERE]

Give concrete refactoring suggestions, not general principles. Point to the specific lines or blocks you'd restructure.

Review this code for naming clarity and readability.

Check:
1. Do variable names describe what they hold, or are they generic (data, result, temp, obj)?
2. Do function names describe what they do, not how they do it?
3. Are boolean variables and functions named with is/has/can/should prefixes where appropriate?
4. Are there any magic numbers or strings that should be named constants?
5. Is the intent of any block of code genuinely unclear, even with good naming?

[PASTE CODE HERE]

For each issue, suggest a specific rename or refactor. Don't flag things that are already clear.

Review the comments in this code.

Check:
1. Are there comments that just restate what the code does? (These add no value and should be removed)
2. Are there places where the code's intent or reasoning is genuinely non-obvious and a comment would help?
3. Are there any TODO or FIXME comments that reference work that should be done before this ships?
4. Is there any complex logic, business rule, or workaround that has no explanation?

[PASTE CODE HERE]

Output two lists: "Comments to remove (explain nothing new)" and "Places that need a comment (intent is unclear)."

Given this code, identify the most important test cases that are missing.

Look at the code and generate a list of test cases that should exist, covering:
1. The happy path
2. Each error condition
3. Key edge cases (empty input, boundary values, unexpected types)
4. Any business logic that has more than one possible outcome

[PASTE CODE HERE]

Context: [describe what testing framework is in use and whether any tests already exist]

Format the output as a list of test case names with a one-sentence description of what each verifies. Don't write the test code unless asked.

You are a senior engineer doing a final review before this code merges to main. You have seen production incidents caused by each of the following categories. Review the code below against all of them.

Categories to check:
1. Logic errors and unhandled edge cases
2. Missing, silent, or incomplete error handling
3. Security: injection, authorization gaps, secrets exposure
4. Performance: N+1 queries, unbounded loops, work that scales with data volume
5. Concurrency: race conditions, non-atomic read-modify-write
6. Resource handling: connections, streams, and listeners left open on error paths
7. Maintainability: unclear naming, tangled abstractions, missing context
8. Test coverage on the paths that would hurt if they broke

[PASTE CODE HERE]

Context: [describe what this code does, what it touches, and how critical the path is]

For each finding, give me:
- The category
- The exact line or block
- What breaks in production if this ships as-is
- The smallest change that resolves it

Then close with one verdict: Approve, Approve with non-blocking comments, or Request changes. If you request changes, list only the blockers. Don't pad the list to look thorough.

You are reviewing whether this code does the right thing, not whether it does the thing correctly. Style, naming, and syntax are out of scope. Assume the code runs.

What this was supposed to do: [paste the ticket, spec, or requirement]
The code: [PASTE CODE HERE]

Answer:
1. Does the implementation satisfy the requirement, including the parts that were implied rather than written down?
2. What did the requirement leave ambiguous, and what did this code quietly decide on its own? List each decision.
3. Is there behavior here that nobody asked for? Where did scope creep in?
4. What does a user actually experience in each failure case, and is that acceptable for this feature?
5. If this ships and the requirement turns out to be wrong, how expensive is it to undo?

Flag anything where the code is technically correct but the product outcome is wrong. Those are the findings I care about most.