Verified against Cursor · 2026-08-03
Force Cursor's Agent mode to reproduce a bug before it proposes a fix
A debugging brief that requires the agent to first write a failing reproduction of the reported bug and confirm it fails for the stated reason, before proposing any change, so a plausible-sounding fix can't ship for a cause that was never actually confirmed to be the real one.
The prompt
Ready to copy — highlighted parts are example details you can swap.
BUG REPORT Users report that clicking "Save" twice quickly sometimes creates two duplicate records instead of one. Happens intermittently, not on every double-click. STEPS TO REPRODUCE, AS REPORTED Open the edit form, make a change, click Save twice within about a second, check the records table for duplicates. Do not propose a fix yet. Your first job is to reproduce this bug and confirm it fails for the reason it appears to fail for — not to explain what's probably wrong from reading the code. ENVIRONMENT / DATA NEEDED TO REPRODUCE Needs a test account with an existing record to edit; the duplicate only seems to happen on records with at least one existing related child record. STAGE 1 — REPRODUCE Write the smallest test or script that reproduces the reported behavior. Run it and show the actual failure output. If you cannot reproduce it with the information given, say exactly what's missing — a specific input, a state, a timing condition — rather than guessing at a plausible cause without ever having seen it actually fail. STAGE 2 — ISOLATE Once reproduced, narrow it down: change one variable at a time to find the smallest set of conditions that still triggers it, and the smallest change that makes it stop. Report both explicitly — the presence of the bug and the boundary where it disappears are both diagnostic information. STAGE 3 — FIX Only now propose the fix, tied directly to what Stage 2 isolated. State exactly why this fix addresses the isolated cause, not just why it's a generally reasonable-looking change to make in this area of the code. STAGE 4 — CONFIRM Run the Stage 1 reproduction again against the fix and show that it now passes. Then check for regressions: does the fix change behavior for any case that was working before? Name specifically what you checked, not just that you checked "the usual suspects."
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A model asked to fix a bug directly from a description will very often produce a plausible-sounding explanation and a plausible-sounding fix without ever confirming either one against an actual failure, because pattern-matching a bug report to a familiar category of cause — a race condition, a missing debounce, a stale closure — is something a language model can do fluently from the report's prose alone, and that fluency is exactly what makes it easy to skip the step of checking whether this specific instance of the pattern is actually what's happening here. Requiring Stage 1 to produce an actual failing reproduction before any diagnosis is proposed closes that gap directly: a fix can only be evaluated against a cause that's been confirmed to exist, and "I couldn't reproduce it, here's what's missing" is a legitimate and useful Stage 1 outcome that a fix-first approach never produces, because a model that skips straight to proposing a fix has no occasion to discover the repro steps were incomplete in the first place. Stage 2's isolation step matters because "reproduced" and "understood" are different claims — a bug that reproduces under the reported steps might actually be triggered by something narrower or broader than what was reported, and changing one variable at a time to find the actual boundary is what turns "it happens sometimes" into a specific, checkable condition a fix can be judged against. Requiring Stage 4's regression check to name specifically what was verified, rather than accept a vague "checked the usual suspects," targets a documented pattern where a race-condition fix — adding a lock, a debounce, an idempotency check — silently changes legitimate concurrent-use behavior that was never part of the bug report, and a fix that suppresses double-clicks correctly but also breaks a legitimate rapid-edit-then-save workflow has just traded one bug for a different one that won't surface until a different user reports it weeks later.
What you get back
STAGE 1 — REPRODUCE Wrote a script simulating two rapid POST /api/records calls 400ms apart with identical payloads. Confirmed: both requests create a record; no duplicate-prevention check exists on the create path. Reproduced.
STAGE 2 — ISOLATE Duplicate occurs any time the second request starts before the first one's DB write completes, regardless of payload — not specific to records with child relations as suspected. Disappears entirely if the second request is delayed until after the first completes (confirmed by adding an artificial 200ms delay between the two test calls).
STAGE 3 — FIX Adding an idempotency key check keyed on (userId, formSessionId) with a short TTL addresses the isolated race directly — it doesn't depend on request timing, it makes the second identical request within the window a no-op instead of a second insert.
STAGE 4 — CONFIRM Re-ran the Stage 1 script against the fix: second request now returns the first request's record instead of creating a new one. Checked: a legitimate edit-save-then-edit-again-and-save sequence with a 5-second gap still creates/updates correctly, since it falls outside the idempotency TTL.
Verified against
Cursor 2.2 · 2026-08-03
Changelog
- 2026-08-03 — Initial publish, verified against Cursor 2.2 Agent mode on a race-condition duplicate-record bug.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
