Cursor prompts for reproducing, tracing and fixing bugs

I need to see why [FUNCTION NAME] returns [WRONG VALUE] in [FILE PATH]. Before you add any log line, state the hypothesis you are testing and the evidence for it. Then produce a logging plan as a table with columns Location, Variable, Why it matters and Limit. Each row is one log line: the exact spot in the file, the variables it prints, and the condition that keeps output to the failing case. Add no logging library or config file the project does not already use.

I have @-mentioned the files on that path. Trace one request from the route handler for [ROUTE NAME] down to the database call. Read each file before you name it. Write the path as a numbered list of function calls, with the file and line for each step. Mark the first step where [EXPECTED BEHAVIOUR] and [ACTUAL BEHAVIOUR] split. Give the hypothesis for that step and the evidence in the code, and describe only the functions you have opened.

Read the log excerpt below, taken from [TIME WINDOW] when [SYMPTOM] happened: [LOG EXCERPT]. Work only from the lines I pasted. Group the lines into up to five patterns, count each pattern, and give the timestamp of its first line. Then name the one check that would separate the two most likely patterns. If a field that check needs is missing, write MISSING FIELD instead of guessing its value. Output a table of up to five rows with columns Pattern, Count, First seen and Linked to symptom, then two lines: the check, and any MISSING FIELD note.

Compare a working run and a broken run of [FLOW NAME]. Working log: [WORKING LOG]. Broken log: [BROKEN LOG]. Line up the two logs step by step and mark every step that appears in one run and not the other. Give the earliest difference and a hypothesis for its cause, with the evidence from the two logs. Output a table with columns Step, Working, Broken and Difference, then one sentence naming the log line to add next.

Ask me exactly five questions about [BUG SUMMARY] before you read any code. Cover the input that triggers it, the environment, what changed last, what I already tried, and what I expected. Stop after the fifth question and wait for my answers. Then read [FILE PATH], state three hypotheses with the evidence each one needs, and name the single log line that would prove or rule out the top hypothesis. Do not invent a stack trace or a file name I have not given you.

The bug only shows up when [CONCURRENT ACTIONS] happen within [TIME WINDOW]. Read [FILE PATH] and the function [FUNCTION NAME] first. Output a table of up to five rows with columns Value, Access, Verdict and Reason, covering the most important shared values that two async paths can read or write. Then state your hypothesis for the race and the evidence from the code, and propose one timing test that forces the bad order, in under 200 words. Add no locks, queues or logs until I confirm the hypothesis. I will use Debug Mode for the reproduction after that.

Fill in this template using only the code in [FILE PATH] and the error [ERROR MESSAGE]. Symptom: one sentence on what the user sees. Unawaited or uncaught call: the function, the file and the line. Missing await or missing catch: the exact spot. Hypothesis and evidence: one sentence each. Smallest fix: under 10 lines of code. Test that fails before the fix: its name and one sentence. Add no library call you have not read, and write UNKNOWN in any field the code does not answer.

My [SERVICE NAME] process grows from [START MEMORY] to [END MEMORY] over [TIME WINDOW]. Build a checklist for [FILE PATH]. Each item is a listener, timer, cache or observer that is added without a matching removal, with its file and line. Mark each item as found in the code or not found, based only on what you read. Then state your hypothesis for the strongest candidate, with its evidence, and the one heap snapshot step that would confirm it. Name no profiler option the project does not show.

Here is the slow function from [FILE PATH]: [PASTED CODE]. Timing: [CURRENT TIMING] on [INPUT SIZE], target [TARGET TIMING]. Critique the code in a table with columns Line, Cost and Why. Then rewrite only the slowest block, in under 25 lines, and name the measurement that would show whether the rewrite reaches the target. Claim no speed-up until that measurement has been run, and keep the output the same as before.

After a timeout, [SERVICE NAME] clients seem to retry at once, and the logs show [RETRY PATTERN]. Read the retry code in [FILE PATH] and the timeout setting you find there. List every place a request is retried, with its file and line. For each retry, state whether it has a backoff, a jitter step and a retry cap, based only on the code you read. Name the path most likely to multiply the load, with the evidence, and the one change that would cut the retries. Output a table of up to five rows with columns Retry point, File and line, Backoff and Verdict.

Act as a careful reviewer of [FILE PATH]. The error is [ERROR MESSAGE] on line [LINE NUMBER]. Find every value on the path to that line that can be null or undefined, and give the condition under which each one is empty, based only on the code you read. Propose the smallest guard that stops the crash. Output a 4-row table with columns Value, Empty when, Guard and Hides a real bug?, under 200 words. Use no default value unless the code shows what it should be.

Read the type definition for [TYPE NAME] and the call that fails with [ERROR MESSAGE]. Give numbered steps to narrow the type at that call site, one check per step, and write the exact type guard you would use for each. Do not use a type assertion that hides a real mismatch without flagging it as a risk. Say which steps you can skip if the value comes from a typed source you have opened.

