systematic-debugging

Enforce a four-phase root-cause debugging process from investigation to verified implementation.

3|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/pedropaulovc/agent-plugins --skill systematic-debugging-pedropaulovc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/pedropaulovc/agent-plugins/tree/main/plugins/superpowers/skills/systematic-debugging
Command: npx skills add https://github.com/pedropaulovc/agent-plugins --skill systematic-debugging-pedropaulovc

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve?

Prevents wasted effort by blocking symptom-chasing and forcing a disciplined root-cause investigation before proposing fixes.

Core Features & Use Cases

  • Four-phase debugging workflow: Root Cause Investigation → Pattern Analysis → Hypothesis & Testing → Implementation, with explicit success criteria for each phase.
  • Pressure-resistant rules: Mandates root-cause first (even under emergencies), requires single-hypothesis testing, and prohibits stacking multiple changes before verification.
  • Failure-mode handling: If the first hypothesis fails, forms a new hypothesis without adding extra fixes; if 3+ fixes fail, stops and questions architecture instead of continuing symptom patches.
  • Supporting techniques and related skills: Points to root-cause tracing, defense-in-depth, and condition-based waiting, plus references to test-driven development and verification-before-completion.
  • Use cases: Test failures, production bugs, unexpected behavior, performance problems, build/integration failures, and multi-component debugging where evidence must be gathered at each boundary.

Quick Start

When you hit a bug, follow Phase 1 to gather evidence and trace the issue to its original trigger before writing or proposing any fixes.

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 test failures instead of just patching symptoms?

To find the root cause of test failures, you must complete a full investigation phase to gather evidence and trace the issue to its original trigger before proposing any fixes. This prevents wasted effort on symptom-chasing.

What is the best way to debug production outages and multi-component failures?

The best way to debug production outages is to gather evidence at each component boundary during investigation, form a single hypothesis, test it minimally, and verify each step before moving to implementation.

Why do my debugging fixes keep failing when I stack multiple changes at once?

Debugging fixes fail when stacking multiple changes because you cannot isolate the effect of each modification. You must test a single hypothesis at a time and verify each step before applying additional fixes.

When should I stop trying to patch a bug and question my software architecture instead?

You should stop patching a bug and question your software architecture after three or more fixes fail. Continuing to apply symptom patches after repeated failures wastes effort compared to re-evaluating the design.

How do I debug build and integration breakages systematically?

To debug build and integration breakages systematically, follow a four-phase process: root cause investigation, pattern analysis, hypothesis testing, and verified implementation. You must gather evidence and complete the investigation before writing fixes.

Does root-cause debugging work for performance issues and unexpected application behavior?

Yes, root-cause debugging works for performance issues and unexpected behavior by enforcing a disciplined four-phase workflow that requires forming a single hypothesis and verifying each step before implementation.