Engineering

Stack Trace Analysis Prompt

Read the trace bottom-up, find the frame where the bad value entered, and name what made it bad — the trace is a map, not an answer.

Open in Debugging Prompt Generator

Overview

A stack trace shows the path to the crash — and teams still patch the top frame and move on. This setup analyzes a Python AttributeError from an import job: the trace says .strip() failed on a float at normalize.py line 31, but the investigation asks the real questions — where did a float enter a path that expects strings? which upstream frame stopped enforcing the contract? — tracing the execution path backward and treating the throw frame as the start of the investigation, not the end.

How to use this resource

Paste the whole trace

Every frame matters — the detector recognizes it, and the analysis walks it bottom-up.
Find the entry frame

The investigation's pivot: the boundary where the bad value entered the failing path.
Fix at the contract, not the crash

The repair belongs where the contract broke — usually frames above the throw, sometimes in the data itself.

Why This Works

Bottom-up reading turns the trace from a blame pointer into an evidence chain
Entry-frame hunting localizes the bug to where it is fixable once
Contract framing decides the eternal question: fix the caller or the callee

Best for

Crashes deep in utility code that "never changed"
Type errors that surface far from their source
Import/ETL jobs that die mid-file

Not for

Traces from intermittent failures — the intermittent strategy's pattern hunt comes first
Minified production JS traces — source-map them before investigating

Use cases

Working a traceback to the frame where the bad value entered
Finding the implicit contract the crashing code assumed
Deciding between fixing the data, the caller, or the callee

FAQ

How does this stack trace prompt avoid just fixing the top frame of the traceback?

The INVESTIGATION FRAMEWORK forces stage 5 ROOT CAUSE ANALYSIS to separate the proximate cause (what threw) from the root trigger (what made it throw), and the ROOT CAUSE RULES state the symptom site and the cause site may be different places. For the sample AttributeError, that means asking where the float entered a path expecting .strip(), not patching normalize.py line 31.

What output format does the debugging-prompt-generator produce for analyzing a crash like this AttributeError?

It produces a prompt that makes the assistant work through ten named stages in order, from SYMPTOMS to POST-FIX VERIFICATION, and label every statement as FACT, ASSUMPTION, or HYPOTHESIS with its test per the EVIDENCE RULES. You copy that prompt and run it in your own assistant; NewPrompt does not run the investigation or confirm the diagnosis.

When should I not use this stack trace analysis prompt?

Skip it for intermittent failures, because this template's VALIDATION REQUIREMENTS lean on the gold standard of a reproduction that turns the failure on and off by toggling the suspected cause. Also skip minified production JS traces until you source-map them, since the bottom-up frame walk needs real file and line names like normalize.py line 31.

Can I use this for a crash that isn't a Python AttributeError from an import job?

Yes — the AttributeError at normalize.py line 31 is a worked example, so replace the KNOWN FACTS block (Symptoms, Actual behavior, the Traceback) with your own trace, and adjust the SYSTEM CONTEXT Reported severity. The DEBUGGING CHECKLIST item on input that violates an implicit contract the code never checks generalizes to any type error surfacing far from its source.

Customize This Resource

Opens this setup in Debugging Prompt Generator. Generate to get the full investigation contract — then adjust the problem type, mode, and environment.

Open in Debugging Prompt Generator

Prompt Template

Copy it as-is, or use Open in Debugging Prompt Generator to load it pre-filled and customize it with your own context.

DEBUGGING OBJECTIVE
Work through this stack trace to the root trigger, not just the throw site.
Problem type: runtime error — an exception, crash, or stack trace marks the failure.
Determine what is actually happening. Do not jump directly to a solution before identifying the most likely root cause.

SYSTEM CONTEXT
Environment: local development — full access to debugger, logs, and code; reproduce freely and instrument aggressively.
Reported severity: Medium.
Investigation strategy for this problem type:
- Locate the exact failure point: the line, the call, and the state at the moment of failure.
- Trace the execution path backward from the failure to its trigger — the throw site is rarely the cause site.
- Distinguish the proximate cause (what threw) from the root trigger (what made it throw).

