systematic-debugging

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

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/assafmanor/waypoint --skill systematic-debugging-assafmanor
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/assafmanor/waypoint/tree/main/.claude/skills/systematic-debugging
Command: npx skills add https://github.com/assafmanor/waypoint --skill systematic-debugging-assafmanor

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 wasted hours of guess-and-check thrashing. This Skill enforces a disciplined four-phase debugging methodology 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, 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. - Failure Recovery Rules: After three failed fix attempts, the process mandates stopping to question the underlying architecture rather than attempting a fourth fix. - Use Case: A test suite has flaky failures caused by race conditions. Instead of adding longer sleep delays, use this Skill to trace the data flow, find the actual timing dependency, and replace arbitrary timeouts with condition-based polling. ## 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 fix with a failing test case. Never propose fixes before completing the investigation phase.

How to fix flaky tests caused by race conditions?▼

Replace arbitrary timeouts like setTimeout or sleep 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 timeout, and only use fixed delays when testing actual timing behavior.

What should I do when multiple fix attempts keep failing?▼

Stop after three failed fixes and question the architecture rather than attempting a fourth fix. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss the architecture with your team before continuing.

How do I trace a bug that appears deep in the call stack?▼

Trace backward from the error location by asking what called each function and what values were passed, continuing until you find the original trigger. Add stack trace instrumentation with console.error before the failing operation if manual tracing is not possible.

When should I add validation at multiple layers of my code?▼

Add defense-in-depth validation after fixing a bug caused by invalid data, placing checks at entry points, business logic, environment guards, and debug instrumentation. Single-point validation can be bypassed by different code paths, refactoring, or mocks.