What this prompt does
This prompt runs a disciplined debugging session in Cursor chat that chases the root cause instead of the symptom. You provide the [language]/[framework], the [error_message], and the [trigger_action], then the AI analyzes the stack trace from the file you @-mention, checks whether it is a [error_type] issue by walking the data flow from [entry_point] to the crash, inspects [related_files] for race conditions, stale state, or incorrect assumptions, proposes a minimal fix with reasoning, suggests a defensive change to prevent the whole bug class, writes a regression test, and checks whether the same pattern exists elsewhere.
The structure works because most bugs get fixed superficially — patched at the point they blow up rather than where they start. By forcing a data-flow walk from [entry_point] to the crash point, the prompt finds where bad or missing data actually originates, which is usually several steps upstream of the stack-trace line. The regression test step locks the fix in so the bug cannot silently return in a later change, and running that test before the fix confirms you actually reproduced the right bug. The final duplicate-pattern scan catches the sibling bugs hiding elsewhere in the codebase — the ones that share the same unchecked assumption and would otherwise resurface in production weeks later.
When to use it
- You have a concrete
[error_message]and a reliable[trigger_action]to reproduce it - A quick patch keeps masking the symptom and you want the actual root cause this time
- The bug smells like a null-reference or missing-data issue worth tracing through the data flow
- You suspect race conditions or stale state somewhere in
[related_files] - You want a regression test that fails before the fix and passes after it
- You think the same buggy pattern might be repeated in other parts of the codebase
Example output
You get a structured analysis: the root cause behind the [error_message] rather than just the symptom, the data-flow path from [entry_point] to the crash, any contributing issues found in [related_files], a minimal proposed fix with reasoning, a defensive change to prevent the bug class, a regression test that reproduces the bug and then passes, and a list of other spots in the codebase sharing the same risky pattern.
Pro tips
- Paste the full
[error_message]and complete stack trace; a truncated trace sends the analysis down the wrong path - Be precise about
[trigger_action]and[entry_point]so the data-flow walk starts from the right place @-mention the actual crash file and the[related_files]so Cursor reasons over real code, not assumptions- Insist on the minimal fix first, then ask separately for the defensive change so you can review each on its own
- Run the regression test before applying the fix to confirm it actually reproduces the bug you think it does
- Take the duplicate-pattern scan seriously; the sibling bugs it finds are the ones that resurface in production
