debug
Use when encountering any bug, test failure, unexpected behavior, or error - before proposing fixes. Use especially when previous fix attempts have failed.
Works with
--- name: debug description: Use when encountering any bug, test failure, unexpected behavior, or error - before proposing fixes. Use especially when previous fix attempts have failed. license: MIT --- # /debug - Systematic Debugging Investigate and fix the bug using 4-phase methodology. **Target:** $ARGUMENTS ## The 4 Phases ``` Phase 1 Phase 2 Phase 3 Phase 4 ┌────────┐ ┌─────────┐ ┌───────────┐ ┌───────────┐ │ GATHER │─►│ ANALYZE │─►│ FORMULATE │─►│ IMPLEMENT │ │Evidence│ │ Patterns│ │ Hypothesis│ │ & Prove │ └────────┘ └─────────┘ └───────────┘ └───────────┘ ``` ## Workflow ### Phase 1: GATHER EVIDENCE 1. **Read the error completely:** - Full error message - Stack trace - File and line numbers 2. **Reproduce the bug:** - Document exact steps - Confirm reproducible 3. **Check recent changes:** ```bash git log --oneline -10 git diff HEAD~3 ``` 4. **Search for related code:** ```bash grep -r "error message" . ``` **Output:** ```markdown ## Evidence Error: [full message] Location: [file:line] Stack trace: [trace] Reproduction: 1. [step] 2. [step] 3. Error occurs Recent changes: - [commit]: [relevant change] ``` **BLOCKED** until evidence collected. ### Phase 2: ANALYZE PATTERNS 1. **Trace execution path:** - Entry point → Error location - Data flow through system 2. **Compare with working code:** - Find similar code that works - Identify differences 3. **Identify patterns:** - Consistent or intermittent? - Data-dependent? - Timing-dependent? **Output:** ```markdown ## Analysis Execution: [entry] → [fn1] → [fn2] → [error] Working vs Broken: | Aspect | Working | Broken | |--------|---------|--------| | [X] | [value] | [value]| Patterns: - [pattern 1] - [pattern 2] ``` **BLOCKED** until patterns identified. ### Phase 3: FORMULATE HYPOTHESIS 1. **Generate hypotheses:** - Multiple, not just one - Based on evidence 2. **Rank by probability:** - Which fits all evidence? - Simplest explanation? 3. **Design tests:** - How to prove/disprove each? **Output:** ```markdown ## Hypotheses H1: [most likely] (80%) Evidence for: [...] Test: [how to verify] H2: [second option] (15%) Test: [how to verify] ``` **BLOCKED** until hypotheses formulated. ### Phase 4: IMPLEMENT & PROVE 1. **Test primary hypothesis:** - Execute minimal test - Capture output 2. **If confirmed:** - Write test that reproduces bug - Implement fix - Verify test passes 3. **If rejected:** - Test next hypothesis 4. **Create checkpoint:** ```bash git add -A && git commit -m "fix: [description]" git tag checkpoint/bugfix-[name] ``` **Output:** ```markdown ## Resolution Hypothesis: H1 - CONFIRMED ✓ Root Cause: [Clear explanation] Fix: ```diff - [old code] + [new code] ``` Verification: - Reproduction test: PASS ✓ - Existing tests: PASS ✓ ``` ## Three-Strike Rule After 3 failed hypotheses: ``` ⚠️ THREE STRIKES Re-evaluating understanding of the system. Looking for deeper architectural issues. ``` ## Output ``` ──── /debug ──── Bug: [description] Phase 1: Evidence gathered ✓ Phase 2: Patterns identified ✓ Phase 3: Hypotheses formulated ✓ Phase 4: Fix implemented ✓ ──── Debug Summary ──── Root cause: [explanation] Fix: [what changed] Checkpoint: checkpoint/bugfix-[name] Confidence: HIGH ``` ## Anti-Rationalization | Excuse | Reality | |--------|---------| | "I know the fix already" | You have a hypothesis, not a fix. Follow the phases. | | "It's obviously this line" | Obvious fixes that skip investigation create new bugs. | | "I'll just try this quickly" | Quick fixes without understanding cause regressions. | | "Too slow to gather evidence" | Debugging without evidence takes 3x longer. | | "The error message tells me everything" | Error messages are symptoms, not root causes. | ## Rules 1. **Never guess** - Evidence first 2. **Never fix without understanding** - Know the root cause 3. **Never skip phases** - Each prevents blind spots 4. **Always checkpoint** - Fixes must be reversible
More Debugging skills
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
explore-code
lllllllama/rigorpilot-skills
Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline reproduction, conservative debugging, environment setup, verified contribution claims, or default repository analysis.
safe-debug
lllllllama/rigorpilot-skills
Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization.

