systematic-debugging

Reproduce software bugs, identify root causes, and verify fixes.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Systematic Debugging eliminates guesswork and symptom-focused fixes by ensuring engineers find the root cause of bugs, test failures, and unexpected behavior before applying changes. It reduces repeated thrashing, prevents new regressions, and saves time by enforcing reproducible investigation and evidence-based fixes.

Core Features & Use Cases

  • Four-phase workflow: mandatory Root Cause Investigation, Pattern Analysis, Hypothesis & Testing, and Implementation with clear stop conditions.
  • Pressure-resistant rules: reproduce before fixing, form a single hypothesis, test minimally, create a failing test case, and stop to re-analyze if fixes fail repeatedly.
  • Practical utilities and examples: guidance on tracing call stacks, defense-in-depth validation, condition-based waiting patterns, and a bisection script to find polluting tests.
  • When to use: debugging flaky tests, production incidents, build and integration failures, and any multi-component system where the source of error is unclear.

Quick Start

Use the systematic-debugging skill to reproduce a failing test, gather cross-component evidence, form one clear hypothesis, and run the minimal change to verify the hypothesis.

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

Systematic debugging enforces a four-phase workflow: mandatory Root Cause Investigation, Pattern Analysis, single Hypothesis & Testing, and Implementation with clear stop conditions to eliminate guesswork and repeated thrashing.

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

Debugging multi-component production incidents requires tracing call stacks, gathering cross-component evidence, and validating defense-in-depth to isolate the exact error source before making minimal code changes.

How do I stop my debugging fixes from causing new regressions in my software system?

To stop fixes from causing regressions, create a failing test case that reproduces the bug, test a single hypothesis minimally, and stop to re-analyze if the fix fails repeatedly instead of thrashing.

Does systematic debugging work for tracing polluting tests in integration environments?

Yes, systematic debugging applies to integration failures and includes practical utilities like a bisection script to find polluting tests, alongside condition-based waiting patterns for multi-component services.

When should I stop trying to fix a bug and re-analyze the root cause?

You should stop to re-analyze the root cause when your fixes fail repeatedly, as this indicates symptom-focused patching rather than resolving the underlying issue through evidence-based hypothesis testing.