debugging

What it does and when to use it

Systematic debugging methodologies for hard bugs. Covers rubber ducking, code tracing, hypothesis testing, logging strategies. Use when stuck on bugs that resist quick fixes.

How it works

1. Rubber Ducking
2. Code Flow Tracing
3. Hypothesis Testing
4. Logging
5. Agent Investigation
6. Before Fixing
7. Related

---
name: debugging
description: Systematic debugging methodologies for hard bugs. Covers rubber ducking, code tracing, hypothesis testing, logging strategies. Use when stuck on bugs that resist quick fixes.
user-invocable: true
---

# Debugging Hard Bugs

## Rubber Ducking

Quote code snippets and explain what each chunk *should* do vs *actually* does. Don't assume—verbalize the logic. Discrepancies reveal bugs.

## Code Flow Tracing

Trace data from entry point to failure. At each transformation: what goes in, what comes out? Mark where expectations diverge.

**Failure-prone boundaries:** async, serialization, type coercion, null propagation, state mutations.

## Hypothesis Testing

1. List 3-5 possible causes
2. List 3-5 assumptions you're making
3. Test to eliminate possibilities
4. Repeat until one remains

**Don't** change code hoping it helps—that creates noise.

## Logging

Log at decision points and async boundaries, not everywhere.

**Workflow:**
1. Add targeted logs
2. Have user perform action and report output
3. Diagnose and fix
4. **After user confirms fix works:** remove all added logging

## Agent Investigation

For complex/unfamiliar code sections acting as a blackbox:

- Spawn an Explore agent to trace a specific code path and report back
- Run agents in background while continuing other investigation

**When stuck:** Spawn 2-3 senior-advisor agents in parallel with different perspectives (pragmatist, architect, skeptic).

**Avoid biasing agents:** Pass them relevant file paths and the observed behavior, but *not* your hypotheses or assumptions. Let them form independent conclusions.

## Before Fixing

- [ ] Identified exact failing line(s)?
- [ ] Understand *why* it fails?

If no, keep investigating.

## Related

- [Frontend Debugging](./frontend.md)

Versions

Identical content appears in 1 other GitHub folders. We show one copy with the highest score.

Database snapshot: 13.11.2026 · package version 0046359d77bc (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 90dev-loop-debugging-strategy
  Use when the user asks about debugging strategies, debugging methodologies, log analysis, debugging tools, root cause analysis, or systematic debugging approaches. Do NOT use for: performance profiling (dev-loop-performance-profiler), or code review (dev-loop-code-review).
• 100systematic-debugging
  Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
• 100systematic-debugging
  Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
• 100systematic-debugging
  Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
• 100systematic-debugging-engineering
  Engineering practice: Systematic debugging — Reproduce the fault, narrow it down, test one hypothesis at a time and fix the cause, so bugs stay fixed instead of moving around. Use in any language or framework whenever this practice applies, and when reviewing work that should follow it.
• 100systematic-debugging
  Debugging methodology, hypothesis testing, reading stack traces, isolating issues. Use when facing an unexpected bug, a flaky test, a production incident, or any situation where the cause isn't immediately obvious.