systematic-debugging

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

1|Updated Mar 2, 2026
One-click install
npx skills add https://github.com/mst-software-vn/mst-checkscam --skill systematic-debugging-mst-software-vn
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/mst-software-vn/mst-checkscam/tree/main/.claude/skills/systematic-debugging
Command: npx skills add https://github.com/mst-software-vn/mst-checkscam --skill systematic-debugging-mst-software-vn

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

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 apply a quick patch. ## Core Features & Use Cases - Four-Phase Process: Root Cause Investigation, Pattern Analysis, Hypothesis Testing, and Implementation, with mandatory completion of each phase before proceeding. - 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, exhaustion, or authority pressure. - Use Case: A test fails intermittently in CI. Instead of adding sleep delays, you trace the data flow backward, find the race condition at its source, write a failing test, and fix it once with validation at every layer. ## Quick Start Use the systematic-debugging skill to investigate this test failure 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 instead of guessing?▼

Follow the four phases: read error messages and reproduce the issue consistently, compare against working examples, form a single hypothesis and test it minimally, then implement one fix with a failing test case. Never attempt fixes before completing root cause investigation.

How to fix flaky tests caused by race conditions?▼

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual state you need, such as waiting for a specific event count. The included TypeScript helpers waitForEvent and waitForEventCount poll every 10ms with a configurable timeout.

Should I apply a quick fix during a production emergency?▼

The skill mandates root cause investigation even under time pressure, arguing systematic debugging is faster than guess-and-check thrashing. Quick symptom fixes set a bad pattern and typically cause rework and new bugs.

What should I do when my first fix does not work?▼

Stop and return to Phase 1 with the new information rather than stacking more fixes. If three or more fixes have failed, treat it as an architectural problem and discuss the fundamental design 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, stopping at the first polluting test.

When is a single validation check not enough after fixing a bug?▼

Single-point validation can be bypassed by other code paths, mocks, or refactoring. The defense-in-depth technique adds validation at four layers: entry point, business logic, environment guards, and debug instrumentation, making the bug structurally impossible.