systematic-debugging

Diagnose software bugs through a four-phase root cause investigation workflow.

Updated Aug 19, 2026
One-click install
npx skills add https://github.com/swcstudiospace/aimeecodes --skill systematic-debugging-swcstudiospace
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/swcstudiospace/aimeecodes/tree/main/.aimee/skills/systematic-debugging
Command: npx skills add https://github.com/swcstudiospace/aimeecodes --skill systematic-debugging-swcstudiospace

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Random fixes and guess-and-check patching waste time, mask underlying issues, and introduce new bugs. This Skill enforces a disciplined root-cause-first debugging process so fixes address the actual problem instead of symptoms. ## Core Features & Use Cases - Four-Phase Process: Root cause investigation, pattern analysis, hypothesis testing, and verified implementation, with mandatory completion checklists per phase. - Tight Feedback Loops: Builds fast, deterministic, red-capable reproduction commands (failing tests, curl scripts, bisection harnesses, fuzz loops) before any fix is attempted. - Rule of Three & Architecture Escalation: After three failed fixes, stops and questions the architecture instead of attempting a fourth patch. - Use Case: A flaky integration test fails intermittently in CI. The Skill guides you to raise the reproduction rate, trace data flow across components, form ranked falsifiable hypotheses, and land a single regression-tested fix. ## Quick Start Use the systematic-debugging skill to investigate why the checkout endpoint returns a 500 error before proposing any fix.

Frequently Asked Questions about systematic-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a bug systematically instead of guessing?▼

Follow the four phases: investigate the root cause by reading errors and building a reproduction loop, analyze patterns against working code, test ranked hypotheses one variable at a time, then implement a single fix verified by a regression test.

How to reproduce a flaky test before fixing it?▼

Raise the reproduction rate by running the trigger repeatedly, parallelizing, adding stress, or narrowing timing windows. A 50% flake is debuggable; a 1% flake usually is not, so invest in the loop before forming theories.

When should I stop trying fixes and question the architecture?▼

Stop after three failed fix attempts. If each fix reveals new coupling or creates symptoms elsewhere, the pattern indicates an architectural problem, and you should discuss refactoring with the user before attempting more fixes.

Does systematic debugging work for multi-component systems?▼

Yes. For systems spanning APIs, services, and databases, add diagnostic instrumentation at each component boundary, log data entering and exiting each layer, then run once to identify which component breaks before investigating it.

Why should I write a failing test before fixing a bug?▼

A failing test proves you understand the root cause and gives a red-to-green signal confirming the fix. Untested fixes do not stick, and the test becomes a permanent regression guard.