systematic-debugging

Diagnose bugs through a four-phase root cause investigation process before proposing fixes.

1|Updated Jun 15, 2026

Search Tags:#software engineering #debugging #troubleshooting #root cause analysis #test failures #hypothesis testing

Ready to run

npx skills add https://github.com/abdullah72005/skills --skill systematic-debugging-abdullah72005

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/abdullah72005/skills/tree/main/systematic-debugging/.claude/skills/systematic-debugging
Command: npx skills add https://github.com/abdullah72005/skills --skill systematic-debugging-abdullah72005

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Random fixes and guess-and-check patching waste time, mask underlying issues, and introduce new bugs. This Skill enforces a disciplined debugging methodology that finds the root cause before any fix is attempted. ## Core Features & Use Cases - Four-Phase Process: Root cause investigation, pattern analysis, hypothesis testing, and verified implementation, each gated before proceeding. - Multi-Component Evidence Gathering: Add diagnostic instrumentation at component boundaries to identify exactly which layer fails in pipelines like CI, build, and signing. - Architectural Escalation: After three failed fixes, stop and question the architecture instead of attempting a fourth patch. - Use Case: A test fails in production after a deploy. Instead of guessing, you reproduce the issue, trace the data flow backward through the call stack, form a single hypothesis, and verify one minimal fix with a failing test. ## Quick Start Use the systematic-debugging skill to investigate this failing test and find its root cause before suggesting any fix.

Frequently Asked Questions about systematic-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I debug a test failure systematically?▼

Start by reading the full error message and stack trace, then reproduce the failure consistently. Check recent changes via git diff, form a single hypothesis about the root cause, and test it with the smallest possible change before implementing a fix.

How to find root cause in multi-component systems?▼

Add diagnostic logging at each component boundary to capture what data enters and exits every layer. Run the system once to gather evidence showing which layer breaks, then investigate only that failing component instead of guessing.

When should I stop trying fixes and question the architecture?▼

Stop after three failed fix attempts. If each fix reveals a new problem in a different place or requires massive refactoring, the architecture itself is likely flawed and should be discussed before further patching.

Why do quick fixes cause more bugs?▼

Quick fixes address symptoms rather than root causes, so the underlying issue persists and resurfaces elsewhere. Bundling multiple changes at once also makes it impossible to isolate what worked, often introducing new defects.

Can I skip the debugging process for simple bugs?▼

No, simple bugs have root causes too, and the process is fast for simple issues. Skipping investigation under time pressure leads to thrashing, which is slower than systematic diagnosis.