systematic-debugging

Guide software debugging through a four-phase root cause investigation process.

270k|24.1k|Updated Oct 9, 2025
One-click install
npx skills add https://github.com/obra/superpowers --skill systematic-debugging-obra
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/obra/superpowers/tree/main/skills/systematic-debugging
Command: npx skills add https://github.com/obra/superpowers --skill systematic-debugging-obra

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solves? This Skill eliminates time-wasting random fixes and quick patches that only mask underlying issues. It enforces a rigorous, four-phase framework to ensure you always find and fix the root cause of any technical problem, preventing costly rework.

Core Features & Use Cases

  • Four-Phase Framework: Guides you through Root Cause Investigation, Pattern Analysis, Hypothesis Testing, and Implementation, ensuring a thorough approach.
  • Evidence-Based Debugging: Mandates gathering evidence and reproducing issues consistently before proposing any fixes, preventing guesswork.
  • Pressure-Resistant Rules: Designed to prevent shortcuts and rationalizations, even under extreme time pressure or exhaustion, ensuring discipline.
  • Use Case: When a critical production API is down, this skill forces you to resist the urge for a "quick fix" and instead systematically investigate the root cause, preventing future recurrences and saving significant revenue.

Quick Start

Example: Encountering a test failure

You: I'm using the systematic-debugging skill to investigate this test failure.

Phase 1: Root Cause Investigation (BEFORE any fix)

- Read error messages carefully, reproduce consistently, check recent changes.

- Gather evidence in multi-component systems (add diagnostic instrumentation).

- Trace data flow (use superpowers:root-cause-tracing if error is deep).

Phase 2: Pattern Analysis

- Find working examples, compare against references, identify differences.

- Understand dependencies and assumptions.

Phase 3: Hypothesis and Testing

- Form a single, specific hypothesis: "I think X is the root cause because Y."

- Test minimally (one variable at a time).

- If fix doesn't work, form a NEW hypothesis (DON'T add more fixes).

Phase 4: Implementation

- Create a failing test case (use superpowers:test-driven-development).

- Implement a single fix for the root cause.

- Verify the fix, ensure no other tests are broken.

- If 3+ fixes failed, STOP and question the architecture.

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 applying quick fixes?▼

Root cause analysis follows a four-phase framework: investigate the issue systematically, analyze patterns by comparing working and broken states, form and test a single hypothesis, then implement a focused fix. This prevents symptom-masking and rework by addressing the underlying problem, not surface symptoms.

Why do my bug fixes keep failing or causing new problems?▼

Fixes fail when you skip evidence gathering and root cause investigation. Systematic debugging mandates reproducing issues consistently, tracing data flow across components, and testing one variable at a time. Multiple failed fixes signal an architecture problem requiring investigation, not more patches.

How do I debug problems in multi-component systems?▼

Systematic debugging gathers diagnostic evidence across components, traces data flow to isolate failure points, and uses root-cause-tracing for deep errors. This approach prevents false leads and ensures you identify where the problem actually originates, not where symptoms appear.

Can I use this approach under time pressure or during production outages?▼

Yes. Systematic debugging is designed pressure-resistant: it prevents rationalizations and shortcuts even under exhaustion or tight deadlines. Following the four-phase workflow ensures you fix problems once rather than applying temporary patches that cause costly rework later.

What's the difference between investigation and hypothesis testing in debugging?▼

Investigation gathers evidence and reproduces the issue consistently; hypothesis testing validates a single, specific theory about the root cause. Separating these phases prevents guesswork and ensures you understand the problem before attempting a fix, avoiding the trap of chasing symptoms.

When should I stop debugging and reconsider the architecture?▼

Stop and reconsider architecture after three or more failed fixes. This signals the problem may not be a simple bug but a design flaw. Systematic debugging prevents wasting effort on patches by forcing this evaluation point explicitly.