debugging

name	debugging
description	Hypothesis-driven debugging with systematic investigation. Identifies root causes, creates minimal reproductions, and implements fixes. Use when investigating errors, bugs, crashes, or unexpected behavior.

Debugging

Systematic debugging using hypothesis testing and root cause analysis.

When to Use

• Error investigation (exceptions, crashes)
• Unexpected behavior diagnosis
• Performance issue root cause
• Integration/dependency failures

MCP Workflow

# 1. Get code at error location
serena.find_symbol(name_path="ErrorClass/method", include_body=True)

# 2. Trace call chain
serena.find_referencing_symbols(name_path="ErrorClass/method")

# 3. Search for similar patterns
serena.search_for_pattern("null.*check|error.*handling", relative_path="src/")

# 4. Check past similar issues
claude-mem.search(query="<error-type>", project="<project>")

# 5. Framework error handling
context7.get-library-docs("<framework>", topic="exception handling")

Workflow

1. Observe

- Error message and stack trace
- Steps to reproduce
- When did it start? (recent changes?)
- Scope (one user? all?)

2. Hypothesize

Based on: [observation]
Hypothesis: [proposed cause]
Test: [how to verify]

3. Test

serena.find_symbol("SuspectedClass/method", include_body=True)
serena.find_referencing_symbols("SuspectedCause")
# Log analysis, local reproduction

4. Fix

1. Write failing test that reproduces bug
2. Implement minimal fix
3. Verify test passes
4. Run full test suite

5. Prevent

- Add edge case tests
- Improve validation
- Update documentation

Common Patterns

Null/Undefined

Symptoms: NullPointerException, "undefined is not a function" Investigate:

• Find where null originates
• Trace back through call chain
• Check data presence assumptions

Race Condition

Symptoms: Intermittent, works in debug mode Red flags:

• Shared mutable state
• Missing synchronization
• Execution order assumptions

Data Inconsistency

Investigate:

• Trace data flow source to error
• Check transformation logic
• Verify cache invalidation

Investigation Techniques

Git Bisect

git bisect start
git bisect bad
git bisect good <commit>
# Test middle commit, mark good/bad
git bisect reset

Stack Trace Analysis

Start at bottom (entry point)
Move up to error line
Examine code at that line
Check what could be null/invalid

Divide and Conquer

A -> B -> C -> D (output wrong)
Check B: correct? -> problem in C or D
        wrong?   -> problem in A or B

Output Format

## Bug: [Title]

### Symptoms
- Error: [message]
- Location: `file:line`

### Investigation
**Hypothesis 1:** [description]
- Test: [method]
- Result: Confirmed / Ruled Out

### Root Cause
[Identified cause] at `file:line`

### Fix
[Description]

### Prevention
- [ ] Test added
- [ ] Similar patterns checked

Checklist

• Can reproduce consistently
• Stack trace analyzed
• Root cause identified (not just symptom)
• Failing test written
• Fix implemented
• Full test suite passes