systematic-debugging

Breaks down debugging tasks into a four-phase workflow with reproduction and hypothesis testing.

Updated Apr 24, 2026
One-click install
npx skills add https://github.com/Cain-Ish/claude-code-plugin --skill systematic-debugging-cain-ish
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/Cain-Ish/claude-code-plugin/tree/main/skills/systematic-debugging
Command: npx skills add https://github.com/Cain-Ish/claude-code-plugin --skill systematic-debugging-cain-ish

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents wasted time and new bugs by enforcing root-cause investigation before any code change, even when you feel pressure to “just patch it.”

Core Features & Use Cases

  • Root cause first: Requires completing evidence gathering, pattern analysis, and hypothesis testing before implementation.
  • Phase-driven workflow: Structures debugging into clear phases with specific success criteria and explicit “stop” rules when you’re guessing.
  • Multi-component diagnostics: Prompts you to instrument and trace data flow across boundaries (CI → build → deploy, API → service → database, etc.).

Use case examples: resolving a flaky test failure, diagnosing an unexpected production behavior, or tracking down a build/integration issue where symptoms don’t reveal the true source.

Quick Start

Use systematic-debugging when you hit a failing test or unexpected runtime error, and follow Phase 1 to reproduce and gather evidence before suggesting 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 a failing test instead of just patching the symptom?

Root cause debugging requires completing evidence gathering, pattern analysis, and hypothesis testing before implementation. You reproduce the failure, gather evidence, compare patterns, and test a single minimal hypothesis to verify the true source before proposing fixes.

What is the best way to debug an unexpected production behavior across multiple components?

Multi-component diagnostics instrument and trace data flow across boundaries like API to service to database. By tracking data flow across system borders, you can identify exactly where the unexpected behavior originates before applying any code changes.

How do I systematically investigate a build or integration error when symptoms don't reveal the source?

Systematic investigation structures debugging into phases with explicit stop rules for guessing. You reproduce the error, gather evidence, compare against known patterns, and test a single minimal hypothesis to isolate the hidden root cause.

Can I use hypothesis testing to resolve a flaky test failure?

Hypothesis testing resolves flaky test failures by forcing you to reproduce the failure and gather evidence first. You then test a single minimal hypothesis against the collected data, ensuring you verify the root cause before implementation.

When should I stop guessing during error investigation?

You should stop guessing during error investigation when you lack sufficient evidence to form a hypothesis. The workflow enforces explicit stop rules that require returning to evidence gathering and pattern comparison before proceeding to implementation.