systematic-debugging

Investigate root causes through a 4-phase process before modifying code.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Random fixes waste time and create new bugs. Quick patches hide root causes, leading to recurring issues and technical debt. This skill enforces a disciplined 4-phase process to ensure you always identify and fix the true source of problems, even under extreme time pressure, authority bias, or sunk cost fallacies.

Core Features & Use Cases

  • 4-Phase Root Cause Process: Investigation, Pattern Analysis, Hypothesis, and Implementation with strict anti-shortcut rules and mandatory re-analysis on failure.
  • Pressure-Resistant Design: Built to resist rationalization during emergencies, social pressure from senior engineers, and exhaustion after long debugging sessions.
  • Supporting Techniques: Includes root-cause tracing for deep stack traces, defense-in-depth validation across all layers, and condition-based waiting for flaky tests.
  • Use Case: When a production API is down and every minute costs thousands, this skill prevents deploying risky retry patches without understanding the true failure mode.

Quick Start

Use the systematic-debugging skill to investigate the failing payment processing test by starting with Phase 1 root cause analysis before attempting any fix.

Frequently Asked Questions about systematic-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the best way to find the root cause of a test failure instead of just patching symptoms?

Systematic debugging enforces a 4-phase process—investigation, pattern analysis, hypothesis, and implementation—to identify the root cause of test failures before proposing any modifications. This eliminates symptom-fixing and prevents recurring bugs.

How do I debug a production outage under extreme time pressure without deploying risky patches?

Debugging a production outage under time pressure requires a pressure-resistant process that enforces single-hypothesis validation and mandatory architectural review after three failed fix attempts. This prevents deploying risky retry patches without understanding the true failure mode.

Why does my bug fix keep failing after multiple attempts, and how can I stop the cycle?

Bug fixes repeatedly failing indicate skipped root cause analysis. A systematic debugging process mandates a strict architectural review after three failed fix attempts, forcing re-analysis of the underlying patterns instead of continuing ineffective patches.

How do I handle flaky tests and unexpected behavior in my integration issues?

Handling flaky tests and unexpected integration behavior requires condition-based waiting and defense-in-depth validation across all layers. These techniques isolate the true failure mode by tracing deep stack traces instead of applying quick patches.

When should I not use a systematic debugging process for my code?

A systematic debugging process should not be used when a fast, temporary symptom patch is explicitly required for immediate mitigation and the technical debt is accepted. Its strict 4-phase root cause investigation and anti-shortcut rules add latency unsuitable for non-critical, trivial fixes.