systematic-debugging

Diagnose software bugs through a four-phase root cause investigation workflow.

2|Updated Oct 20, 2017
One-click install
npx skills add https://github.com/rbudiharso/dotfiles --skill systematic-debugging-rbudiharso
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/rbudiharso/dotfiles/tree/main/hermes/.hermes/skills/software-development/systematic-debugging
Command: npx skills add https://github.com/rbudiharso/dotfiles --skill systematic-debugging-rbudiharso

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Random fixes and guess-and-check patching waste hours and introduce new bugs. This Skill enforces a disciplined four-phase debugging process that finds the root cause before any fix is attempted, preventing symptom-only patches and repeated failed fix attempts. ## Core Features & Use Cases - Four-Phase Process: Root cause investigation, pattern analysis, hypothesis testing, and implementation, each with explicit completion checklists. - Tight Feedback Loops: Build fast, deterministic reproduction commands (failing tests, curl scripts, CLI invocations, headless browser checks) that go red on the exact symptom and green when fixed. - Rule of Three: After three failed fixes, stop and question the architecture instead of attempting a fourth patch. - Use Case: A production API intermittently returns wrong data. Instead of guessing, you build a high-repetition repro loop, trace data flow across the API-service-database boundary, form ranked hypotheses, and fix the actual root cause with a regression test. ## Quick Start Ask the agent to debug a failing test or bug using the systematic-debugging process, starting with root cause investigation 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 failing test systematically?▼

Start with root cause investigation: read the full error message and stack trace, build a tight reproduction command that fails on the exact symptom, and check recent git changes. Only after understanding why it fails should you form hypotheses and test fixes one variable at a time.

What is a tight feedback loop in debugging?▼

A tight feedback loop is a fast, deterministic command that goes red on the exact bug symptom and green only when the bug is fixed. Examples include a failing unit test, a curl script against a dev server, or a CLI invocation diffed against expected output.

How do I debug flaky or intermittent test failures?▼

Raise the reproduction rate first: run the trigger 100 times, parallelize, add stress, or narrow timing windows. A 50% flake is debuggable while a 1% flake usually is not. Pin time, seed randomness, and isolate filesystem and network to improve determinism.

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

Stop after three failed fix attempts. If each fix reveals new shared state or coupling in a different place, requires massive refactoring, or creates new symptoms elsewhere, the pattern itself is likely wrong and needs architectural discussion before more fixes.

Why should I not apply a quick fix before investigating?▼

Quick fixes mask symptoms while the root cause remains, often creating new bugs elsewhere. Systematic investigation typically resolves issues in 15-30 minutes with a 95% first-time fix rate, versus hours of thrashing with random patches.