Workshop 04
Prompt Debugging Clinic
Get unstuck on purpose instead of re-rolling the same broken prompt.
Overview
What you will build
A repeatable debugging routine, practised on a project that is currently broken.
Who it is for
Anyone who has been stuck in a loop of 'still broken, try again' for more than twenty minutes.
Before you start
- — A project with a bug you have failed to fix at least twice
- — Access to the error message or console output
- — Willingness to undo work
What you will walk away with
- Separate a symptom from a cause before prompting
- Give the builder evidence instead of adjectives
- Know when to revert rather than patch
Resources
Open these in a second tab before you begin.
Instructions
Work through these in order. Where there is a prompt, copy it and fill in the parts in angle brackets.
- 01
Write the bug as three facts
What you did, what you expected, what happened. No theories yet. Most failed fixes come from prompting a guess as if it were a fact.
- 02
Bring evidence
Paste the exact error, the console output, or the exact numbers on screen. 'It looks wrong' cannot be debugged; a stack trace can.
Something is broken. Do not change any code yet. What I did: <steps> What I expected: <expected> What happened: <actual> Error output: <paste exactly> Tell me the most likely cause and how you would confirm it before fixing anything.
- 03
Confirm the cause, then fix
Ask for the smallest possible check that proves the diagnosis. Only approve the fix once the check agrees.
Run only the check you described and report what you find. Do not fix anything yet.
- 04
Fix one thing, verify, repeat
Bundled fixes hide which change worked. Keep changes single-purpose so you always know what fixed it.
Fix only the cause you confirmed. Change nothing else. Then tell me exactly how to verify the fix in the preview.
- 05
Know when to revert
If three attempts have not moved the needle, go back to the last version that worked and re-approach from there. Reverting is progress, not defeat.
Build-along
The same journey as milestones, so you can stop at any point and pick it up later. Do not move on until the checkpoint is true.
Milestone 1 — Facts, not theories
The bug written as did / expected / happened.
Checkpoint — No guesses in your description.
Milestone 2 — Named cause
A specific cause proposed and confirmed by a check.
Checkpoint — The check output matches the diagnosis.
Milestone 3 — Verified fix
One targeted change, verified in the preview.
Checkpoint — You can reproduce the old bug and see it gone.
Milestone 4 — Routine
The routine written down for next time.
Checkpoint — You could hand it to a teammate.
Build Submission
Send the before-and-after of one bug: your three facts, the confirmed cause, and the fix.
Submissions are sent by message — nothing is stored on this site.
Submit your buildOther workshops