systematic-debugging

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

Updated Aug 26, 2026
One-click install
npx skills add https://github.com/danieliudi/trackforge-os --skill systematic-debugging-danieliudi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/danieliudi/trackforge-os/tree/main/.cursor/skills/systematic-debugging
Command: npx skills add https://github.com/danieliudi/trackforge-os --skill systematic-debugging-danieliudi

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? When facing bugs, test failures, or unexpected behavior, the temptation to apply quick symptom fixes leads to thrashing, regressions, and wasted hours. This Skill enforces a disciplined investigation process that finds the actual root cause before any fix is attempted. ## Core Features & Use Cases - Four-Phase Process: Root cause investigation, pattern analysis, hypothesis testing, and implementation, each with concrete checklists and explicit stop conditions. - Supporting Techniques: Includes references for backward call-stack tracing, defense-in-depth validation across layers, and condition-based waiting to replace flaky arbitrary timeouts in tests. - Pressure Resistance: Red-flag lists and rationalization tables counter shortcuts taken under time pressure, authority pressure, or after repeated failed fixes, including a rule to question the architecture after three failed attempts. - Use Case: A test suite fails intermittently in CI. Instead of adding longer sleeps, follow Phase 1 to gather evidence across components, trace the bad value to its source, then fix it at the origin with a failing test proving the resolution. ## Quick Start Ask the AI to debug a failing test or production bug using the systematic-debugging skill and require root cause evidence before any fix is proposed.

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 errors and reproduce the failure, compare against working examples, form one hypothesis and test it minimally, then implement a single fix verified by a failing test. Never stack multiple fixes at once.

How do I fix flaky tests caused by timing issues?

Replace arbitrary setTimeout or sleep calls with condition-based waiting that polls for the actual state you need, such as an event count or a status value. The included reference shows this raised a test suite from 60% to 100% pass rate.

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

Stop and return to Phase 1 with the new information rather than adding more fixes. If three or more fixes have failed, treat it as an architectural problem and discuss the design 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 stops at the first test that creates the unwanted file or directory. Then trace the call chain backward to the original trigger.

When is it acceptable to skip root cause investigation?

Never, according to the skill. Even under production emergencies or time pressure, systematic investigation is faster than guess-and-check thrashing, and symptom fixes are treated as failures.