# Debug an error

Turn an error message and the code around it into a ranked list of likely causes, a check for each, and a fix you can try.

Paste into: **a new Claude conversation**

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
<error>
{{error}}
</error>
{{#code}}

<code>
{{code}}
</code>
{{/code}}

Help me find the cause of the error above.

Expected behavior: {{expected}}
{{#environment}}
Environment: {{environment}}
{{/environment}}
{{#tried}}
Already tried:
{{tried}}
{{/tried}}

Work through it in this order:
1. Explain in plain words what the error means.
2. List the most likely causes, most likely first. For each, say what in the error or code points to it.
3. For each cause, give one quick check that would confirm or rule it out.
4. Suggest a fix for the most likely cause, with a short code change when it helps.

Base your answer on the error and code shown. If the cause depends on something I have not included, such as a config file, a dependency version or another function, say exactly what you need to see instead of guessing.
```

## Fields

- `{{error}}` (required): Error message or stack trace. Paste the complete output, not a summary. The lines around the error often matter as much as the message itself.
- `{{expected}}` (required): What you expected to happen.
- `{{code}}`: Relevant code. Optional. Include the code the stack trace points to. Remove secrets such as keys or passwords first.
- `{{tried}}`: What you have already tried. Optional. List the steps you tried and what happened, so Claude can take them into account.
- `{{environment}}`: Environment.

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- You have an error message or stack trace and are not sure where to start looking.
- You suspect several possible causes and want them ranked, with a quick way to rule each one in or out.
- You have already tried the obvious steps and want suggestions that do not repeat them.

## When not to use it

- The problem is a wrong result with no error at all. Describe the input, the output you got and the output you expected instead; a plain debugging conversation works better than this structure.
- The failure depends on a large system you cannot paste, such as a production database or a cluster. Claude can only reason about what you show it.
- The code or logs contain secrets, customer data or anything you are not allowed to share. Redact it first or reproduce the error with fake data.

## Why this structure

- The error comes first inside `<error>` tags, followed by the optional `<code>` block, so the raw material is clearly separated from your question and from each other.
- The expected behavior line is required because an error only makes sense against what should have happened. It also gives you a reference for checking whether a suggested fix keeps the behavior you want.
- The four numbered steps ask for an explanation, ranked causes, a check for each cause, and then a fix. This order asks Claude to establish the cause before proposing a patch that might only treat a symptom.
- Asking what in the error or code points to each cause makes the reasoning visible, so you can judge it instead of trusting it.
- The final paragraph tells Claude to name missing information instead of guessing, which is common when the real cause sits in a file you did not paste.

## Example input (fictional)

Error message or stack trace:

```
TypeError: Cannot read properties of undefined (reading 'map')
    at renderList (list.js:14:22)
    at App (app.js:8:5)
```

What you expected to happen:

```
The list of saved recipes appears on the page
```

Relevant code:

```
function renderList(data) {
  return data.items.map((item) => `<li>${item.name}</li>`).join("");
}
```

What you have already tried:

```
Reloaded the page and checked that the server is running.
```

Environment:

```
Chrome 130, plain JavaScript, no framework
```

## Follow-ups to send Claude

- The first check came back negative. Here is the output of the second check; what does it tell us?
- Write the smallest code change that fixes this, and a test that would fail before the fix and pass after it.
- Explain why this error appears at that line when the real problem is elsewhere.

## Common mistakes

- Pasting only the last line of the error. The stack trace shows where the failure started, which is often far from where it was reported.
- Leaving out what you expected. Without it, Claude can only make the error go away, which is not the same as making the code correct.
- Applying a suggested fix without running the quick check first. The checks exist so you confirm the cause before you change code.

## Related templates

- [Code review prompt](https://awesomeclaudeprompts.com/prompts/code-review/): Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
- [Write unit tests](https://awesomeclaudeprompts.com/prompts/write-unit-tests/): Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.
- [Explain a concept](https://awesomeclaudeprompts.com/prompts/explain-concept/): Get a concept explained at your level, in the format that helps you most, with a quick self-check and the common misconceptions.

## Sources

- [Prompting best practices: Be clear and direct](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#be-clear-and-direct) (Anthropic documentation)
- [Prompting best practices: Structure prompts with XML tags](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#structure-prompts-with-xml-tags) (Anthropic documentation)
- [Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.