I am running this in Plan Mode. After upgrading [PACKAGE NAME] from [OLD VERSION] to [NEW VERSION], the build fails with [ERROR MESSAGE]. Read the lock file and the package manifest first. List the changes that could cause this, each with the evidence from those files. Write a plan with one step per check: roll back only that package, rerun the build, and record the result. Describe the package changelog only if you have opened it.

The error [ERROR MESSAGE] appeared after I moved [FILE PATH] into a new folder. I have @-mentioned the files that import it. State your hypothesis and the evidence for it before you edit anything. List every import that still points to the old path, and add the alias or path config you have read that resolves those imports. Output a checklist with one line per file: old import, new import, and a tick once it is fixed. Invent no config file that the project does not contain.

Rewrite the build failure [ERROR MESSAGE] for a product manager who does not read code. Keep the file name and the error code, remove the jargon, and write three sentences: what broke, what it blocks, and what the team needs to decide. Then give the engineer's version in 60 words for the pull request thread, with your hypothesis and the evidence from the log. Do not state a cause that the log does not confirm.

The test [TEST NAME] passes on my machine and fails in CI with [ERROR MESSAGE]. My local setup: [LOCAL SETUP NOTES]. The CI job: [CI JOB NOTES]. Read the CI workflow file at [FILE PATH] before you guess. Produce a table with columns Setting, Local, CI and Why it matters. Name the setting most likely to cause the failure and give the evidence from the workflow file. Name no CI variable or version that the workflow file does not show.

Check every environment variable the code reads in [FILE PATH] against the variables set in [CONFIG FILE]. Produce a checklist with one line per variable, marked Set in CI, Set locally, Missing in CI or Default in code, with its file and line. Then state your hypothesis for [ERROR MESSAGE] and the evidence in those lines. Check each variable's value, not only its name, and quote each variable name exactly.

A date shows [WRONG DATE] in [ENVIRONMENT] but [EXPECTED DATE] on my laptop. Using only the date code in [FILE PATH], give three possible causes: the server time zone, a date parsed without a zone, or a daylight saving boundary. Output a 3-row table with columns Cause, Fixed-clock test and Would show, under 200 words, then name the most likely cause and its evidence. Change nothing until I confirm the choice.

The service starts with [LOCAL COMMAND] on my laptop but fails in the container with [ERROR MESSAGE]. Read the Dockerfile at [FILE PATH] and any compose file in the repo. List the symptoms in the order they appear in the logs. Output a 4-row table with columns Symptom, Likely cause, File and Next check, under 200 words, then the next command to run and what each possible output would mean. Use no image tag, port or path that is missing from the files you read.

Here is my fix draft for [ENCODING ISSUE] in [FILE PATH]: [FIX DRAFT]. Score it from 1 to 5 on four points: fixes the reported case, keeps other inputs working, uses only functions that exist in the code I shared, and comes with a test. Give the scores in a table with columns Point, Score and Reason. Then rewrite only the points that scored below 4, and show the failing input you used. Change only the files I shared.

Explain why the test [TEST NAME] in [FILE PATH] fails with [ERROR MESSAGE]. Read the test and the code under test before you answer. Say whether the test or the code is wrong, with the evidence from both, in no more than 120 words. Then output a table with two rows: what the test expects and what the code returns. Change the test only after I confirm which side is wrong.

Before you write anything, state your hypothesis for [BUG SUMMARY] in [FILE PATH] and the evidence for it. Then write one regression test for that bug. The test must fail on the old code and pass on the fixed code. Read the existing test file next to it and match its framework and naming, and use no helper it does not already use. Give the test in one code block, then three numbered steps to confirm it fails before the fix.

Make the smallest change that fixes [BUG SUMMARY] in [FILE PATH], then add one test. I have attached @Commit (Diff of Working State), my uncommitted changes. First write your hypothesis and its evidence in two sentences, and list the files you read. Show the patch as a diff of at most 30 lines and the test as one code block. Change no other file, and use only utility functions the project already exports.

Write a post-mortem for [INCIDENT TITLE] in 150 words at most, under four labelled lines: What broke, Root cause, Fix and Follow-up. Take the root cause and the fix only from the diff summary I paste here: [DIFF SUMMARY]. Mark anything the evidence does not show as UNKNOWN. Keep names out of the note, and add no date, duration or user count that I have not given you.

Before I open a pull request for the fix to [BUG SUMMARY], give me a checklist of ten checks. Include reproducing the bug on the old commit, running the failing test, confirming the regression test fails before the fix, checking the logs for the old error, and running the /agent-review command on the local changes. Read the repo files first. Do not list a project command or CI job you did not find in the repo files. Output ten lines, each with the check, Needed or Not needed for this change, and a few words of reason.