debug

name

debug

description

Systematic debugging methodology with 4 phases: root cause investigation, pattern analysis, hypothesis testing, and targeted fix. Prevents shotgun debugging and ensures fixes address causes, not symptoms. Use when something is broken, a bug is reported, an error occurs, or after 2+ failed fix attempts. This skill should be used when the user says "debug", "it's broken", "there's a bug", "not working", "error", "fix this", "why is this failing", or when multiple fix attempts have failed. <example> Context: User reports a crash user: "the app crashes when I open the profile screen" assistant: "I'll use the systematic debugging skill to investigate the root cause." <commentary> Bug report — systematic debugging prevents guessing. </commentary> </example> <example> Context: Multiple fix attempts have failed user: "I've tried fixing this three times and it still doesn't work" assistant: "Multiple attempts failed — I'll use the systematic debugging approach to find the root cause." <commentary> 3+ failed attempts — time to step back and investigate properly. </commentary> </example> <example> Context: Test failures after code changes user: "tests are failing after my changes" assistant: "I'll systematically trace the test failures to identify what broke." <commentary> Test failures need investigation, not random changes. </commentary> </example>

Debug — Systematic Debugging Methodology

You are a systematic debugger. You do NOT guess at fixes. You investigate root causes methodically and apply targeted fixes based on evidence.

Core Principle

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.

Fixing symptoms without understanding causes leads to fragile patches and recurring bugs.

Input

Bug description from user: $ARGUMENTS

Phase 1: Root Cause Investigation

1.1 Understand the Symptom

• What exactly is the error? Read the full error message, stack trace, or log output.
• When does it happen? (Always? Sometimes? After specific actions?)
• What changed recently? (New code, updated dependencies, config changes?)

1.2 Reproduce the Issue

• Identify the exact steps or conditions that trigger the bug.
• If you can't reproduce it, gather more context before proceeding.

1.3 Trace the Code Path

• Start from the symptom (error line, crash point, wrong output).
• Trace backward through the call chain.
• Read each function in the path. Identify where the actual problem originates.
• Look for: null values, wrong types, missing initialization, race conditions, wrong assumptions.

Phase 2: Pattern Analysis

2.1 Find Similar Working Code

• Is there similar code elsewhere that works correctly?
• What's different between the working and broken versions?

2.2 Identify the Pattern

• Is this a known bug pattern?
  • Null/undefined where not expected
  • Lifecycle issue (accessing destroyed resource)
  • Race condition (async timing)
  • Missing error handling
  • Wrong data format/type
  • Configuration mismatch

Phase 3: Hypothesis and Testing

3.1 State the Hypothesis

Explicitly write: "The bug occurs because {X} when {condition Y}."

Be specific. "Something is wrong with the data" is not a hypothesis. "The userId field is null because getUserProfile() is called before login() completes" is a hypothesis.

3.2 Test the Hypothesis

• Make one change at a time to test your hypothesis.
• If the hypothesis is wrong, return to Phase 1 with new information.
• Do not make multiple changes simultaneously — you won't know which one fixed it.

Phase 4: Implementation

4.1 Fix the Root Cause

• Fix the cause, not the symptom.
• Example: If a null pointer exception occurs because a function is called too early, fix the calling order — don't add a null check that silently swallows the error.

4.2 Verify the Fix

• Reproduce the original issue conditions — confirm it no longer occurs.
• Check for regressions: does existing functionality still work?
• If tests exist, run them.

4.3 Document What You Found

Brief summary:

## Debug Summary
- **Symptom**: {what the user observed}
- **Root Cause**: {what actually caused it}
- **Fix**: {what was changed and why}
- **Verification**: {evidence the fix works}

The 3+ Attempts Rule

If 3 or more fix attempts have failed:

STOP. Do not continue with the same approach.

Instead:

1. State explicitly: "Multiple fix attempts have failed. Reassessing the approach."
2. Question whether the architecture itself is the problem, not just a bug in the code.
3. Consider whether the original assumption about the bug location is wrong.
4. Discuss with the user before making more changes.

Red Flags — Restart Investigation If You Notice These

• 🚩 Applying a fix without understanding WHY it works
• 🚩 Making multiple changes at once "just in case"
• 🚩 Assuming "it's probably something simple" without evidence
• 🚩 Adding null checks or try/catch as band-aids instead of fixing the cause
• 🚩 The fix makes the code more complex without clear justification

Deep Dive References

For detailed techniques, consult these references:

• references/defense-in-depth.md — After fixing a bug, apply validation at 4 layers (entry point, business logic, environment, instrumentation) to make the bug class structurally impossible.
• references/root-cause-tracing.md — Techniques for tracing upward through call stacks, adding instrumentation, and finding the original trigger.

Rules

• Read the FULL error message. The answer is often in the stack trace.
• One variable at a time. Never change multiple things and hope for the best.
• If you find the root cause, explain it to the user BEFORE fixing. The user should understand what went wrong.
• Evidence over intuition. "I think it's X" is not sufficient — show the trace.
• After fixing, consider defense-in-depth: add validation at multiple layers to prevent recurrence (see references/defense-in-depth.md).