24 Cursor Prompts for Debugging & Fixing Errors (2026)

Ask mode. Diagnose the current error — don't edit anything yet.

Read @Terminal and @Lint Errors for the failing command and diagnostics.
Relevant code: @Files [path/to/file]

Do this:
- State the single most likely root cause first, then 2 alternates.
- Point to the exact file and line where it originates.
- Tell me the one-line fix and where it goes.
- Say what you'd still need to see to be sure.

Walk this stack trace to the root cause. Ask mode — explain, don't edit.

<trace>
[paste the full stack trace, or reference @Terminal]
</trace>

Do this:
- Read the trace bottom to top and identify the frame where MY code is at fault (not library internals).
- Explain what call path led there and why it threw.
- Name the underlying cause, not just the line that crashed.
- Give the fix and one nearby thing worth checking.

Explain this error message like I've never seen it before. Ask mode.

<error>
[paste the error, or reference @Terminal / @Lint Errors]
</error>
Code it points at: @Files [path/to/file]

Do this:
- Translate the error into plain language: what it literally means.
- Explain why it's happening in THIS code specifically.
- List the 2-3 usual causes of this error, ranked for my case.
- Tell me the standard fix for each.

Agent mode. Reproduce this bug before doing anything else.

Symptom: [what's wrong]. Steps: [how to trigger it].
Expected: [what should happen]. Actual: [what happens].
Reference @Terminal for the current output.

Do this:
- Write a small failing test (or run the repro steps) and confirm you actually see the bug.
- Stop and show me the reproduction. Don't attempt a fix yet.
- Tell me what the failing case proves about where the bug lives.

Agent mode. Help me narrow down where this goes wrong by adding logging.

The value is wrong by the time it reaches [point]. Code: @Files [path]

Do this:
- Add temporary log lines at the key steps so I can see where the data first becomes wrong.
- Label each log clearly and don't change any logic.
- Tell me exactly which command to run and what to look for in @Terminal.
- After I paste the output back, tell me the narrowed-down cause and remove the logs.

This runs without crashing but produces the wrong result. Find out why.

Code: @Files [path/to/file]
Input: [the input I gave it].
Expected: [what it should return / do].
Actual: [what it actually returns / does].

Do this (Ask mode first):
- Trace the input through the code and show me where the actual diverges from the expected.
- Name the root cause.
- Give the smallest safe fix.
- Suggest one assertion or test that would have caught this.

The output value is wrong and I can't see why.

Code: @Files [path]
For input [X], it returns [wrong value] but should return [right value].

Do this:
- Compute the expected value by hand, step by step, and compare against what the code does at each step.
- Point to the exact line where the calculation goes wrong.
- Explain the mistake (wrong operator, bad rounding, unit mismatch, etc.).
- Fix only that line and confirm the input above now yields the right value.

This works for normal input but fails on edges. Find the boundary bug.

Code: @Files [path]
It breaks when: [empty input / first or last element / single item / zero / max].

Do this:
- Check the loop bounds, index math, and range/slice logic for off-by-one errors.
- List every boundary the code should handle and whether it does.
- Give the fix.
- Add a quick test covering the edge above and re-run it to confirm it passes.

I think this is an async or race-condition bug — it works sometimes.

Code: @Files [path]
Symptom: [e.g. stale data, missing await, out-of-order updates, double fire].

Do this (Ask mode):
- Trace the async flow: what's awaited, what isn't, and what runs concurrently.
- Identify any missing await, unhandled promise, or shared state written from two paths.
- Explain the exact interleaving that produces the bug.
- Give the fix that makes ordering deterministic, and note any others I should check.

My UI isn't updating when the data changes. Find why.

Framework: [React / Vue / Svelte / etc.]. Component: @Files [path]
Expected: [what should re-render / show]. Actual: [what's stale or missing].

Do this:
- Check for state mutated in place instead of replaced, wrong or missing dependency arrays, stale closures, or keys that don't change.
- Point to the exact cause in this component.
- Give the idiomatic fix for this framework.
- Tell me how to verify the UI now updates.

A test is failing and I don't know if the test or the code is wrong. Ask mode.

Test: @Files [path/to/test]
Code under test: @Files [path/to/code]
Failure output: @Terminal

Do this:
- Tell me whether the bug is in the test or the code, and how you know.
- If the test is asserting the wrong thing, explain the correct expected behavior.
- If the code is wrong, name the root cause.
- Don't change anything yet — just give me the verdict and the reasoning.

Agent mode. This test is failing because the code is wrong. Fix the code.

Test: @Files [path/to/test]
Code: @Files [path/to/code]
Failure: @Terminal

Do this:
- Make the smallest change to the code that makes this test pass for the right reason.
- Do not weaken or delete the test to make it green.
- Don't touch unrelated files.
- Re-run the test and confirm it passes; show me the diff of what you changed.

This test passes sometimes and fails others. Make it deterministic.

Test: @Files [path/to/test]
Code it exercises: @Files [path]

Do this (Ask mode first):
- List the usual flakiness causes that could apply here: timing, test ordering, shared state, randomness, real clock/timezone, network.
- Rank which is most likely given this test.
- Then in Agent mode, apply the fix that removes the nondeterminism (fake timers, seed, isolate state, mock the network).
- Run the test several times to show it's now stable.

Agent mode. Get the whole test suite green.

Run the tests, read @Terminal, and use @Codebase to find causes across files.

Do this:
- Run the suite and list every failing test grouped by likely shared cause.
- Outline your plan before editing — which failures come from one root cause vs. many.
- Fix the code (not the tests) one group at a time, re-running after each.
- Ask before deleting or skipping any test.
- Finish only when the full suite passes; summarize what was broken and why.

Fix this TypeScript error properly — no "any", no @ts-ignore.

Error: @Lint Errors (or paste it below)
<error>
[paste the TS error if not using @Lint Errors]
</error>
Code: @Files [path]

Do this:
- Explain what the type error is actually telling me.
- Fix it by making the types correct, not by silencing the checker.
- If the type reveals a real bug (a value that can be undefined/null), fix that too.
- Keep runtime behavior identical and show the diff.

Agent mode. My build is failing. Diagnose and fix it.

Read @Terminal for the full build output.
Build command: [e.g. npm run build].

Do this:
- Identify the first real error in the output (ignore downstream noise it caused).
- Explain what's failing and why.
- Apply the fix — config, code, or dependency as appropriate.
- Re-run the build and confirm it completes clean. Don't touch unrelated config.

Ask mode. I have a dependency/version conflict. Help me resolve it safely.

Error: @Terminal
Package manager: [npm / pnpm / yarn / pip / etc.].
Relevant manifest: @Files [package.json / lockfile / requirements]

Do this:
- Explain which packages conflict and why (peer dep, incompatible ranges, transitive pin).
- Give me the safest resolution: which version to pin/upgrade and the exact command.
- Warn me about any breaking changes that upgrade introduces.
- List what I should test after applying it before I trust the fix.

Fix this "cannot find module" / import-resolution error.

Error: @Lint Errors / @Terminal
Failing import is in: @Files [path]

Do this:
- Tell me whether it's a wrong path, a missing package, a misconfigured alias/paths, or an ESM/CommonJS mismatch.
- Check the tsconfig/jsconfig paths and the build config for the alias if one is used.
- Give the exact fix (correct path, install command, or config change).
- Confirm the import resolves and nothing else broke.

Ask mode. Find why this is slow before I change anything.

Code: @Files [path]
Context: it handles [scale, e.g. 100k rows / N requests] and takes [current time].

Do this:
- Identify the likely bottleneck(s) with reasoning about time/space complexity.
- Rank the fixes by impact vs. effort.
- Give the single highest-impact change as concrete code.
- Warn me about any correctness or memory trade-off it introduces.

I think this has an N+1 query problem. Find and fix it.

ORM/DB layer: [Prisma / ActiveRecord / SQLAlchemy / raw SQL].
Code: @Files [path]

Do this:
- Show me where a query runs inside a loop, causing one query per row.
- Rewrite it to batch/eager-load/join so it's a fixed number of queries.
- Keep the returned data shape identical.
- Estimate the query-count reduction and note anything to verify (correct joins, no duplicates).

This is re-rendering too often / using too much memory. Fix it.

Framework/runtime: [React / etc.]. Code: @Files [path]
Symptom: [janky UI / growing memory / repeated expensive work].

Do this:
- Identify what's causing the extra renders or retained memory (new object/function identities each render, missing memoization, unbounded caches, leaked listeners/subscriptions).
- Apply the targeted fix without changing behavior.
- Make sure you're not over-memoizing things that don't need it.
- Tell me how to confirm the improvement.

Agent mode. We just fixed a bug — now lock it in with a regression test.

The bug was: [describe it]. The fix was: [describe it, or reference @Git for the diff].
Code: @Files [path]

Do this:
- Write a test that reproduces the ORIGINAL bug — it must fail on the old code and pass on the fixed code.
- Verify this by mentally (or actually) reverting the fix: the test should go red.
- Name the test after the behavior it protects.
- Run it and confirm it passes now. Don't touch unrelated tests.

This bug happened because bad input got in unchecked. Add guardrails.

Code: @Files [path]
The bad input that caused it: [describe it].

Do this:
- Add validation at the boundary where this input enters (function arg, API payload, env var).
- Fail fast with a clear error instead of letting the bad value propagate.
- Don't over-validate deep internals that a boundary check already covers.
- Add a test for the rejected-input case and re-run it.

We keep hitting this bug. Write a Cursor rule so Agent stops introducing it.

The recurring mistake: [describe the pattern, e.g. "forgetting to await DB calls" or "mutating state directly"].

Do this:
- Draft a .cursor/rules/[name].mdc file that tells Cursor to avoid this pattern and what to do instead.
- Scope it with the right glob (e.g. matches [src/**/*.ts]) and set it to Auto Attached.
- Keep it short and specific — one clear do/don't, with a tiny example.
- Explain where to save it so it applies to every future Ask/Agent/inline run.