PromptZone - Leading AI Community for Prompt Engineering and AI Enthusiasts

Code review and debugging

Most prompt libraries treat coding as code generation. That is the part you least need help with — you can already write the function. The expensive hours go somewhere else: reading an unfamiliar file well enough to change it safely, working out why a test only fails in CI, deciding whether a migration will lock a table in production, and reviewing a diff carefully enough that the bug does not reach main.

These prompts are for those moments. Every one takes real input — a diff, a stack trace, a query plan, a failing test — and asks the model to do something specific with it. They are written to make the model say "I cannot tell from this" rather than invent a plausible cause, because a confident wrong answer about why production broke costs more than no answer.

Curated

Assess the blast radius before deleting code

You are deciding whether this code is safe to delete. List everything that could still depend on it, including callers in the code given, dynamic dispatch by name, serialised references such as enqueued jobs or stored class names, database columns or migrations, public API surface, and anything reachable from configuration or templates. For each, say how you would verify it before deleting. End with a plain verdict: safe, unsafe, or cannot determine from what was provided. Code: {{code}}

Fill in: The code you want to remove, plus how it is referenced if you already know of any callers.

Known limits: Cannot grep your repository — dynamic references are the ones it will raise as questions rather than facts.

Curated

Check a PR description against its diff

Compare this pull request description against what the diff actually does. Report three things: changes present in the diff but not mentioned in the description, claims in the description not supported by the diff, and any change that is larger in blast radius than the description implies. Quote the specific lines for each. If the description accurately covers the diff, say so. PR: {{pr}}

Fill in: The description and the full diff.

Known limits: A description can be accurate and the change still wrong; this checks correspondence, not correctness.

Curated

Explain a file you did not write

You are explaining this file to an engineer who has to modify it today and has never seen it. In this order: one sentence on what it is responsible for; the public entry points and who calls them; the state it reads and the state it mutates; the non-obvious behaviour or assumption a newcomer would most likely break; and the one thing you would verify before changing it. Mark anything you are inferring from naming rather than reading as an inference. Code: {{code}}

Fill in: The file, ideally whole rather than excerpted.

Known limits: Infers caller behaviour it cannot see; treat the 'who calls this' section as a hypothesis to check, not a finding.

Curated

Explain what a regex actually matches

Explain this regular expression in plain language, then give a table of five inputs it matches and five near-miss inputs it does not, choosing the near-misses to expose its edge cases rather than obvious non-matches. Flag any catastrophic backtracking risk with the input shape that triggers it, and note anything that behaves differently across regex engines. Regex and its intended purpose: {{regex}}

Fill in: The expression and what it is meant to match — the gap between those two is usually the bug.

Known limits: Engine differences are real; verify anything version-specific against your actual runtime.

Curated

Explain why a test is flaky

Act as an engineer who has seen every common source of flakiness: shared mutable state between examples, real clock or timezone dependence, ordering assumptions on unordered results, unawaited async work, network or filesystem access, and random data. Given this test and what is known about when it fails, rank the likely causes and give, for each, the specific line that would produce it and a deterministic rewrite. If the failure pattern does not match any of these, say so. Test and failure pattern: {{test}}

Fill in: The test source plus when it fails — CI only, in parallel, after a particular other test, or at certain times of day.

Known limits: Without the failure pattern it lists generic causes; the 'when it fails' half of the input is what makes the answer specific.

Curated

Find the root cause from a stack trace

Act as an engineer on call. Given this stack trace, identify the most likely root cause and rank your top three candidates by probability. For each: name the specific frame that supports it, state what you would check to confirm or eliminate it, and say what evidence in the trace would have to be different for it to be wrong. Do not propose a fix until the cause is established. If the trace is insufficient, say what is missing. Trace: {{trace}}

Fill in: The full trace including the exception class and message, not just the top frames.

Known limits: Truncated traces produce confident guesses; paste the whole thing, including any 'caused by' chain.

Curated

Find why a query is slow

Given this query and its execution plan, explain where the time actually goes. Name the specific plan node responsible, say why the planner chose it, and state whether the problem is a missing index, a bad row estimate, an unnecessary sort, or the query shape itself. Propose one change and predict its effect on the plan. Do not suggest adding an index without saying which node it would eliminate. Query and plan: {{plan}}

Fill in: The query plus EXPLAIN ANALYZE output — the plan without actual timings is much weaker.

Known limits: Given EXPLAIN without ANALYZE it reasons from estimates, which is exactly what misleads when the estimates are the problem.

Curated

Refactor a long function without changing behaviour

