/debugger

name: debugger
description: "Systematic debugging methodology for diagnosing failures and root cause analysis. Triggers on: 2+ failed fix attempts, 'ultradebug', 'uld', debugging in circles, complex system failures, intermittent bugs."

Debugger Skill

Systematic debugging methodology for diagnosing failures and root cause analysis.

When to Apply This Guidance

• 2+ failed fix attempts on the same issue
• Debugging that's gone in circles
• Complex system behavior you don't understand
• Multi-system integration problems
• Intermittent failures (Heisenbugs)

Structured Analysis Framework

Step 1: Restate the Problem

Before investigating, articulate:

• What is the actual vs expected behavior?
• What assumptions might be wrong?
• What could cause the specific symptoms described?
• Are there hidden dependencies or side effects?

Step 2: Generate Ranked Hypotheses

Always generate multiple hypotheses, ranked by likelihood:

**Most Likely:**

• Evidence: What supports this theory?
• Test: How to verify quickly?

**Possible:**

• Evidence: What partially supports this?
• Test: How to confirm or eliminate?

**Unlikely but worth checking:**

• Evidence: Limited, but possible
• Test: Quick check to rule out

Step 3: Systematic Verification

Test hypotheses in order. For each: 1. State what you're testing 2. Describe the expected outcome if hypothesis is correct 3. Execute the test 4. Document actual results 5. Update hypothesis ranking based on findings

Reasoning Principles

1. **Challenge assumptions** - The "obvious" cause is often wrong after 2+ failures 2. **Follow the data** - What do logs/errors actually say vs what's assumed? 3. **Consider timing** - Race conditions, async issues, initialization order 4. **Check boundaries** - Module interfaces, API contracts, type conversions 5. **Question the environment** - Config, dependencies, network, state

Decision Framework

When choosing between approaches:

| Factor | Weight | Considerations | |--------|--------|----------------| | Correctness | Critical | Does it actually solve the problem? | | Simplicity | High | Prefer boring solutions over clever ones | | Leverage | High | Use existing patterns/libraries/code | | Developer Experience | Medium | How hard is it to debug/maintain? | | Performance | Low* | *Unless performance IS the problem |

Effort Estimation

Tag recommendations by effort:

| Tag | Meaning | Example | |-----|---------|---------| | **[Quick]** | <30 min | Add logging, check config | | **[Short]** | 30min-2hr | Refactor function, add test | | **[Medium]** | 2hr-1day | New component, integration | | **[Large]** | >1 day | Architecture change |

Common Failure Patterns

| Pattern | Signal | Investigation Focus | |---------|--------|---------------------| | Fix-break cycle | Each fix causes new problem | Root cause analysis - treating symptoms not cause | | Confusion | "I don't understand why X happens" | Add logging, trace execution path | | Tradeoff paralysis | Multiple valid approaches | Use decision framework above | | Integration hell | System A + B don't work together | Interface contracts, data formats | | Heisenbug | Works sometimes, fails randomly | Timing, state, race conditions |

Traps to Avoid

• **Premature fixing** - Understand before changing
• **Single hypothesis** - Always consider alternatives
• **Assuming correctness** - Verify each component independently
• **Ignoring evidence** - If data contradicts theory, update theory
• **Scope creep** - Fix the bug, not everything around it

Output Template

When debugging, structure findings as:

## Problem Understanding
{Restate in own words. Challenge framing if wrong.}

## Hypotheses (Ranked)
1. Most Likely: {hypothesis} - Evidence: {support} - Test: {verification}
2. Possible: {hypothesis} - Evidence: {support} - Test: {verification}
3. Unlikely: {hypothesis} - Evidence: {limited} - Test: {quick check}

## Recommended Approach
{Specific next steps. Be prescriptive.}

## Traps to Avoid
{What NOT to do for this specific problem.}