# Use Debug > Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - Skill: `tomevault-io/use-debug` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/use-debug` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/use-debug/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/use-debug --- Random fixes waste time and create new bugs. Quick patches mask underlying issues. **Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure. # The Iron Law ``` NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST ``` If you haven't completed Phase 1, you cannot propose fixes. # The Four Phases ## Phase 1: Root Cause Investigation **BEFORE attempting ANY fix:** 1. **Read Error Messages Carefully** - Read stack traces completely - Note line numbers, file paths, error codes - They often contain the exact solution 2. **Reproduce Consistently** - Can you trigger it reliably? - Exact steps? Every time? - If not reproducible → gather more data, don't guess 3. **Check Recent Changes** - Git diff, recent commits - New dependencies, config changes - Environmental differences 4. **Gather Evidence in Multi-Component Systems** For each component boundary: - Log what data enters component - Log what data exits component - Verify environment/config propagation - Check state at each layer Run once to gather evidence showing WHERE it breaks THEN analyze evidence to identify failing component 5. **Trace Data Flow** - Where does bad value originate? - What called this with bad value? - Keep tracing up until you find the source - Fix at source, not at symptom ## Phase 2: Pattern Analysis 1. **Find Working Examples** - Locate similar working code in same codebase - What works that's similar to what's broken? 2. **Compare Against References** - If implementing pattern, read reference implementation COMPLETELY - Don't skim - understand the pattern fully 3. **Identify Differences** - What's different between working and broken? - Don't assume "that can't matter" ## Phase 3: Hypothesis and Testing 1. **Form Single Hypothesis** - State clearly: "I think X is the root cause because Y" - Be specific, not vague 2. **Test Minimally** - SMALLEST possible change to test hypothesis - One variable at a time - Don't fix multiple things at once 3. **Verify Before Continuing** - Did it work? Yes → Phase 4 - Didn't work? Form NEW hypothesis - DON'T add more fixes on top ## Phase 4: Implementation 1. **Create Failing Test Case** - Use the autonome:use-tdd skill - Simplest possible reproduction - MUST have before fixing 2. **Implement Single Fix** - Address the root cause identified - ONE change at a time - No "while I'm here" improvements 3. **Verify Fix** - Test passes now? - No other tests broken? - Issue actually resolved? 4. **If Fix Doesn't Work** - STOP - Count: How many fixes have you tried? - If < 3: Return to Phase 1, re-analyze - **If ≥ 3: STOP and question the architecture** - DON'T attempt Fix #4 without discussion 5. **If 3+ Fixes Failed: Question Architecture** Pattern indicating architectural problem: - Each fix reveals new shared state/coupling in different place - Fixes require "massive refactoring" - Each fix creates new symptoms elsewhere **STOP and question fundamentals:** - Is this pattern fundamentally sound? - Should we refactor architecture vs. continue fixing symptoms? Discuss before attempting more fixes. # Red Flags - STOP If you catch yourself thinking: - "Quick fix for now, investigate later" - "Just try changing X and see if it works" - "Add multiple changes, run tests" - "Skip the test, I'll manually verify" - "It's probably X, let me fix that" - "I don't fully understand but this might work" - "Here are the main problems: [lists fixes without investigation]" - Proposing solutions before tracing data flow - **"One more fix attempt" (when already tried 2+)** - **Each fix reveals new problem in different place** **ALL of these mean: STOP. Return to Phase 1.** **If 3+ fixes failed:** Question the architecture. # Common Rationalizations | Excuse | Reality | |--------|---------| | "Issue is simple, don't need process" | Simple issues have root causes too. | | "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check. | | "Just try this first, then investigate" | First fix sets the pattern. Do it right from start. | | "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. | | "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. | | "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. | # Supporting Techniques Available in this directory: - **root-cause-tracing.md** - Trace bugs backward through call stack - **defense-in-depth.md** - Add validation at multiple layers - **condition-based-waiting.md** - Replace arbitrary timeouts **Related skills:** - **autonome:use-tdd** - For creating failing test case - **autonome:use-verify** - Verify fix worked --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/mtthsnc) — claim your Tome and manage your conversions.