systematic-debugging

Name: systematic-debugging
Availability: InStock
Author: jbonfim

Debug failures through a four-phase root-cause investigation process.

Updated May 15, 2026

Search Tags:#debugging #root cause #test failures #flaky tests #hypothesis testing #incident response #debugging workflow

Ready to run

npx skills add https://github.com/JBonfim/skill-developer --skill systematic-debugging-jbonfim

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/JBonfim/skill-developer/tree/main/.agents/skills/systematic-debugging
Command: npx skills add https://github.com/JBonfim/skill-developer --skill systematic-debugging-jbonfim

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve?

This Skill prevents wasted time and recurring bugs by enforcing root-cause investigation before any fixes, including during test failures and production incidents.

Core Features & Use Cases

Root-cause first mandate: Establishes the Iron Law that no fixes are allowed without Phase 1 root-cause investigation, especially when under time pressure.
Four-phase debugging workflow: Guides users through Root Cause Investigation, Pattern Analysis, Hypothesis & Testing, and Implementation with explicit success criteria.
Failure-resistant guardrails: Requires minimal testing per hypothesis, prohibits stacking multiple changes, and instructs what to do after a failed fix (including when to question architecture after 3+ failures).

Quick Start

Follow Phase 1 of the skill to read errors carefully, reproduce the issue consistently, check recent changes, and gather evidence 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 find the root cause of flaky test failures instead of just fixing symptoms?▼

Root cause debugging requires completing a strict investigation phase that reproduces the issue consistently and gathers cross-boundary evidence before proposing any fixes. This enforces evidence-based pattern comparison to prevent recurring bugs.

What is the best way to debug production incidents without causing recurring issues?▼

The best way to debug production incidents is following a four-phase systematic workflow: root cause investigation, pattern analysis, hypothesis testing, and implementation. This mandates root-cause fixing with a failing test case before deploying changes.

How do I debug multi-component integration issues with cross-boundary evidence?▼

Debugging multi-component integration issues requires a systematic process that gathers cross-boundary evidence during pattern analysis. You test a single hypothesis with minimal changes before applying root-cause fixes to isolate the failing component accurately.

What should I do when my debugging fixes keep failing on the same bug?▼

When your debugging fixes fail repeatedly, you should re-analyze the problem and question the architecture after three or more failed attempts. This prevents stacking multiple changes and forces a return to root-cause investigation.

Can I use a systematic debugging workflow for build failures and performance problems?▼

Yes, a systematic debugging workflow applies to any bug, build failure, performance problem, or unexpected behavior. It requires reading errors carefully, reproducing the issue, and checking recent changes before implementing a fix.