KNOWN FACTS
Symptoms: The import job crashes part-way through large files.
Expected behavior: The import completes and reports a row count.
Actual behavior: AttributeError after ~8,000 rows; the job aborts.
Reproduction steps:
- Run the import with the March export file (about 12,000 rows)
Logs / errors:
```
Traceback (most recent call last):
  File "import_job.py", line 88, in process_batch
    record = normalize(row)
  File "normalize.py", line 31, in normalize
    return row["amount"].strip()
AttributeError: 'float' object has no attribute 'strip'
```

INVESTIGATION FRAMEWORK
Structure the investigation in exactly these stages:
1. SYMPTOMS — restate the observable symptoms, separating observations from interpretations.
2. KNOWN FACTS — list what is directly evidenced, each fact with its source.
3. REPRODUCTION STEPS — verify the provided steps reproduce the problem; reduce them to the minimal failing case.
4. POSSIBLE CAUSES — candidate causes, drawn from the checklist below and from the evidence.
5. ROOT CAUSE ANALYSIS — the most likely cause and the alternatives, per the root cause rules.
6. EVIDENCE REVIEW — which evidence is solid, which is weak, which is missing, and what contradicts what.
7. MISSING INFORMATION — what you need that you do not have. Ask for it; do not guess it.
8. VALIDATION PLAN — the tests or observations that will confirm or eliminate the leading cause.
9. FIX RECOMMENDATION — per the fix requirements below.
10. POST-FIX VERIFICATION — per the verification requirements below.

DEBUGGING CHECKLIST
Candidate causes to check for this problem type:
1. Null/undefined references on the failure path
2. Dependency failures (network, database, filesystem) surfacing as exceptions
3. Invalid state reached through an unexpected order of operations
4. Configuration differences from the environment where it works
5. Environment drift: versions, locales, time zones, OS differences
6. Input that violates an implicit contract the code never checks

ROOT CAUSE RULES
- Identify the MOST LIKELY root cause — and at least two ALTERNATIVE causes.
- For each candidate cause: list the evidence supporting it AND the evidence contradicting it.
- Define a validation step for each candidate: what observation would confirm or eliminate it.
- The symptom site and the cause site may be different places — finding where it hurts is not finding why.

EVIDENCE RULES
Label every statement as exactly one of:
- FACT: directly observed. Example: "The application returned HTTP 500."
- ASSUMPTION: believed without direct evidence. Example: "The database is probably down." Assumptions must be verified or discarded — never silently promoted to facts.
- HYPOTHESIS: a testable causal claim. Example: "A failed database connection may be causing the 500 response." Every hypothesis comes with its test.
- Prefer evidence over inference; where evidence is missing, label the assumption explicitly.
- Carry at least two hypotheses until evidence separates them.

VALIDATION REQUIREMENTS
- Before proposing any fix, state how the diagnosis was validated — or what validation is still pending.
- The gold standard: a reproduction that turns the failure on and off by toggling the suspected cause.
- If the root cause cannot be validated with the available information, say so and list what is needed.

FIX REQUIREMENTS
- Any fix proposal must include: the likely cause, the supporting evidence, the proposed change, and how to verify it worked.
- Frame it as "here is why this is likely the fix" — never an unexplained patch.
- Prefer the smallest fix that addresses the root cause; label symptom-only fixes as temporary mitigations.

POST-FIX VERIFICATION
- Define what to observe after the fix: the original reproduction passing, error rates at baseline, the affected metric recovered.
- Check for regressions in the paths the fix touched.
- State how long to observe before declaring the problem resolved — intermittent problems need longer windows.

More resources from Debugging Prompt Generator

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Resource

Error Analysis Prompt

An exception is a symptom, not a diagnosis: trace from the throw site back to the root trigger, with the runtime checklist on the table.

Engineering

Resource

Debug Performance Problems

Measure before reasoning: find WHERE the time goes, separate latency from memory from throughput, and think at production scale.

Engineering

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Related tools

Tool

Debugging Prompt Generator

Build debugging prompts from symptoms, environment, and reproduction steps — root cause first, fix second.

Coding Workflows

Guides for this resource

Guide

How to Analyze a Stack Trace With AI Without Trusting the Top Line

A stack trace is precise about where execution stopped and nearly silent about why it started going wrong. Here is how to analyze a stack trace with AI: read the exception chain inside out, find the frames you own, and separate what the trace proves from what it merely suggests.

Software Development with AI

Tip: Save time by exploring related resources and tools that integrate with this resource.