Give Cursor the Error and the Reproduction
What it is
Why it works
Cursor can read your whole codebase, but it can't see your terminal or reproduce your run. The stack trace tells it where; the reproduction tells it when; the @-mentioned files let it read the actual code. With all three it fixes the cause; with a vague 'it's broken' it guesses.
When to use it
Runtime errors, failing tests, and wrong-output bugs where you have — or can get — a concrete trigger. Especially in a large repo where the model needs pointers.
When not to use it
Bugs you can't yet reproduce. If you can't trigger it reliably, spend the first step making it reproducible; a fix without a repro is unverifiable.
Prompt
"Bug: <what's wrong>.
Repro: <exact steps or input>.
Expected: <what should happen>.
Stack trace:
<paste the full trace>
Relevant code: @path/to/file.ts @path/to/its.test.ts
Find the root cause, explain it in one line, then make the smallest fix and update the test."Example
For a 500 on checkout, pasting the full trace plus '@checkout.ts, happens when the cart is empty' lets Cursor jump straight to the unchecked array access, fix it, and add the empty-cart test — no back-and-forth.
Advanced version
Ask Cursor to reproduce the bug as a failing test first, then fix until it passes. In agent mode it can run the test itself, so you get a fix that's verified rather than asserted — and a regression test for free.
Common mistakes
- Pasting a one-line summary instead of the full stack trace, hiding the actual location.
- Not mentioning the relevant files, forcing the model to search and guess in a big repo.
- Accepting a fix with no reproduction, so you can't tell whether it actually worked.