systematic-debugging

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

Updated Jan 16, 2026
One-click install
npx skills add https://github.com/dudqks0319-cpu/antigravity-skills --skill systematic-debugging-dudqks0319-cpu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/dudqks0319-cpu/antigravity-skills/tree/main/systematic-debugging
Command: npx skills add https://github.com/dudqks0319-cpu/antigravity-skills --skill systematic-debugging-dudqks0319-cpu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Random fixes and quick patches waste time, mask underlying issues, and introduce new bugs. This Skill enforces a disciplined debugging methodology that finds the actual root cause before any fix is attempted, even under time pressure or social pressure to take shortcuts. ## Core Features & Use Cases - Four-Phase Process: Structured workflow covering root cause investigation, pattern analysis, hypothesis testing, and verified implementation. - Supporting Techniques: Includes root-cause tracing through call stacks, defense-in-depth validation at multiple layers, and condition-based waiting to replace flaky arbitrary timeouts in tests. - Pressure Resistance: Explicit anti-patterns, red flags, and rationalization tables that stop shortcut behavior during emergencies, plus a bisection script to find which test pollutes shared state. - Use Case: When a production test fails intermittently, follow Phase 1 to reproduce and gather evidence, trace the bad value to its source, form a single hypothesis, and verify the fix with a failing test case instead of stacking sleep() calls. ## 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 find the root cause of a bug instead of fixing symptoms?▼

Follow a four-phase process: investigate the root cause by reading errors and reproducing consistently, analyze patterns against working examples, form and test a single hypothesis, then implement one verified fix. Never propose fixes before completing the investigation phase.

How to fix flaky tests caused by arbitrary timeouts?▼

Replace setTimeout and sleep calls with condition-based waiting that polls for the actual condition you care about, such as an event appearing or state changing. Poll every 10ms with a clear timeout error, which eliminated flakiness and ran 40% faster in real sessions.

What should I do when my first fix doesn't work?▼

Stop and return to root cause investigation with the new information rather than stacking more fixes. If three or more fixes have failed, question the underlying architecture and discuss with your team before attempting another fix.

How do I find which test is polluting shared state?▼

Use the included find-polluter.sh bisection script, which runs test files one by one and checks whether a specified file or directory appears after each run. It stops at the first polluting test and reports the file for investigation.

When is it acceptable to skip systematic debugging for simple bugs?▼

Never. Simple bugs have root causes too, and the process is fast for simple issues. Skipping investigation under time pressure or for 'obvious' fixes leads to symptom patches that mask the real problem and create new bugs.