debug
Installation
SKILL.md
Debug
Maximize information gained per failing reproduction. Treat code reading, tests, static analysis, and existing telemetry as hypothesis inputs; require runtime evidence to prove the originating fault, its propagation, and the reported symptom.
Use one coverage-first workflow. Scale probe breadth with reproduction cost, residual ambiguity, privacy risk, and observer cost. Treat “one pass” as the initial failing reproduction only; allow a targeted blind-spot run and a separate post-repair verification run when needed.
Broad first-pass breakpoint batch
- When a supported native debugger is attached and pausing is safe, derive the complete first-pass breakpoint set from the causal map before any
runorcontinue. Install every safe, nonredundant initial breakpoint in one setup phase. If the debugger accepts one location per call, issue all set-breakpoint calls back-to-back without resuming between them. Never default to one or two exploratory breakpoints while additional material locations are already justified. - Cover the failing-flow ingress and symptom boundary, both sides of transformations and ownership transfers, discriminating branches, before/after mutations, async schedule/start/settle/cancel points, cache/persistence/external-call boundaries, exception/fallback paths, invariants, and the terminal or observation checkpoint. Map each breakpoint to a concrete question plus the stack frames, locals, or expressions to inspect. Do not add redundant locations merely to inflate the count.
- Map a breakpoint to one or more causal boundaries. When one physical paused frame genuinely exposes multiple boundaries, keep one breakpoint and require a concrete
sharedBoundaryRationale; otherwise use distinct locations rather than a catch-all mapping. Treat the same normalized sourcelocationas one physical breakpoint regardless of condition: combine any conditions and merge its boundary and hypothesis mappings instead of duplicating entries or inflating the reported batch count. - On every debugger pause, inspect the planned state first. If the stack, dynamic dispatch, or concrete runtime type reveals more material locations, install the entire newly justified upstream/downstream batch before the next
continue; do not advance one breakpoint at a time through an already-visible causal interval. - Use validated non-pausing structured probes instead when pauses could hide a timing, concurrency, lifecycle, hot-path, or long-lived-stream failure. Keep every
debuggerStrategy.breakpointsentry at fixedkind: "pause". Treat a native debugger logpoint as formal evidence only when it is represented as a plan probe and emits through the same validated runtime adapter; otherwise it is supplemental. MarkdebuggerStrategy.modeasunavailableorunsafewith a concrete reason when native breakpoints cannot be installed. - Enumerate the full concrete candidate breakpoint batch even in
unavailableorunsafemode, but mark every candidatedeferred. Give every deferred entry anactivateWhenplus the matching structureddeferReason:tool-unavailable,observer-risk, orprivacy-risk. A dynamically unresolved site is not yet a breakpoint entry because every entry requires a concrete sourcepath:line; record it incoverage.residualAmbiguities, map its boundary and hypothesis to the nearest concrete upstream or downstream surrogate breakpoint, then add the full newly resolved batch and revalidate before continuing. Residual ambiguity never waives concrete breakpoint coverage. Never use “try the earlier breakpoint first,” low rank, or cheap reproduction as a deferral reason. - Treat pause-only breakpoints as supplemental evidence. They do not satisfy the all-occurrence event contract, and a breakpoint that did not pause cannot prove absence unless independently bracketed by complete structured evidence. Set
coverage.firstPassBreakpointBatchReviewedonly after the full initial batch and every explicit deferral have been reviewed.