home / skills / dmdorta1111 / jac-v1 / debugging

debugging skill

/.claude/skills/debugging

This skill guides systematic debugging to identify root causes before fixes, validate at every layer, and verify outcomes for reliable software.

npx playbooks add skill dmdorta1111/jac-v1 --skill debugging

Review the files below or copy the command above to add this skill to your agents.

Files (7)
SKILL.md
3.3 KB
---
name: Debugging
description: Systematic debugging framework ensuring root cause investigation before fixes. Includes four-phase debugging process, backward call stack tracing, multi-layer validation, and verification protocols. Use when encountering bugs, test failures, unexpected behavior, performance issues, or before claiming work complete. Prevents random fixes, masks over symptoms, and false completion claims.
version: 3.0.0
languages: all
---

# Debugging

Comprehensive debugging framework combining systematic investigation, root cause tracing, defense-in-depth validation, and verification protocols.

## Core Principle

**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST**

Random fixes waste time and create new bugs. Find the root cause, fix at source, validate at every layer, verify before claiming success.

## When to Use

**Always use for:** Test failures, bugs, unexpected behavior, performance issues, build failures, integration problems, before claiming work complete

**Especially when:** Under time pressure, "quick fix" seems obvious, tried multiple fixes, don't fully understand issue, about to claim success

## The Four Techniques

### 1. Systematic Debugging (`references/systematic-debugging.md`)

Four-phase framework ensuring proper investigation:
- Phase 1: Root Cause Investigation (read errors, reproduce, check changes, gather evidence)
- Phase 2: Pattern Analysis (find working examples, compare, identify differences)
- Phase 3: Hypothesis and Testing (form theory, test minimally, verify)
- Phase 4: Implementation (create test, fix once, verify)

**Key rule:** Complete each phase before proceeding. No fixes without Phase 1.

**Load when:** Any bug/issue requiring investigation and fix

### 2. Root Cause Tracing (`references/root-cause-tracing.md`)

Trace bugs backward through call stack to find original trigger.

**Technique:** When error appears deep in execution, trace backward level-by-level until finding source where invalid data originated. Fix at source, not at symptom.

**Includes:** `scripts/find-polluter.sh` for bisecting test pollution

**Load when:** Error deep in call stack, unclear where invalid data originated

### 3. Defense-in-Depth (`references/defense-in-depth.md`)

Validate at every layer data passes through. Make bugs impossible.

**Four layers:** Entry validation → Business logic → Environment guards → Debug instrumentation

**Load when:** After finding root cause, need to add comprehensive validation

### 4. Verification (`references/verification.md`)

Run verification commands and confirm output before claiming success.

**Iron law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

Run the command. Read the output. Then claim the result.

**Load when:** About to claim work complete, fixed, or passing

## Quick Reference

```
Bug → systematic-debugging.md (Phase 1-4)
  Error deep in stack? → root-cause-tracing.md (trace backward)
  Found root cause? → defense-in-depth.md (add layers)
  About to claim success? → verification.md (verify first)
```

## Red Flags

Stop and follow process if thinking:
- "Quick fix for now, investigate later"
- "Just try changing X and see if it works"
- "It's probably X, let me fix that"
- "Should work now" / "Seems fixed"
- "Tests pass, we're done"

**All mean:** Return to systematic process.

Overview

This skill provides a systematic debugging framework that enforces root-cause investigation before any fix. It combines a four-phase debugging process, backward call-stack tracing, multi-layer validation, and strict verification protocols to prevent symptom fixes and false completion claims.

How this skill works

Start by reproducing the issue and collecting evidence, then analyze patterns and form minimal hypotheses to test. If an error is deep in the stack, trace backward level-by-level to locate the original polluter and fix the source. After identifying the root cause, add validation at each layer and run fresh verification commands to confirm success before declaring the problem resolved.

When to use it

  • When tests fail or CI reports regressions
  • When encountering bugs or unexpected behavior in production or development
  • For performance problems or intermittent failures
  • Before claiming work complete or merging changes
  • When a quick fix is tempting or multiple fixes have already failed

Best practices

  • Never apply fixes before a root cause investigation is complete
  • Reproduce the issue deterministically and collect relevant logs and inputs
  • Form small, testable hypotheses and run minimal experiments
  • Trace errors backward through the call stack to fix the origin, not the symptom
  • Add defense-in-depth: entry validation, business logic guards, environment checks, and debug instrumentation
  • Always run fresh verification commands and read their output before declaring success

Example use cases

  • A failing integration test that passes locally — reproduce in CI, trace call stack to find environment polluter, add guards, verify CI output
  • Intermittent performance regression — capture profiles, compare working baselines, hypothesize a change, test minimally, fix hotspot at its source
  • A deep error raised in a downstream library — trace upstream inputs to locate where invalid data was introduced and correct the producer
  • Pre-merge checklist — run verification commands after fixes and include evidence before marking the task done

FAQ

What if I can’t reproduce the bug locally?

Collect logs, environment details, and inputs from the failing environment; use bisecting or targeted instrumentation to narrow where behavior diverges and then reproduce a minimal case.

How do I decide where to add validation layers?

Add checks at every boundary data crosses: at input/entry points, in business logic, in environment assumptions, and expose debug instrumentation to catch future regressions.