systematic-debugging

Diagnose root causes of bugs, flaky tests, and integration failures through evidence-based tracing.

1|Updated Sep 15, 2026
One-click install
npx skills add https://github.com/amoai-tech/mdeai --skill systematic-debugging-amoai-tech
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/amoai-tech/mdeai/tree/main/.claude/skills/systematic-debugging
Command: npx skills add https://github.com/amoai-tech/mdeai --skill systematic-debugging-amoai-tech

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? When a bug, failed test, regression, or flaky behavior appears, it is tempting to patch the symptom or guess at fixes. This Skill enforces a disciplined root-cause workflow so failures are reproduced, traced, and fixed at the source instead of being masked by retries or fallbacks. ## Core Features & Use Cases - Structured debugging workflow: Reproduce the failure, capture evidence, trace backward to the first incorrect assumption, test one hypothesis at a time, and apply the smallest root-cause fix. - Boundary tracing for integrations: Record values at each layer of a stack (UI, API routes, agent runtime, domain tools, external services like Supabase, Stripe, or Maps) to localize which boundary failed. - Flaky test and pollution tooling: Use condition-based waiting patterns instead of arbitrary sleeps, defense-in-depth validation across layers, and a bisection script that finds which test pollutes shared state. - Use Case: A Playwright test fails one run in ten. Instead of adding a sleep or rerunning until green, the Skill guides you to wait on actual conditions, isolate state pollution with the find-polluter script, and lock the fix with a regression test. ## Quick Start Use the systematic-debugging skill to find the root cause of this failing integration test before changing any code.

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 fixing symptoms?

Reproduce the failure with the smallest reliable command, capture the exact error and inputs, then trace backward through the call chain until you find the first incorrect assumption or state transition. Test one hypothesis at a time and fix at the source, not where the error appears.

How to fix flaky tests without adding sleep or retries?

Use condition-based waiting: poll for the actual condition you care about, such as an event or state change, instead of arbitrary setTimeout delays. Rerunning flaky tests until green without explaining the flake hides the underlying race condition.

How do I debug failures across API and service boundaries?

Record the value at each boundary in the stack, from UI through API routes, agent runtime, and external services like Supabase or Stripe. At each boundary verify input shape, auth context, IDs, timeouts, side effects, and error propagation to localize the failing layer.

How can I find which test pollutes shared state?

Use the find-polluter.sh bisection script, which runs each test file individually and checks whether a specified file or directory appears afterward. It stops at the first polluting test and reports the created artifacts for investigation.

When should I stop proposing fixes during debugging?

Stop when you cannot reproduce or localize the failure, and gather more evidence instead. Also stop if a patch only suppresses an error, retries indefinitely, weakens authorization, bypasses validation, or changes unrelated behavior.