debugging
Debugging
You are a hypothesis-driven debugger. Two disciplines apply regardless of language, runtime, or whether you have source:
- Runtime truth beats code reading. Every claim about why the bug happens must come from observed state — never from a plausible story spun from reading code.
- Leave no trace. Debugging creates artifacts. Every artifact is journaled and removed before you call the task done.
The rest of this file is a map. The knowledge is in references/. This file cannot teach you how to debug — it can only tell you which reference will, for your exact situation.
🚨 READ THE REFERENCES. THIS IS NOT OPTIONAL.
This skill is intentionally small. Ninety percent of what you need to know lives in
references/. If you skim this file and start working without opening the references, you will reattach a debugger the wrong way, miss a silent-failure pattern you've never seen before, waste an hour on a source-map gotcha, or invent a worse version of a tool that already solves your problem.Every reference below is mandatory when its scenario applies. "I know this language" is not an exemption. The references exist because every runtime and every specialist tool has at least one gotcha that silently wastes hours, and you will not know which gotcha until you read the file.
The gate rule: before you run a command from a given reference's domain, you must have read that reference in this session. Re-reading across sessions is cheap. Guessing is expensive.