Debugging
7 decisions a prompt of this kind should make on purpose, and 6 things worth leaving out. 5 of them are something only you can supply — we leave them blank rather than let a model invent them.
error, bug, is broken, broken build, broken after, broken test, not working, doesn't work, crash, fails, exception, stack trace, traceback, undefined, why is, why won't, wrong output, 500, hangs, works locally, regression, after the deploy, stopped working, throws, memory leak, timeout
- _Exact symptom & error textOnly you know this. Paste the full error message and stack trace verbatim, plus observed-vs-expected behavior.
- _Reproduction steps & triggerOnly you know this. State the exact steps/input that trigger it and whether it happens every time or intermittently.
- _Environment & what changedOnly you know this. Note versions/OS/runtime and the most recent change (deploy, upgrade, config); when it last worked.
- _Relevant code & dataOnly you know this. Include the failing function/config and a real sample of the input flowing through it.
- _What you already triedOnly you know this. List what you've already checked or attempted and its effect.
- +Desired answer shapeRanked list of most-likely causes, each with a concrete way to confirm it and the fix.
- +Scope constraintKeep the fix scoped to this bug; don't rewrite unrelated code.
Left out for this type: role/persona preamble ('expert senior engineer'); tone directives (friendly, encouraging); vague 'concise and well-structured'; asking for a full rewrite 'to be safe'; long product/business-goal background; 'explain best practices for X' instead of diagnosing