Debug from a stack trace without guessing

---
name: debug-from-a-stack-trace
description: "Forces the model to separate what the trace proves from what it's inferring, rank hypotheses by testability, and give you the cheapest experiment that discriminates between them. Use when the user asks for help with engineering tasks like debugging, engineering, troubleshooting."
license: CC-BY-4.0
metadata:
  source: https://promptsbuddy.com/prompts/debug-from-a-stack-trace
  author: "Meghna"
  version: "1.0"
---

# Debug from a stack trace without guessing

Forces the model to separate what the trace proves from what it's inferring, rank hypotheses by testability, and give you the cheapest experiment that discriminates between them.

## Inputs to collect first

Ask the user for anything below that they have not already given you. Do not
invent values for these.

- `TRACE` — The full stack trace or error output. Don't trim it. (e.g. Paste the whole trace, including the framework frames.)
- `CODE` — The function at the top of your own frames, plus anything it calls. (e.g. Paste the relevant source.)
- `WHEN` — When it happens and when it doesn't — the most useful thing you can supply. (e.g. Only in production, only for users with more than 50 saved items, started Tuesday.)

## Tools this works with

Do not require any of these. If one is unavailable, use the stated fallback and
say which input is missing rather than inventing it.

- **Sentry** (needed) — The full trace plus the breadcrumbs and conditions — the 'when does it happen' field does more work than the trace itself.
  - Without it: Ask the user to paste the full trace and describe when it happens.
  - https://sentry.io/
- **Datadog** — Logs for the same job, especially for timing and load-dependent bugs.
  - Without it: Ask the user for the relevant log lines and timings.
  - https://www.datadoghq.com/

## Instructions

Help me debug this. Do not propose a fix yet.

TRACE:
{{TRACE}}

CODE:
{{CODE}}

WHEN IT HAPPENS: {{WHEN}}

**1. What the trace proves.** State only what is certain from the trace
itself — which call failed, with what, in which frame. Separate this from
anything you are inferring. Label inferences `[inferred]`.

**2. What "when it happens" rules out.** Given the conditions I described,
which otherwise-plausible causes are eliminated? This is the most useful
section — be rigorous.

**3. Hypotheses, ranked by testability**, not by likelihood. For each: the
mechanism in one sentence, and the single cheapest observation that would
confirm or kill it. Prefer a log line or a one-off query over a code change.

**4. The discriminating test.** If you could run exactly one thing, what is it,
and what does each possible outcome tell me?

Rules:
- Do not suggest a fix until I come back with results.
- Do not suggest "add error handling" or "add logging" as a hypothesis. Those
  are not causes.
- If the trace is truncated or the relevant frame is missing, say exactly what
  else you need rather than working around it.
- Do not assume library internals you have not seen. Say when you are.

## Notes from people who use this

- The WHEN field does the heavy lifting. 'Only for users with >50 items' eliminates more hypotheses than the trace does.
- Ranking by testability rather than likelihood is deliberate — a cheap test for an unlikely cause beats an expensive test for a likely one.
- Come back with the test result and only then ask for a fix. Fixes proposed before evidence are how you end up with three unrelated changes.

---

Debug from a stack trace without guessing · by Meghna · v1.0
From PromptsBuddy — https://promptsbuddy.com/prompts/debug-from-a-stack-trace
Licensed CC BY 4.0.

Every prompt is also available at /prompts/debug-from-a-stack-trace/skill.md — see all install options.