The traceback explainer prompt

When you hit an unfamiliar exception type, the temptation is to paste the whole traceback and say "what's wrong?" That works, but the response is usually too long and too generic. You get a paragraph about the exception class, a paragraph about possible causes, and three paragraphs of "you might also try…"

A tighter prompt gives you exactly what you need: what the error means, and the most likely cause given your specific code.

I get this error and I do not understand it. Tell me in 2 sentences what it actually means, then give the most likely cause given the code.

Code:

def average(nums):
    return sum(nums) / len(nums)

print(average([]))

Traceback:

Traceback (most recent call last):
  File "x.py", line 4, in <module>
    print(average([]))
  File "x.py", line 2, in average
    return sum(nums) / len(nums)
ZeroDivisionError: division by zero

Claude Sonnet 4.5 returned:

What it means: You're trying to divide a number by zero, which is mathematically
undefined and causes an error. Python cannot perform division when the
denominator (bottom number) is zero.

Most likely cause: You passed an empty list [] to the average() function, so
len(nums) equals 0, causing division by zero when calculating sum(nums) / len(nums).

Captured from Claude Sonnet 4.5 (claude-sonnet-4-5) on 2026-04-27. Re-runs may differ slightly.

Two short paragraphs. The first is reusable knowledge — what ZeroDivisionError is. The second is specific — exactly which call path produced it. That's the shape you want when debugging at speed.

The decision tree the model walks when it explains a traceback well:

The prompt structure here is worth memorizing as a template:

I get this error and I do not understand it. Tell me in 2 sentences what
it actually means, then give the most likely cause given the code.

Code:
<paste minimal reproducer>

Traceback:
<paste full traceback, no truncation>

The "in 2 sentences" constraint is doing real work. Without it, you get an essay. The "most likely cause given the code" framing is doing more — it forces the model to combine the generic error knowledge with the specific code, instead of giving you generic-only advice. That combination is what an experienced colleague would do at your desk.

Two anti-patterns to avoid:

1. Pasting only the last line of the traceback. The line above (File "x.py", line 4, in <module>) is what tells the model where the call originated. Without the call chain, the model can only guess.
2. Asking "how do I fix this?" before "what does this mean?" The fix prompt belongs in a separate turn. Mixing diagnosis with prescription gets you a fix that may or may not apply to your real situation.

Once you have the diagnosis, the next prompt becomes: "Given that diagnosis, what is the smallest change to the function that prevents this for empty input?" That's a separate, smaller prompt with a single output to review.

Next up: writing prompts that say "this is what should happen, not what it does." :::