Skill v1.0.1
currentAutomated scan100/1003 files
version: "1.0.1" name: debug description: "Systematic debugging with hypothesis-driven investigation. Use when something is broken, tests are failing, unexpected behavior occurs, or errors need investigation. Triggers on: 'this is broken', 'debug', 'why is this failing', 'unexpected error', 'not working', 'bug', 'fix this issue', 'investigate', 'tests failing', 'trace the error', 'use debug mode'. Full access mode - can run commands, add logging, and fix issues." allowed-tools: [Read, Edit, Write, Bash, Grep, Glob, LSP]
Debug Mode
Systematic bug investigation and resolution.
Core Approach
"Don't guess. Form hypotheses. Test them."
The 4-Phase Process
Phase 1: Assessment 🔍
Goal: Understand and reproduce
- What is the expected behavior?
- What is the actual behavior?
- Can you reliably reproduce?
- What changed recently?
Key Questions:
- When did this start happening?
- Does it happen consistently or intermittently?
- What are the exact inputs that trigger it?
- What error messages or symptoms appear?
Building a Feedback Loop
This is the most important step. If you have a fast, deterministic, agent-runnable pass/fail signal, you will find the cause. If you don't, no amount of code-staring will save you. Spend disproportionate effort here.
Techniques — try in roughly this order:
- Failing test at whatever seam reaches the bug (unit, integration, e2e)
- Curl / HTTP script against a running dev server
- CLI invocation with fixture input, diffing stdout against known-good output
- Headless browser script (Playwright/Puppeteer) — drives UI, asserts on DOM/console
- Replay captured trace — save a real request/payload to disk, replay through the code path
- Throwaway harness — minimal subset of system that exercises the bug path
- Property/fuzz loop — if "sometimes wrong output", run 1000 random inputs
- Bisection harness — automate
git bisect runbetween known-good and known-bad - Differential loop — run same input through old vs new version, diff outputs
Iterate on the loop: Can you make it faster? Sharper signal? More deterministic?
If you cannot build a loop: Stop and say so. List what you tried. Ask for: captured artifacts (logs, HAR file), environment access, or permission to add temporary instrumentation.
Phase 2: Investigation 🔬
Goal: Isolate and trace
- Trace execution from entry point
- Identify where expected diverges from actual
- Form hypotheses about root cause
- Test hypotheses systematically
Techniques:
- Add strategic logging/prints
- Use debugger breakpoints
- Simplify inputs to minimal reproduction
- Check boundary conditions
Phase 3: Resolution 🔧
Goal: Fix minimally and verify
- Implement the smallest fix that addresses root cause
- Don't fix symptoms, fix the disease
- Add regression test
- Verify fix doesn't break other things
If fix doesn't work:
- Count: How many fixes attempted?
- If < 3: Return to Phase 1, re-analyze with new information
- If ≥ 3: STOP. Question your understanding of the system.
Phase 4: Quality ✅
Goal: Prevent recurrence
- Add test covering the bug
- Document if the cause was non-obvious
- Consider if similar bugs exist elsewhere
- Clean up debug code
Debugging Checklist
-[ ] **Reproduced**: Can trigger bug consistently-[ ] **Isolated**: Know which component is failing-[ ] **Root Cause**: Understand WHY it fails-[ ] **Fixed**: Minimal change addresses cause-[ ] **Tested**: Regression test added-[ ] **Clean**: Debug code removed
Hypothesis Template
For each hypothesis, record: Hypothesis (what's wrong) → Test (how to verify) → Result → Conclusion (confirmed/rejected/needs more info).
Common Root Causes
| Symptom | Often Caused By | |
|---|---|---|
| Works locally, fails in CI | Environment differences, missing deps | |
| Intermittent failure | Race condition, timing, external dependency | |
| Wrong output | Logic error, wrong variable, off-by-one | |
| Crash/exception | Null/None access, type mismatch, missing data | |
| Performance issue | N+1 queries, missing index, memory leak |
Rationalization Prevention
| Excuse | Reality | Required Action | |
|---|---|---|---|
| "The fix is obvious" | Obvious fixes mask root causes | Form a hypothesis and verify before changing code | |
| "It's probably X" | "Probably" isn't evidence | Test the hypothesis — name it, design a test, run it | |
| "This is too simple to debug formally" | Simple bugs waste the most time undiagnosed | Follow Phase 1 — reproduce, isolate, then fix | |
| "Logs look clean" | You didn't add targeted logging | Add debug logging at the suspected point | |
| "I've tried 3 things, might as well try a 4th" | Stacking guesses compounds confusion | STOP. Return to Phase 1. Re-analyze with new info | |
| "It works now" | If you don't know why, it will break again | Explain WHY it works and what changed |
Red Flags - STOP and Re-Assess
If you catch yourself skipping reproduction ("I know what's wrong") or testing multiple hypotheses at once — STOP. Return to Phase 1.
Debug Report Format
## Debug Report### Bug Summary-**Expected**: [what should happen]-**Actual**: [what happens instead]-**Severity**: [critical/high/medium/low]### Reproduction1.[Step to reproduce]2.[Step to reproduce]3.[Observe bug]**Minimal reproduction**: [simplest case that triggers bug]### Investigation| Hypothesis | Test | Result || ---------- | -------------- | -------------------------- || [theory] | [what I tried] | ✅ Confirmed / ❌ Rejected |### Root Cause[What's actually wrong and why]### Fix Applied-**File**: `path/to/file.py`-**Change**: [what was modified]-**Why**: [how this fixes the root cause]### Verification-[ ] Bug no longer reproduces-[ ] Existing tests pass-[ ] Regression test added: `test_name`-[ ] No debug code left behind### Prevention[How to prevent similar bugs in the future]