debugging-disciplinelisted

# Debugging Discipline Condensed from GSD v1 (audit 2026-04-28). Tier-2. fetch when actively debugging, not preloaded. ## Conversation context (prior) **Prior conversation**: skill triggers when actively debugging an issue. The prior turn has: an error message OR an "expected X but got Y" report OR multiple failed fix attempts. Read those, treat user as reporter (knows symptom) not investigator (does not know cause). Don't ask user what's broken. that's the investigator's job. ## Example (cognitive-bias antidote in action) ``` User: "The chat reply tool keeps failing. I've checked the auth token, restarted the daemon, rebuilt the plugin. Nothing works." Bad response (anchoring trap): "Let me check the auth token configuration..." (user already ruled out) Good response (3-hypothesis generation): 3 hypotheses BEFORE investigating any: H1: plugin orphan procs (PPID=1) holding the connection H2: runtime version mismatch H3: a getUpdates 409 (multi-poller conflict) Cheapest disconfirming test: pgrep for orphan bun procs. Run that first. Result will rule out H1 in 5 sec. ``` ## Procedure (thinking step by step) 1. **Treat user as reporter**. don't ask "what's causing it"; gather: expected vs actual, error message, when-it-started, what-was-changed-recently 2. **Establish a minimal reproduction first**. a bug you can't trigger on demand can't be confirmed fixed. nail the smallest reliable repro before theorizing. if it only happens intermittently, that IS the