Verified against Cursor · 2026-08-09
Have Cursor's Agent mode rank competing causes before it touches a production bug it can't reproduce locally
A differential-diagnosis brief for incidents where local reproduction isn't available — it forces the agent to list multiple candidate causes, score each against the actual evidence in hand, and name the one piece of evidence that would distinguish the top two, instead of committing to the first plausible-sounding explanation.
The prompt
Ready to copy — highlighted parts are example details you can swap.
INCIDENT SYMPTOM Roughly 2% of checkout requests return a 500 starting at 14:10 UTC, concentrated on orders with more than one line item. EVIDENCE AVAILABLE Error logs show a null-pointer in calculateShippingTotal for the affected requests. Deploy log shows a shipping-rates service deploy at 14:05 UTC. No corresponding spike in the shipping-rates service's own error rate. RECENT CHANGES THAT COULD BE RELATED shipping-rates service deployed at 14:05 UTC (adds a new zone-based pricing tier). No other deploys in the last 24 hours. This cannot be reproduced locally right now — The affected shipping zones only exist in production data; staging has no multi-zone orders to trigger the path. — so you are diagnosing from evidence alone, not from a failing test you can iterate against. Do not present a single cause as confirmed unless the evidence actually rules out the alternatives; a story that fits the symptom is not the same as a story the evidence has confirmed over its rivals. STEP 1 — LIST CANDIDATE CAUSES Name at least 3 distinct, genuinely different candidate causes consistent with the symptom — not one cause phrased three ways. For each, state what you'd expect to see in the evidence if it were true. STEP 2 — SCORE AGAINST EVIDENCE Go through EVIDENCE AVAILABLE line by line and, for each candidate, state whether that evidence supports it, contradicts it, or is silent on it. A candidate contradicted by even one piece of hard evidence gets demoted, not kept in contention just because it's otherwise the most attractive explanation. STEP 3 — NAME THE DECIDING EVIDENCE For the top two candidates still standing, state the one specific additional piece of evidence — a log line, a metric, a specific field on a specific record — that would distinguish between them, and where you'd look for it if it isn't already in EVIDENCE AVAILABLE. STEP 4 — RECOMMEND, DON'T FIX YET Name the single most likely cause and the fix you'd propose for it, but do not write that fix until the Step 3 evidence is actually checked. If checking it isn't possible right now, say so plainly and mark the recommendation unconfirmed rather than presenting it with the same confidence as a checked conclusion.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A language model asked to diagnose a bug from a symptom description has a strong pull toward premature convergence on a single coherent, confident-sounding narrative, because that's the shape of answer its training rewards — and a story that merely fits the symptom's surface description is trivially easy to construct for almost any plausible cause, which is exactly why it isn't evidence of anything on its own. Requiring at least a stated minimum of genuinely distinct candidates before any scoring happens breaks that premature convergence by making the model commit to breadth before it's allowed to narrow, and the line-by-line evidence-scoring step in Stage 2 is what actually does the diagnostic work: it forces each candidate to be checked against specific facts rather than against the symptom's prose, which is where hypotheses that sound equally good on the surface start to separate, since real evidence supports some and contradicts others even when both stories are individually coherent. Naming the one piece of deciding evidence that would distinguish the top two remaining candidates matters because it converts "I believe it's X" into a falsifiable claim with a named test, which is the only thing that actually resolves a genuine tie between two evidence-consistent explanations — without it, the model defaults to picking whichever candidate it introduced first or described most fluently, which has no correlation with which one is actually correct. Marking an unconfirmed recommendation as unconfirmed, rather than presenting it with the same tone of certainty as a checked conclusion, matters specifically for incidents: a fix shipped against an unconfirmed cause can make the symptom subside for an unrelated reason — traffic dropping, a concurrent deploy, a cache expiring — and get credited as "fixed" while the actual cause ships unaddressed and recurs later under conditions nobody thought to re-check.
What you get back
Candidates: (1) new zone-pricing tier in shipping-rates returns a shape calculateShippingTotal doesn't expect for certain zones. (2) unrelated null-check regression already present before 14:05, coincidentally surfaced by unrelated traffic composition. (3) a race condition between cart total and shipping calc, unrelated to the deploy.
Scoring: no error-rate spike in shipping-rates itself contradicts candidate (1) being a shipping-rates bug directly, but supports a shape mismatch on the caller's side. Deploy timing lining up almost exactly with symptom onset contradicts (2) and (3) as coincidence explanations.
Deciding evidence: pull one affected request's raw shipping-rates response body from logging and check whether it includes the new zone-tier field that calculateShippingTotal's null-check doesn't handle.
Recommendation (unconfirmed pending that check): calculateShippingTotal doesn't handle the new zone-tier field shape introduced at 14:05.
Verified against
Cursor 2.2 · 2026-08-09
Changelog
- 2026-08-09 — Initial publish, verified against Cursor 2.2 Agent mode on a production incident with no local repro.
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
