Debug running programs interactively with breakpoints and live inspection

This skill interactively debugs source code using dap, a CLI and background daemon speaking the Debug Adapter Protocol, supporting Python, Go, Node.js and TypeScript, Rust, C and C++, and any other DAP-compatible language. It lets an agent pause a running program at any point, read live variable values and the call stack at that exact moment, step forward line by line or jump to the next breakpoint, and evaluate arbitrary expressions against the live process without restarting - reaching for it when reading source alone can't validate a root cause and re-running with more print statements would be too slow.

Session start strategies vary by what's known: set a breakpoint at a hypothesized location, a conditional breakpoint that only stops when an expression is true, breakpoints across multiple files for a multi-file app, a stop-on-entry flag to walk from the start for a small program with no hypothesis, avoided for large projects due to noisy startup, a break-on-exception flag to catch an exception at an unknown location, an attach flag for a remote process, or a process-ID flag to attach to an already-running stuck process, noting a macOS and Go gotcha requiring a security feature disabled for that attach mode, so starting under the debugger or attaching remotely is preferred - with a session flag isolating concurrent agents from interfering with each other's debug state.

Its debugging mindset holds that a debugger observes what actually happens - values, path, state - versus what should happen, and that divergence is the bug; if two hypotheses fail at the same location, the mental model is wrong and needs a completely different theory; escalate gradually from a quick expression evaluation, to conditional breakpoints filtering noise, to full breakpoints and stepping only when needed; mimic the expected user or code journey to find where execution diverges from expectation; and set breakpoints instead of reaching for print statements. Every stop returns full context automatically - location, source, locals, call stack, and output - and tracing causation up the stack means evaluating an expression in a specific caller frame until the frame where a value first became wrong is found, which is the bug's origin, not its symptom. Breakpoints should be set where a problem begins rather than where it manifests, at data boundaries, state transitions, or a wrong-branch condition, bisecting with two breakpoints when uncertain, avoiding breaks inside library code in favor of the call site, and avoiding unconditional breaks in tight loops in favor of a condition. Breakpoints can be added or removed mid-session for progressive narrowing without restarting. Conditional and invariant breakpoints, such as stopping the moment a balance goes negative or a value's type is wrong, act as runtime assertions. Navigation commands cover stepping over, into, or out, continuing to the next or a specific breakpoint, re-inspecting current state, draining buffered output, inspecting nested variables at a given depth, pausing a hanging program, restarting with the same arguments and breakpoints, and switching threads - with a rule that stepping more than three times in a row means a breakpoint is needed instead. Expression evaluation probes live state read-only, avoiding side-effecting calls that could corrupt the session, and a disposable one-shot breakpoint supports a quick peek at a line without managing its lifecycle. A worked walkthrough shows narrowing from a bad hypothesis, a missing assignment, to the real root cause, an empty list from a config with no guard, by adding and removing breakpoints and inspecting caller frames. Fixes are verified by testing the fix expression live before editing, then restarting to confirm end-to-end - never trusting a fix until observed working at the same breakpoint where the bug was found.

Use it when a program crashes, raises unexpected exceptions, produces wrong output, or when understanding exactly how execution reached a state requires more than re-running with extra print statements.

Given a program and a bug hypothesis, or none, it produces a live debugging session with breakpoint state, variable inspection, call-stack traces, and a verified root-cause fix confirmed by restarting the same scenario. A companion reference file covers advanced scenarios like hangs, concurrency bugs, deeply nested state, and loop bisection.

The dap CLI, installable via Homebrew, an install script, or a Go install command, which wraps any DAP-compatible debugger backend for the target language.

Developers debugging crashes, wrong output, or hard-to-trace execution paths who want live variable and call-stack inspection with hypothesis-driven breakpoint narrowing instead of print-statement debugging.