systematic-debugging

Diagnose bugs through a four-phase root-cause investigation workflow before applying fixes.

1|Updated Mar 18, 2026
One-click install
npx skills add https://github.com/MARUCIE/openclaw-foundry --skill systematic-debugging-marucie
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/MARUCIE/openclaw-foundry/tree/main/web/public/packs/algorithm-engineer/skills/algorithm/systematic-debugging
Command: npx skills add https://github.com/MARUCIE/openclaw-foundry --skill systematic-debugging-marucie

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Debugging often devolves into guessing and quick patches that mask root causes and create new bugs. This Skill enforces a disciplined four-phase investigation process so every fix is backed by evidence, not intuition. ## Core Features & Use Cases - Four-Phase Discipline: Sequential phases covering root cause analysis, pattern comparison, hypothesis testing, and verified fixes with regression checks. - 3-Strike Rule: After three failed fix attempts, the issue is escalated as an architectural problem instead of endless patching. - Layer-by-Layer Diagnostics: Inject diagnostic output at each component boundary to locate exactly where multi-component systems break. - Use Case: A test suite suddenly fails after a refactor. Instead of tweaking code at random, you reproduce the failure, compare against the last working version, test one hypothesis at a time, write a failing test that reproduces the bug, then apply a single verified fix. ## Quick Start Ask the AI to systematically debug the failing test or error you are seeing, following the root-cause-first process 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 failing test without guessing?▼

Follow a root-cause-first process: read the full error stack, reproduce the failure, check recent changes, and trace the data flow before proposing any fix. Then test one hypothesis at a time with the smallest possible reproduction case.

What is the 3-strike rule in debugging?▼

The 3-strike rule stops endless patching: after three failed fix attempts, you stop and treat the issue as an architectural problem rather than a bug. The team discusses the design instead of applying more surface-level fixes.

How do I find which component failed in a multi-layer system?▼

Inject diagnostic output at each layer boundary: entry point, processing, and output. Run the system once to see exactly where it breaks, then investigate only that layer instead of guessing across the whole stack.

When should I not use a systematic debugging process?▼

This process is not for writing new features or greenfield code. It is designed for existing bugs, test failures, crashes, and regressions where a root cause exists and must be found before fixing.

Why do quick fixes create more bugs?▼

Quick fixes address symptoms rather than root causes, so the underlying defect remains and often surfaces elsewhere. Each symptom patch can introduce new problems, which is why evidence-based diagnosis must come first.