The prompt
Score 10 of 10, Excellent
Use it when Something failed with an error message, stack trace or log you do not fully understand, and you want the likely causes ranked with a way to confirm each.
- {{stack}}
- {{environment}}
- {{experience_level}}
- {{what_i_was_doing}}
- {{recent_changes}}
- {{error_output}}
- {{relevant_code}}
Full prompt and why it works
Prompt
# Role You are an experienced {{stack}} engineer who debugs from evidence: you read the error, form hypotheses and say how to test each one. # Goal Explain the error in the Context section and help me find its cause, so that I can fix it in {{environment}}. I am {{experience_level}}. # Success criteria - The explanation says in plain words what the error means, and which line of the trace or log points to our code rather than to library internals. - Likely causes are ranked by how well they fit the evidence, and each comes with a quick check that would confirm or rule it out. - A fix is suggested only for a cause the evidence supports, and it is the smallest change that addresses that cause. # Constraints - Base the explanation on the error, the log and the code given. Do not assume library versions, configuration or code you cannot see; if they matter, name what you need. - Do not suggest silencing the error (catching and ignoring it, or disabling a check) as a fix. - Leave out general debugging advice that does not apply to this error. # Output format 1. What the error means: 2 or 3 sentences. 2. Where it happens: the file, line and function from the trace that is most likely our code, quoted. 3. Likely causes: a numbered list of up to 4, most likely first, each with the evidence for it and a check to run (a command, a log line to add, or a value to print). 4. Suggested fix: for the top cause only, as a short code block with one sentence on why it works. 5. What to send next: the one piece of information that would narrow it down most. # Stop rules If the error output is cut off or the trace never reaches our code, say so and tell me exactly what to capture instead, for example the full trace with debug logging turned on. # Context What I was doing when it failed: {{what_i_was_doing}} What changed recently: {{recent_changes}} <error_output> {{error_output}} </error_output> <relevant_code> {{relevant_code}} </relevant_code>
Variables
- {{stack}}
- The language, framework and runtime, for example "Node.js with Express" or "Python 3.12 with pandas".
- {{environment}}
- Where it fails, for example "local development", "CI" or "production".
- {{experience_level}}
- How familiar you are with this code, for example "new to this codebase" or "comfortable with it, but new to this library".
- {{what_i_was_doing}}
- The command, request or action that triggered it.
- {{recent_changes}}
- Deploys, upgrades or config changes since it last worked. "Nothing that I know of" is fine.
- {{error_output}}
- The full error message, stack trace or log lines, pasted exactly. Remove secrets and personal data first.
- {{relevant_code}}
- The code the trace points to, if you have it, or "none".
Why it works
- What good looks like. Causes are ranked by fit with the evidence, and each comes with a check you can run, so you test a hypothesis instead of applying a guessed fix.
- What to avoid. Silencing the error is ruled out as a fix, and the model may not assume versions or code it cannot see.
- If unsure. A cut-off trace gets a precise request for what to capture next, rather than an explanation built on half the evidence.