Awesome Claude Prompts Unofficial

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.

Task: Debug an error · Other tasks

Fill in the details

Paste the complete output, not a summary. The lines around the error often matter as much as the message itself.

Optional. Include the code the stack trace points to. Remove secrets such as keys or passwords first.

Optional. List the steps you tried and what happened, so Claude can take them into account.

Copy your prompt

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

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

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.
  • Code review prompt: 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: 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: Get a concept explained at your level, in the format that helps you most, with a quick self-check and the common misconceptions.

See all templates

Sources