systematic-debugging

Enforce a four-phase root-cause investigation workflow before fixing bugs.

6|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/caitengwei/my-skills --skill systematic-debugging-caitengwei
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/caitengwei/my-skills/tree/main/superpowers/skills/systematic-debugging
Command: npx skills add https://github.com/caitengwei/my-skills --skill systematic-debugging-caitengwei

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents wasted time and recurring failures by forcing a disciplined root-cause-first debugging process instead of applying quick symptom patches.

Core Features & Use Cases

  • Root-cause mandate (Iron Law): Requires root-cause investigation before proposing any fixes.
  • Four-phase workflow: Guides you through Phase 1 (investigation), Phase 2 (pattern analysis), Phase 3 (hypothesis & testing), and Phase 4 (implementation).
  • Pressure-resistant anti-rationalization: Emphasizes stopping when tempted to skip steps, especially under time pressure or after prior fixes fail.
  • Multi-component evidence gathering: Provides a structured approach for tracing failures across boundaries (CI → build → signing, API → service → database, etc.).
  • Failure modes and guardrails: Includes explicit rules for single-hypothesis testing and what to do when fixes fail (re-analyze vs. question architecture).

Quick Start

Use systematic-debugging when you hit a test failure, bug, or unexpected behavior, and follow the four phases until the root cause is proven.

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

Root cause analysis for flaky test failures requires a systematic debugging workflow that enforces evidence-driven tracing and single-hypothesis testing before proposing any fixes. This prevents recurring failures by stopping symptom patches.

How do I debug production incidents across multi-component system boundaries?

Debug production incidents by applying a four-phase investigation workflow with multi-component evidence gathering, tracing failures across boundaries like API to service to database before implementing changes.

Why do my bug fixes fail under time pressure and how can I stop rationalizing skipped steps?

Bug fixes fail under time pressure due to anti-rationalization gaps; a systematic debugging process enforces strict rules for failed fixes, requiring re-analysis or questioning architecture instead of skipping steps.

What steps should I follow for root cause analysis when handling integration and build failures?

Handling integration and build failures follows four phases: investigation, pattern analysis, hypothesis with single minimal testing, and implementation, proving the root cause before any code changes.

When should I re-analyze a failed fix versus questioning the architecture during debugging?

During debugging, re-analyze the failed fix when single-hypothesis testing yields new evidence; question the architecture if the systematic process reveals fundamental multi-component anti-patterns causing the incident.