Refactor this function for readability while preserving observable behaviour exactly, including its error cases and return types. Produce the rewritten code, then a list of every behavioural difference you could not avoid — if there are none, say so explicitly. Do not rename anything in the public interface, do not change the signature, and do not introduce a new dependency. Flag any branch whose current behaviour looks like a bug rather than silently correcting it. Function: {{function}}

Fill in: The function, plus its tests if you have them.

Known limits: It will preserve existing bugs by design — that is the point, but it means the output is not automatically an improvement in correctness.

Curated

Review a change for security issues

Review this change for security defects only. Check specifically: injection through unsanitised input, authorisation checks that are missing or applied after the effect, secrets or tokens reaching logs or responses, unsafe deserialisation, and user-controlled values reaching a filesystem path, shell, or URL. For each finding give the line, the attacker-controlled input, and the concrete consequence. Do not list theoretical risks with no path from input to impact in this code. Change: {{change}}

Fill in: The change, plus any route or permission code that governs who can reach it.

Known limits: Judges only what you paste — a missing authorisation check in a parent controller is invisible to it.

Curated

Review a diff for correctness bugs

Act as a reviewer whose only job is finding bugs that would reach production. Review this diff for correctness only — not style, naming, or preferences. For each issue: quote the exact line, state the concrete input or state that triggers it, and state the wrong behaviour that results. If you cannot construct a failing case for an issue, do not report it. If you find no correctness bugs, say so plainly instead of inventing minor observations. Diff: {{diff}}

Fill in: The diff you want reviewed, with enough surrounding context to show how the changed code is called.

Known limits: Cannot see code outside the diff, so it misses bugs whose cause lives in a caller you did not paste.

Curated

Review a migration for production safety

Act as a DBA reviewing a migration that will run against a live table. Identify anything that takes a blocking lock, rewrites the table, or runs unbounded: adding a non-null column with a default on an old database version, adding an index without a concurrent build, changing a column type, adding a foreign key without validation deferred, and backfills without batching. For each, state the lock taken and what queries it blocks, then give the safe rewrite. Note the table size at which each stops being safe. Migration: {{migration}}

Fill in: The migration, the database engine and version, and roughly how many rows the table holds.

Known limits: Safety depends on engine version and row count — without both it answers for a generic large Postgres table.

Curated

Review error handling

Review the error handling in this code. Identify: exceptions caught too broadly, errors swallowed without logging or re-raising, retries around non-idempotent operations, cleanup that will not run on the failure path, and error messages that leak internal detail to a caller who should not see it. For each, name the failure that would go unnoticed in production as a result. Do not comment on anything other than error handling. Code: {{code}}

Fill in: The code, including whatever wraps it — a swallowed error is only a problem relative to who needed to hear about it.

Known limits: Cannot know your alerting setup; 'goes unnoticed' assumes an unlogged error is invisible, which may not hold.

Curated

Trace where an unexpected nil comes from

A value is unexpectedly nil or undefined at a known point. Working backwards from that point through the code given, enumerate every path that could produce it, ordered by likelihood. For each path, name the line where the value becomes nil and the condition required. Then state the single cheapest check that would distinguish between your top two candidates. Do not suggest adding a nil guard at the symptom — the point is to find the origin. Context: {{context}}

Fill in: Where you observed the nil, and the code between its origin and that point.

Known limits: Only reasons over the code you paste; if the value crosses a serialisation or job boundary, include both sides.

Curated

Turn a vague bug report into a reproduction

Act as an engineer triaging a report too vague to act on. Produce: the minimal sequence of steps that would reproduce it if your leading hypothesis is right, the specific environment details that matter and why, the three questions to ask the reporter ranked by how much each narrows the search, and what you would check in logs or telemetry before asking a human anything. Do not guess at a fix. Report: {{report}}

Fill in: The report exactly as the user wrote it, without your own interpretation layered on.

Known limits: Its hypothesis is only as good as the surrounding context you give it; with no system detail it asks broader questions.

Curated

Write a failing test that reproduces a bug

Given this bug report and the relevant code, write the smallest test that pins the CORRECT behaviour — so that it fails against the code as it stands today and passes once the bug is fixed. Use the test framework already present in the code. State in one line what the test asserts, and state explicitly which line of the current code makes it fail today. If the report lacks the detail needed to reproduce it, list what you would need to ask instead of writing a test. Report and code: {{report}}

Fill in: The bug report as written, plus the code path you believe is involved.

Known limits: A vague report yields a test for the wrong thing — the prompt asks it to demand detail instead, so expect questions back sometimes.