Le Stack Trace Decoder : collez n'importe quelle erreur, obtenez la cause racine et le correctif en quelques secondes.

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 future
How 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.
Le Prompt
Je débogue une erreur. Aide-moi à comprendre ce qui s'est mal passé et comment le corriger.
**Message d'erreur :**
[COLLER LE MESSAGE D'ERREUR ICI]
**Stack trace :**
[COLLER LA STACK TRACE COMPLÈTE ICI]
**Code concerné (la fonction/fichier où l'erreur se produit) :**
```
[COLLER LE CODE ICI]
```
**Contexte :**
- Langage/runtime : [ex : Python 3.11, Node.js 22, Go 1.22]
- Ce que j'essayais de faire quand l'erreur est apparue : [une phrase]
- Ce que j'ai déjà essayé : [ou "rien encore"]
Merci de fournir :
1. **Root cause** — explique en langage simple ce qui a vraiment planté et pourquoi
2. **The fix** — montre le code corrigé avec des commentaires inline expliquant le changement
3. **Pourquoi c'est arrivé** — le mécanisme sous-jacent ou l'idée fausse à l'origine du bug, pour que je comprenne au lieu de simplement copier la correction
4. **Prévention** — une phrase sur comment éviter cette classe d'erreur à l'avenir
Comment l'utiliser
Copie le template ci-dessus. Remplis les quatre sections — message d'erreur, stack trace, code et contexte. Plus la stack trace est complète, meilleur sera le diagnostic. Pas besoin d'éditer ou de nettoyer ; colle-la brute.
La section contexte est optionnelle mais vaut le coup d'être remplie. « Ce que j'essayais de faire » aide le modèle à comprendre l'intention. « Ce que j'ai déjà essayé » l'empêche de suggérer des choses que tu as déjà écartées.
Ce que vous obtenez en retour
La structure de réponse en quatre parties est conçue spécifiquement pour éviter les deux modes d'échec les plus courants de l'aide au débogage par IA :
- La correction aveugle — te donner du code corrigé sans expliquer pourquoi l'original était faux. Tu l'appliques, ça marche, mais tu ne comprends pas et tu retombes sur le même motif dans un autre fichier la semaine suivante.
- Le diagnostic vague — « il semble y avoir un problème de référence null ». Rien de précis, aucune correction, aucune piste pour avancer.
Le format structuré force la spécificité : root cause d'abord (ce qui est vraiment cassé), puis le fix avec des commentaires inline (pas juste un dump de code), puis le mécanisme (le pourquoi du pourquoi), et enfin la prévention (une règle que tu peux intérioriser).
Fonctionne dans toutes les langues
Ce prompt est agnostique par rapport au langage. Il fonctionne bien avec :
- Python — excellent pour les tracebacks, erreurs d'import, erreurs de type, problèmes async/await
- JavaScript / TypeScript — gère les erreurs Node.js, les exceptions de console navigateur, les erreurs du compilateur TypeScript
- Go — panics runtime, stack traces de goroutines, échecs d'assertion d'interface
- Java / Kotlin — chaînes de NullPointerException, stack traces JVM, erreurs de contexte Spring
- Rust — messages d'erreur du compilateur (déjà détaillés mais qui bénéficient quand même d'une explication)
- SQL — erreurs de parsing de requêtes, violations de contraintes, traces de deadlock de PostgreSQL/MySQL
Pour les langages compilés où la stack trace est moins informative, colle la sortie complète du compilateur en plus de l'erreur.
Exemple d'entrée et de sortie
Entrée (simplifiée) :
Message d'erreur : TypeError: Cannot read properties of undefined (reading 'map')
Stack trace :
at ProductList (ProductList.jsx:14:22)
at renderWithHooks (react-dom.development.js:14985:18)
Code concerné :
function ProductList({ products }) {
return (
<ul>
{products.map(p => <li key={p.id}>{p.name}</li>)}
</ul>
);
}
Contexte : React 18, Node 22. J'essayais d'afficher une liste récupérée via une API.
Ce à quoi ressemble une bonne réponse :
- Root cause :
productsestundefinedlors du premier rendu du composant, avant que la réponse API n'arrive..map()ne peut pas s'exécuter surundefined. - Fix : Ajouter une valeur par défaut —
function ProductList({ products = [] })— ou ajouter un garde null avant le map. - Pourquoi c'est arrivé : React effectue le rendu de manière synchrone avant que les récupérations de données asynchrones ne se résolvent. Le composant s'affiche avec la valeur initiale que le parent lui passe, qui est
undefinedsi le parent n'a pas encore défini un état initial. - Prévention : Toujours initialiser les props de type liste avec un tableau vide par défaut et gérer les états de chargement/vide explicitement dans le composant.
Conseils pour de meilleurs résultats
- Colle la stack trace complète, pas seulement la première ligne. Les frames inférieurs révèlent souvent l'appel réel qui a déclenché l'erreur.
- Inclus le code immédiatement environnant, pas seulement la ligne en erreur. Quelques lignes de contexte au-dessus et en dessous sont importantes.
- Si l'erreur est intermittente, précise-le — le modèle considérera les race conditions et les problèmes de timing.
- Pour les erreurs TypeScript, inclus les paramètres pertinents de
tsconfig.jsonsi l'erreur concerne la strictesse ou la résolution de modules.