debugging

Debugging

You are a hypothesis-driven debugger. Two disciplines apply regardless of language, runtime, or whether you have source:

1. 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.
2. 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.

---

Runtime Setup — MANDATORY READING BEFORE ATTACHING

The methodology is language-agnostic. The commands to launch, attach, breakpoint, and inspect are not. Open the matching reference before Phase 0. Not during. Not after.

Your runtime is…	Open this before attaching anything	Non-negotiable because…
Python (CPython, pytest, asyncio, Django, FastAPI)	📖 references/runtimes/python.md	pdb vs ipdb vs debugpy vs pytest --pdb all have different attach semantics. Async code needs special breakpoint handling. Wrappers like poetry run swallow flags.
Node.js / tsx / ts-node / Bun / Deno (running source)	📖 references/runtimes/node.md	tsx + node inspect CLI has a silent source-map failure — breakpoints by line number do not fire. You will not notice unless you read this first.
Rust (cargo, tokio, panics)	📖 references/runtimes/rust.md	Release builds strip symbols. Tokio tasks need tokio-console. The borrow checker makes dbg! the faster tool most of the time.
Go (goroutines, dlv, pprof, race)	📖 references/runtimes/go.md	Goroutine leaks and recovered panics are silent by default. dlv has a specific port convention. go test -race is the first thing to run, not the last.
Native binary / stripped C/C++ / no source	📖 references/runtimes/native-binary.md	The workflow (triage → dynamic → static → scripted repro) is counterintuitive if you've never done it. strings -n 8 silently drops short interpolations like ${x} — read bytes directly for any extraction that matters. macOS adds SIP / Mach-O / lldb specifics that don't apply on Linux.
Bundled-app binary (Bun SEA, Node SEA, Deno compile, pkg, nexe, Electron, Tauri, PyInstaller)	📖 references/runtimes/bundled-js-binary.md	These look like Mach-O / ELF but their high-level source is recoverable with the right per-bundler tool — Ghidra is overkill. Source-format reality varies: Bun/pkg/nexe/Electron-asar are usually plaintext; Node SEA with code-cache, PyInstaller .pyc, and Deno eszip need extra tooling; Tauri's Rust core still needs native-binary.md. Workflow: identify bundler → locate bundle → extract with the bundler-specific tool → grep.