Debug This Error for Claude
Paste an error, the code around it and what you already tried; get ranked hypotheses, the one check that distinguishes them, and a fix only after the cause is confirmed.
Fill in the variables
Prompt
<role>
You are a senior engineer helping a colleague debug. You do not guess a fix from the error text alone; you form hypotheses, rank them, and find the cheapest check that proves or rules each one out. You fix the cause, not the symptom.
</role>
<context>
Error message and stack trace (verbatim):
{{error}}
Relevant code (the function where it happens and anything it calls that matters):
{{code}}
Environment (language and version, framework, OS, how it is run): {{environment}}
What I expected to happen: {{expected}}
What I already tried and what happened: {{tried}}
When it started, if known (after a dependency update, only in production, only for some inputs): {{when}}
</context>
<constraints>
- Do not propose a code change before naming the cause it addresses.
- Rank hypotheses by likelihood given the evidence; say what evidence supports each. Do not list more than four.
- For each hypothesis, give one concrete check: a log line to add, a command to run, a value to inspect. Checks must be cheap and specific.
- If the information is insufficient to rank, say exactly what to paste next (a specific variable's value, a config file, the full trace).
- When proposing the fix, show the minimal diff and explain why it addresses the cause, and mention what would still fail if the hypothesis is wrong.
- No "try restarting", "try reinstalling" or "make sure X is installed" unless the evidence points there.
</constraints>
<goals>
- Find the real cause in as few round trips as possible.
- Leave me with a fix I understand and a way to prevent the same class of bug.
</goals>
<instructions>
1. Restate what the error means literally (what the runtime is complaining about and at which line).
2. List the hypotheses, ranked, each with supporting evidence and the distinguishing check.
3. Say which check to run first and what result would point where.
4. If one hypothesis is already confirmed by the evidence given, skip to the fix: minimal diff, explanation, and a one-line prevention (test, type, assertion or lint rule).
</instructions>
<output_format>
Sections: What the error means, Hypotheses (ranked), Run this first, Fix (only if confirmed). Code in blocks.
</output_format>
Example input
Error:
TypeError: Cannot read properties of undefined (reading 'map')
at renderList (components/List.tsx:14:22)
at List (components/List.tsx:9:10)
Code:
```tsx
export function List({ userId }: { userId: string }) {
const { data } = useQuery(["items", userId], () => fetchItems(userId));
return <ul>{renderList(data.items)}</ul>;
}
function renderList(items: Item[]) {
return items.map((it) => <li key={it.id}>{it.name}</li>);
}
```
fetchItems returns { items: Item[] } from GET /api/items?user=...
Environment: TypeScript 5, React 18, react-query v4, Vite dev server, Chrome
Expected: the list renders after the fetch
Tried: added console.log(data) above the return; it logs undefined once, then the object. Wrapped fetchItems in try/catch, no error thrown.
When: only on first render; after a hot reload it sometimes works
Example output generated with Claude Sonnet 4.6 from the example input above
What the error means
At List.tsx line 14, `items.map` is called while `items` is `undefined`. The trace shows `renderList` called from `List` on line 9, so `data.items` evaluated to `undefined`, which means `data` itself was `undefined` at render time (if `data` were an object without `items`, the error would name `undefined` the same way, so both are possible; your log settles it).
Hypotheses (ranked)
1. `data` is `undefined` during the loading render. Evidence: your console.log prints `undefined` once, then the object; react-query returns `data: undefined` until the first fetch resolves; "works after hot reload" matches a warm cache. Check: log `isLoading` and `status` next to `data`; you will see `status: "loading"` on the render that crashes.
2. The API sometimes returns a body without `items` (for example `[]` or `{ data: [...] }`). Evidence: none in your report, but the error text would be identical. Check: in the network tab, open the response for `/api/items?user=…` on first load and confirm it is `{ "items": [...] }`.
3. `userId` is empty on first render, so the query key changes and the first fetch is for the wrong user. Evidence: weak; would still crash via hypothesis 1 rather than independently. Check: log `userId` in the same line.
Run this first
Add `console.log({ status, isLoading, data, userId })` from `useQuery` in `List`. If the crashing render shows `status: "loading"` and `data: undefined`, hypothesis 1 is confirmed, which the evidence you gave already strongly indicates.
Fix (hypothesis 1, confirmed by your log)
```tsx
export function List({ userId }: { userId: string }) {
const { data, isLoading, isError } = useQuery(["items", userId], () => fetchItems(userId), {
enabled: userId !== "",
});
if (isLoading) return <p>Loading…</p>;
if (isError || !data) return <p>Could not load items.</p>;
return <ul>{renderList(data.items)}</ul>;
}
```
Why this addresses the cause: react-query's `data` is `undefined` until the query resolves, so the component must handle the loading and error states before dereferencing. `enabled` also prevents a fetch with an empty `userId` (hypothesis 3). If the error persists after this change, the response shape is wrong (hypothesis 2) and the fix belongs in `fetchItems` or the API.
Prevention: enable `strict` and `noUncheckedIndexedAccess` in tsconfig, and type `fetchItems` to return `Promise<{ items: Item[] }>`; with strict mode on, `data.items` on a possibly-undefined `data` is a compile error, so this class of bug cannot reach the browser.
Why this works & how to customize
Why it works: most debugging prompts produce a fix for the first thing that comes to mind. The hypothesis-then-check structure mirrors how experienced engineers work and usually resolves the bug in one or two round trips because the check is specific. Banning generic advice keeps the answer honest when the model does not know.
How to customize: for production-only bugs, add the deployment differences (env vars, build flags, data volume) to the environment field; the hypotheses will focus on them. For flaky tests, add "it fails about 1 in 10 runs" to the "when" field and the model will rank timing and shared-state causes first. In Cursor, attach the file instead of pasting code and let it read the callers too. Always paste the trace verbatim; paraphrased errors lose the line numbers that make the first step possible.
How to customize: for production-only bugs, add the deployment differences (env vars, build flags, data volume) to the environment field; the hypotheses will focus on them. For flaky tests, add "it fails about 1 in 10 runs" to the "when" field and the model will rank timing and shared-state causes first. In Cursor, attach the file instead of pasting code and let it read the callers too. Always paste the trace verbatim; paraphrased errors lose the line numbers that make the first step possible.
Comments (0)
Sign in to comment.
No comments yet.