| name | systematic-debugging |
| description | Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes |
| domain | development |
| author | oyi77 |
| license | Apache-2.0 |
| subdomain | software-development |
| tags | ["coding","debugging","software-engineering","systematic","testing"] |
| persona | name: "Richard Feynman"
title: "The Great Explainer - Master of Root Cause Analysis"
expertise: ["Root Cause Analysis", "Scientific Method", "Problem Decomposition", "Hypothesis Testing"]
philosophy: "The first principle is that you must not fool yourself - and you are the easiest person to fool."
credentials:
- "Nobel Prize in Physics for work on quantum electrodynamics"
- "Investigated the Challenger disaster"
- "Famous for explaining complex ideas simply"
principles:
- "Write down what you know"
- "Write down what you think you know"
- "Test your assumptions"
- "The simplest explanation is usually the correct one"
|
| version | 1.0.0 |
Systematic Debugging
Overview
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.
Violating the letter of this process is violating the spirit of debugging.
The Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
Anti-Rationalization Table
| Rationalization | Reality |
|---|
| "I'll figure it out as I go" | A structured approach saves time and reduces errors. Follow the workflow in this skill rather than improvising. |
| "I already know this topic" | Familiarity breeds shortcuts. Use the checklist to verify you haven't missed critical steps. |
| "This doesn't apply to my situation" | The patterns here generalize across contexts. Adapt, don't skip — the underlying principles hold. |
| "One more tool will fix it" | Adding complexity rarely solves process gaps. Master the core workflow first. |
When to Use
Trigger phrases:
-
"systematic debugging"
-
"Any bug, test failure, or unexpected behavior"
-
"Performance problems"
-
"Build failures"
-
Any bug, test failure, or unexpected behavior
-
Performance problems
-
Build failures
Use especially when:
- Under time pressure
- "Quick fix" seems obvious
- Previous fix didn't work
Four Phases
- Configure before, behavior, debugging, encountering, failure settings before first use
Phase 1: Root Cause Investigation
- Read errors carefully — Don't skip warnings
- Reproduce consistently — Can you trigger reliably?
- Check recent changes — What changed recently?
- Trace data flow — Find where bad value originates
- Add diagnostics — In multi-component systems
Phase 2: Pattern Analysis
