systematic-debugging

Diagnose bugs and test failures through four-phase root cause investigation.

9|2|Updated Jan 31, 2026
One-click install
npx skills add https://github.com/AbdullahMalik17/Hacathan_5 --skill systematic-debugging-abdullahmalik17
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/AbdullahMalik17/Hacathan_5/tree/main/.claude/skills/systematic-debugging
Command: npx skills add https://github.com/AbdullahMalik17/Hacathan_5 --skill systematic-debugging-abdullahmalik17

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Random fixes and guess-and-check patches waste time, mask underlying issues, and create new bugs. This Skill enforces a disciplined methodology that finds the true root cause of any bug, test failure, or unexpected behavior before any fix is attempted. ## Core Features & Use Cases - Four-Phase Debugging Process: Structured workflow covering root cause investigation, pattern analysis, hypothesis testing, and verified fix implementation. - Root Cause Tracing: Backward tracing through the call stack to find where bad values originate, with guidance on adding stack trace instrumentation. - Escalation Safeguards: Red-flag detection and a rule to question the architecture after three failed fix attempts, preventing fix-stacking thrash. - Use Case: A test suite fails intermittently in CI. Instead of tweaking timeouts, apply the methodology to reproduce the failure, trace data flow across components, form a single hypothesis, and implement one verified fix with a failing test case. ## Quick Start Use the systematic-debugging skill to investigate why my test suite fails intermittently before proposing 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 bug systematically instead of guessing?▼

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

How to find the root cause of an error deep in the call stack?▼

Trace backward through the call chain from where the error appears to where the bad value originated. Add stack trace instrumentation with traceback output to stderr when manual tracing is not possible, then fix at the source rather than the symptom.

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

Stop after three failed fix attempts. If each fix reveals new shared state, requires massive refactoring, or creates new symptoms elsewhere, the problem is architectural and should be discussed before attempting more fixes.

How do I fix flaky tests caused by timing issues?▼

Replace arbitrary sleep calls with condition-based waiting that polls for the actual expected condition with a timeout. Guessing at timing with fixed delays causes flakiness, while waiting on real conditions makes tests deterministic.

What are the limitations of quick fix approaches to debugging?▼

Quick patches treat symptoms rather than root causes, so bugs resurface elsewhere and each patch adds coupling. Symptom fixes also set a bad pattern early, making later systematic investigation harder.