Prompt · Code

Error debugging prompt

Facing a stack trace at the point where you have already tried the obvious thing and it did not work.

The prompt

Help me debug this.

<error>
{{error}}
</error>

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

<context>
{{context}}
</context>

Give me the three most likely causes, ordered by probability, not by how interesting they are.

For each:
- The cause, in one sentence.
- Why this error and this code point at it.
- The cheapest way to confirm or rule it out — a command, a log line, a one-line change. Not a rewrite.

Then state which one you would check first and why.

If the error is a generic one that this trace does not distinguish between causes for, say that and tell me what to capture — a fuller stack trace, a log level, a value at a specific point — rather than guessing.

Do not propose a fix until a cause is confirmed. A fix for the wrong cause makes the next round of debugging harder.

What to fill in

{{error}}: The complete message and stack trace, unedited. The frames you trimmed are usually the ones that matter.
{{code}}: The code around the failing line, plus anything the trace names.
{{context}}: What changed recently, what you already tried, whether it is intermittent, and whether it reproduces locally. This is the field that most improves the answer and the one most often left empty.

Why it is written this way

Every rule in the prompt is there because of a specific failure it prevents. Knowing which is which is what lets you adapt it instead of only pasting it.

Three causes, not one

A single confident answer is right often enough to be trusted and wrong often enough to waste an afternoon. Three ranked hypotheses keep you moving when the first is wrong, and the ranking is itself information.

Each cause carries a cheap test

The point is to eliminate quickly. A hypothesis you can rule out with one log line is worth more than a better hypothesis that needs a refactor to test.

Fixes are deferred

Fixing before confirming is how a simple bug becomes two bugs. The instruction is explicit because the model will otherwise jump straight to a patch.

Insufficient information is a valid answer

Some traces genuinely do not distinguish between causes. Being told what to capture is more useful than three confident guesses about a message that could mean anything.

The version most people write, and what it costs

I'm getting this error, how do I fix it?

{{error}}

You get one confident cause and a patch. If the cause is right, you saved five minutes. If it is wrong — and on a generic error it usually is — you now have a change in the codebase that does nothing, masking the real problem and making the next hypothesis harder to test.

What it still gets wrong

It cannot see your running system. Anything caused by data, timing, environment or infrastructure is invisible unless you described it in the context field.
Intermittent bugs are poorly served. A trace from one occurrence rarely distinguishes a race condition from a data problem.
It will recognise common library errors well and unusual internal ones poorly, because the first are in the training data and the second are not.

Check it before you ship it

To build one of these from scratch for a task not covered here, the prompt generator assembles the same structure — delimiters, output contract, edge cases — from an expert-authored blueprint, and the prompt review checklist is what to run over the result.