Der Stack Trace Decoder: Füge jeden beliebigen Fehler ein, erhalte Ursache + Fix in Sekunden.
Why this prompt matters
Debugging is where developer time disappears. Reading a stack trace tells you where the crash happened, but not why. This prompt gives you both — a diagnosis that explains the root cause in plain language, the exact code change to fix it, and an explanation of the underlying mechanism so you don't hit the same bug twice. It works regardless of language or framework because it reasons from the error text and stack trace, not from memorized APIs.
What we use it for
Debug runtime errors faster — paste the error, stack trace, and relevant code snippet, and get a root cause diagnosis with a working fix and a clear explanation.
Prompt
I'm debugging an error. Please help me understand what went wrong and how to fix it. **Error message:** [PASTE ERROR MESSAGE HERE] **Stack trace:** [PASTE FULL STACK TRACE HERE] **Relevant code (the function/file where the error originates):** ``` [PASTE CODE HERE] ``` **Context:** - Language/runtime: [e.g. Python 3.11, Node.js 22, Go 1.22] - What I was trying to do when the error occurred: [one sentence] - What I've already tried: [or "nothing yet"] Please provide: 1. **Root cause** — explain in plain language what actually went wrong and why 2. **The fix** — show the corrected code with inline comments explaining the change 3. **Why this happened** — the underlying mechanism or misconception that caused the bug, so I understand it rather than just copying the fix 4. **Prevention** — one sentence on how to avoid this class of error in the future
Result
The Prompt
I'm debugging an error. Please help me understand what went wrong and how to fix it.
**Error message:**
[PASTE ERROR MESSAGE HERE]
**Stack trace:**
[PASTE FULL STACK TRACE HERE]
**Relevant code (the function/file where the error originates):**
```
[PASTE CODE HERE]
```
**Context:**
- Language/runtime: [e.g. Python 3.11, Node.js 22, Go 1.22]
- What I was trying to do when the error occurred: [one sentence]
- What I've already tried: [or "nothing yet"]
Please provide:
1. **Root cause** — explain in plain language what actually went wrong and why
2. **The fix** — show the corrected code with inline comments explaining the change
3. **Why this happened** — the underlying mechanism or misconception that caused the bug, so I understand it rather than just copying the fix
4. **Prevention** — one sentence on how to avoid this class of error in the futureHow to Use It
Copy the template above. Fill in the four sections — error message, stack trace, code, and context. The more complete the stack trace, the better the diagnosis. You don't need to edit or clean it up; paste it raw.
The context section is optional but worth filling in. "What I was trying to do" helps the model understand intent. "What I've already tried" prevents it from suggesting things you've already ruled out.
What You Get Back
The four-part response structure is designed specifically to avoid the two most common failure modes of AI debugging help:
- The blind fix — giving you corrected code without explaining why the original was wrong. You apply it, it works, but you don't understand it and hit the same pattern in a different file next week.
- The vague diagnosis — "it looks like there might be a null reference issue." No specifics, no fix, no path forward.
The structured output forces specificity: root cause first (what is actually broken), then the fix with inline comments (not just a code dump), then the mechanism (the why behind the why), then prevention (a rule you can internalize).
Works Across Languages
This prompt is language-agnostic. It works well with:
- Python — great for tracebacks, import errors, type errors, async/await issues
- JavaScript / TypeScript — handles Node.js errors, browser console exceptions, TypeScript compiler errors
- Go — runtime panics, goroutine stack traces, interface assertion failures
- Java / Kotlin — NullPointerException chains, JVM stack traces, Spring context errors
- Rust — compiler error messages (which are already detailed but still benefit from explanation)
- SQL — query parse errors, constraint violations, deadlock traces from PostgreSQL/MySQL
For compiled languages where the stack trace is less informative, paste the full compiler output along with the error.
Example Input and Output
Input (simplified):
Error message: TypeError: Cannot read properties of undefined (reading 'map')
Stack trace:
at ProductList (ProductList.jsx:14:22)
at renderWithHooks (react-dom.development.js:14985:18)
Relevant code:
function ProductList({ products }) {
return (
<ul>
{products.map(p => <li key={p.id}>{p.name}</li>)}
</ul>
);
}
Context: React 18, Node 22. Trying to render a list fetched from an API.What a good response looks like:
- Root cause:
productsisundefinedwhen the component first renders, before the API response arrives..map()can't run onundefined. - Fix: Add a default value —
function ProductList({ products = [] })— or add a null guard before the map. - Why this happened: React renders synchronously before async data fetches resolve. The component renders with whatever initial value the parent passes, which is
undefinedif the parent hasn't set an initial state yet. - Prevention: Always initialize list props with a default empty array and handle loading/empty states explicitly in the component.
Tips for Better Results
- Paste the full stack trace, not just the top line. Lower frames often reveal the actual call that triggered the error.
- Include the immediate surrounding code, not just the line that errored. A few lines of context above and below matter.
- If the error is intermittent, say so — the model will consider race conditions and timing issues.
- For TypeScript errors, include the
tsconfig.jsonrelevant settings if the error is about strictness or module resolution.
Der Prompt
Ich debugge gerade einen Fehler. Hilf mir bitte zu verstehen, was schiefgelaufen ist und wie ich es beheben kann.
**Fehlermeldung:**
[FEHLERMELDUNG HIER EINFÜGEN]
**Stacktrace:**
[VOLLSTÄNDIGEN STACKTRACE HIER EINFÜGEN]
**Relevanter Code (die Funktion/Datei, in der der Fehler auftritt):**
```
[CODE HIER EINFÜGEN]
```
**Kontext:**
- Sprache/Runtime: [z. B. Python 3.11, Node.js 22, Go 1.22]
- Was ich tun wollte, als der Fehler auftrat: [ein Satz]
- Was ich bereits versucht habe: [oder „noch nichts“]
Bitte liefere:
1. **Ursache** — erkläre in einfacher Sprache, was genau schiefgelaufen ist und warum
2. **Die Lösung** — zeige den korrigierten Code mit Inline-Kommentaren, die die Änderung erklären
3. **Warum es passiert ist** — der zugrundeliegende Mechanismus oder das Missverständnis, das den Bug verursacht hat, damit ich es verstehe und nicht nur die Lösung kopiere
4. **Prävention** — ein Satz, wie man diese Art von Fehler in Zukunft vermeidetWie man es verwendet
Kopiere die Vorlage oben. Fülle die vier Abschnitte aus: Fehlermeldung, Stacktrace, Code und Kontext. Je vollständiger der Stacktrace, desto besser die Diagnose. Du musst nichts bearbeiten oder säubern – füge es roh ein.
Der Kontextabschnitt ist optional, aber es lohnt sich, ihn auszufüllen. „Was ich tun wollte“ hilft dem Modell, die Absicht zu verstehen. „Was ich bereits versucht habe“ verhindert, dass es Dinge vorschlägt, die du schon ausgeschlossen hast.
Was du zurückbekommst
Die vierteilige Antwortstruktur wurde speziell entwickelt, um die beiden häufigsten Fehlermodi von KI-Debugging-Hilfe zu vermeiden:
- Die blinde Lösung — sie gibt dir korrigierten Code, ohne zu erklären, warum der originale falsch war. Du wendest sie an, es funktioniert, aber du verstehst es nicht und stößt nächste Woche in einer anderen Datei auf dasselbe Muster.
- Die vage Diagnose — „es sieht aus, als könnte es ein Nullreferenz-Problem geben.“ Keine Details, keine Lösung, kein weiterer Weg.
Die strukturierte Ausgabe erzwingt Klarheit: zuerst die Ursache (was genau kaputt ist), dann die Lösung mit Inline-Kommentaren (nicht nur ein Code-Dump), dann den Mechanismus (das Warum hinter dem Warum), dann die Prävention (eine Regel, die du verinnerlichen kannst).
Funktioniert sprachübergreifend
Dieser Prompt ist sprachunabhängig. Er funktioniert gut mit:
- Python — großartig für Tracebacks, Importfehler, Typfehler, Async/Await-Probleme
- JavaScript / TypeScript — behandelt Node.js-Fehler, Browserkonsole-Exceptions, TypeScript-Compiler-Fehler
- Go — Runtime-Panics, Goroutine-Stacktraces, Interface-Assertion-Fehler
- Java / Kotlin — NullPointerException-Ketten, JVM-Stacktraces, Spring-Kontextfehler
- Rust — Compiler-Fehlermeldungen (die zwar schon detailliert sind, aber dennoch von Erklärungen profitieren)
- SQL — Query-Parse-Fehler, Constraint-Verletzungen, Deadlock-Traces von PostgreSQL/MySQL
Für kompilierte Sprachen, bei denen der Stacktrace weniger aussagekräftig ist, füge die vollständige Compiler-Ausgabe zusammen mit dem Fehler ein.
Beispiel für Eingabe und Ausgabe
Eingabe (vereinfacht):
Fehlermeldung: TypeError: Cannot read properties of undefined (reading 'map')
Stacktrace:
at ProductList (ProductList.jsx:14:22)
at renderWithHooks (react-dom.development.js:14985:18)
Relevanter Code:
function ProductList({ products }) {
return (
<ul>
{products.map(p => <li key={p.id}>{p.name}</li>)}
</ul>
);
}
Kontext: React 18, Node 22. Versuche, eine Liste aus einer API zu rendern.Wie eine gute Antwort aussieht:
- Ursache:
productsistundefined, wenn die Komponente zum ersten Mal rendert, bevor die API-Antwort eintrifft..map()kann nicht aufundefinedausgeführt werden. - Lösung: Füge einen Standardwert hinzu —
function ProductList({ products = [] })— oder baue eine Nullprüfung vor dem map ein. - Warum das passiert ist: React rendert synchron, bevor asynchrone Datenabrufe aufgelöst werden. Die Komponente rendert mit dem initialen Wert, den die Elternkomponente übergibt – das ist
undefined, wenn die Elternkomponente noch keinen initialen State gesetzt hat. - Prävention: Initialisiere Listen-Props immer mit einem leeren Array als Standard und behandle Lade-/Leerzustände explizit in der Komponente.
Tipps für bessere Ergebnisse
- Füge den vollständigen Stacktrace ein, nicht nur die oberste Zeile. Tiefere Frames zeigen oft den eigentlichen Aufruf, der den Fehler ausgelöst hat.
- Füge den direkt umgebenden Code ein, nicht nur die Zeile mit dem Fehler. Ein paar Zeilen Kontext ober- und unterhalb sind wichtig.
- Wenn der Fehler sporadisch auftritt, sag das – das Modell berücksichtigt dann Race Conditions und Timing-Probleme.
- Bei TypeScript-Fehlern füge die relevanten
tsconfig.json-Einstellungen hinzu, wenn der Fehler mit Striktheit oder Modulauflösung zu tun hat.