22 Windsurf Prompts for Debugging & Fixing Errors (2026)

Chat mode. I have this bug: [describe the symptom, e.g. "cart total shows NaN when a coupon is applied"].
Using @codebase, find the code paths involved and write the SMALLEST standalone reproduction that triggers it — a single script or a single failing test in [test dir], with no unrelated setup.
List every input/state that must be true for the bug to appear. Do not fix anything yet — I just want a reliable repro I can run with [npm test / node repro.js].

Write mode. In @file:[path/to/module] I don't know where [value/state] goes wrong.
Add clearly-marked temporary console logging (prefix each line with "DEBUG-[ticket]") at the key branch points and around [the suspicious function]. Don't change any logic.
Then tell me: run [command] and paste the output back to you with @terminal — read it and pinpoint the exact line where [value] first becomes wrong. After we find it, you'll remove every DEBUG-[ticket] line.

Chat mode. This worked on [last known good ref/tag] and is broken on [current branch]: [symptom].
Read @git — the recent commits and diffs between those points. Identify the SMALLEST change most likely to have caused this and explain the exact mechanism (what the old code guaranteed that the new code doesn't).
Rank your top 3 suspect commits with a confidence and a one-line reason each. Don't edit anything — I'll confirm the culprit first.

Read @terminal — the most recent run of [command] crashed with a stack trace.
Trace it to the FIRST line in my own code (ignore node_modules frames) and explain the actual root cause, not just the throwing line. Then propose the minimal fix.
Show me the fix as a diff and wait for my OK before editing. Acceptance: after the fix, re-run [command] and the crash is gone with no new errors.

Explain this error in plain terms, then fix it in my code:
```
[paste the exact error, e.g. "TypeError: Cannot read properties of undefined (reading 'map')"]
```
Using @codebase, find where in [feature/file] this originates. Tell me (1) what the error literally means, (2) why it's happening HERE given my data flow, (3) the smallest correct fix. Don't just add optional chaining to silence it — fix why the value is undefined.

Write mode. @terminal shows this TypeScript error after `tsc --noEmit`:
[reference @terminal or paste the TSxxxx error and file:line]
Fix it PROPERLY — correct the underlying types in @file:[path], don't reach for `any`, `as`, or `@ts-ignore` unless you justify why no better option exists.
Then run `tsc --noEmit` again and confirm zero errors. Don't change runtime behavior; if the types reveal a real bug, flag it before fixing.

My build is broken. Read @terminal — the output of [npm run build / your build command].
Find the root cause (missing import, bad path, version mismatch, misconfigured [bundler/config]) and fix it with the smallest change. If it's a config issue, edit @file:[config file] and explain the one line that mattered.
Acceptance: [build command] exits 0 with no warnings introduced. Re-run it yourself and paste the result.

Chat mode. Using @codebase, find EVERY place [variable/field, e.g. `user.role`] is assigned or mutated across the repo — reads and writes.
For each, give file:line and a one-line note on what it does. Then tell me which of these could set it to [the wrong value I'm seeing] at [when the bug happens].
Don't change code — I want the full map first.

Chat mode. Trace the full path of a [POST /api/orders] request through @codebase: route → controller/handler → service → data layer → response.
At each hop, note what transforms [the field that's wrong]. Point to the exact function where it's set incorrectly for input [example payload]. Give me the chain as a numbered list with file:line, no edits yet.

[value/prop, e.g. `session.user`] is undefined at @file:[path]:[line] when [scenario].
Using @codebase, work BACKWARD from that line to find the origin: where should it have been populated, and why isn't it on this path? Distinguish "never set" from "set then overwritten/cleared".
Give me the root cause and the fix location. Fix the source, not the crash site.

Chat mode. This is intermittent: [symptom, e.g. "stale data ~1 in 20 loads"]. I suspect an async/race issue in @file:[path].
Read the async flow (awaits, promises, effects, event handlers, shared state) and identify any ordering assumption that isn't guaranteed — unawaited promises, state read before it's set, two paths writing the same value.
Explain the exact interleaving that produces the bug, then propose a fix that makes ordering deterministic. No edits until I confirm the interleaving is right.

Write mode. In @file:[Component.tsx], [symptom, e.g. "the list re-renders on every keystroke and loses focus" / "state updates one render late"].
Diagnose the real cause — stale closure, missing/incorrect dependency array, state derived from props, an object/array recreated each render, or setting state in render. Explain which one it is.
Fix it correctly (don't just wrap everything in useMemo). Keep behavior identical otherwise. Then confirm with @terminal that the component's tests still pass.

@terminal shows a hydration mismatch warning on [route/page] in [Next.js / your SSR framework]:
[reference @terminal or paste the warning]
Find what renders differently on server vs. client in @file:[page/component] — Date/random values, `window`/`localStorage` reads during render, browser-only branches, or invalid nested HTML. Explain the specific mismatch.
Fix it so server and client output match, without disabling SSR for the whole page. Confirm the warning is gone.

My [GET /api/report] returns 500. Read @terminal — the server logs from the failing request.
Trace the logged stack/error to the handler in @codebase, find the root cause (bad query, unhandled null, missing await, wrong env var), and fix it. Return a proper error response for the genuinely-invalid case instead of a 500.
Acceptance: reproduce with [curl command or steps], get a 200 (or a correct 4xx) — verify it yourself before telling me it's done.

This test passes locally but fails in CI. Here's the CI log:
```
[paste the failing CI job output — test name, assertion, error]
```
Figure out why it fails ONLY in CI: environment differences (timezone, locale, env vars), test order/shared state, a race under load, or an unmocked network/time dependency. Using @codebase, locate the flaky test and its subject.
Fix the real cause so it's deterministic in CI — do not just add retries or increase the timeout unless that's genuinely correct. Explain the difference that mattered.

Bug: [symptom + how to reproduce]. Work systematically.
1) Using @codebase, propose the 2-3 most likely root causes, ranked, each with a confidence and how you'd confirm it.
2) Verify the top hypothesis by reading the relevant code (and add one temporary log or a quick check if needed) — tell me whether it's confirmed or ruled out.
3) Only once confirmed, apply the minimal fix and run [test command] to prove it. If the top hypothesis is wrong, move to the next before editing.

Write mode. We just fixed [bug] in @file:[path]. Now lock it in.
Write a regression test in [test file] that fails on the OLD behavior and passes on the fixed code. Name it so the ticket [ID] is obvious. Cover the exact input that triggered the bug plus one nearby edge case.
Run the full suite with @terminal and confirm the new test passes and nothing else broke.

Diagnose [symptom] in @file:[path]. Hard rule: DO NOT mask it.
No try/catch that swallows, no `?.` or `?? default` to dodge a null, no disabling the failing assertion, no widening a type to `any`. Find WHY the bad value/state occurs and fix that.
Before editing, state the root cause in one sentence. If a defensive guard is genuinely correct, justify why it's the right fix and not a cover-up.

Chat mode. Memory grows over time in [service/component] and doesn't come back down [under load / after navigation].
Using @codebase, hunt for common leak sources: listeners/subscriptions/timers never removed, caches/maps that only grow, closures holding large objects, [React effects without cleanup / connections never closed].
List each suspect with file:line and why it retains memory, ranked by likelihood. Then, in Write mode, fix the top suspect (add the missing cleanup) and tell me exactly what to measure to confirm the leak is gone.

[GET /api/dashboard] takes [~Xs]. Find and fix the bottleneck.
Read the handler via @codebase and identify the real cost: N+1 queries, a missing index, an unbounded loop, unnecessary serialization, or a blocking call in a hot path. Point to the exact lines.
Fix the biggest offender with the smallest correct change (batch the query / add the index / cache appropriately), keep results identical, and tell me how to measure the before/after. Don't micro-optimize things that don't dominate the time.

Chat mode. It works in [dev/staging] but fails in [prod/other machine]: [symptom].
Compare the two environments systematically — env vars, config files, dependency versions (@file:[lockfile]), Node/runtime version, build flags, and feature toggles. Using @codebase, find every place code branches on environment.
List the differences most likely to explain the symptom, ranked, and tell me exactly what to check to confirm. No edits until we've isolated the difference.

We keep hitting [class of bug, e.g. "unawaited promises causing stale reads"]. Create a rule so Cascade catches it automatically.
Write a scoped rule file at .windsurf/rules/debugging.md with a Glob trigger for [**/*.ts] that says: when editing or reviewing async code, flag unawaited promises and state read before it's set; when fixing a bug, never mask it — find the root cause and add a regression test.
Keep it under 15 lines. After you write it, summarize the trigger and scope so I can confirm it won't over-fire.