systematic-debugging

Coordinates root-cause-first workflows for diagnosing and fixing complex system faults.

4|Updated May 18, 2026
One-click install
npx skills add https://github.com/ZardLi1115/zedclaw --skill systematic-debugging-zardli1115
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/ZardLi1115/zedclaw/tree/main/skills/software-development/systematic-debugging
Command: npx skills add https://github.com/ZardLi1115/zedclaw --skill systematic-debugging-zardli1115

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents wasted time, hidden regressions, and repeated failures by forcing a disciplined workflow that isolates the true root cause before any code changes are proposed.

Core Features & Use Cases

  • Four-phase debugging workflow: Root-cause investigation, pattern analysis, hypothesis testing, and root-cause implementation.
  • Evidence-first diagnostics: Read and interpret error messages, reproduce reliably, review recent changes, gather data, and trace data flow across components.
  • Decision guardrails: Explicitly stops fixes until root cause is understood, and escalates to architecture review after 3+ failed fix attempts.
  • Use cases: Test failures, production bugs, unexpected behavior, performance issues, build/integration failures, and multi-component system issues (CI/build/deploy, API/service/db).

Quick Start

Use the skill to debug a failing test by reproducing it, reading the full error output, tracing the data flow to where the bad value originates, and only then planning the smallest single root-cause change.

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 test failure before attempting a fix?

A systematic debugging workflow isolates the true root cause of test failures by reproducing the error, reviewing recent changes, and tracing data flow across components before any code fixes are proposed.

What is the best way to debug multi-component system issues like CI build and deploy failures?

Debugging multi-component system issues requires evidence-first diagnostics that trace data flow and configuration boundaries across APIs, services, and databases to isolate the root cause before implementing a fix.

How do I stop guessing and systematically troubleshoot production bugs?

To stop symptom-focused guessing during troubleshooting, follow a disciplined four-phase workflow: root-cause investigation, pattern analysis, hypothesis testing, and root-cause implementation. You must understand the root cause completely before applying any fixes.

When should I escalate a production bug or build integration issue to an architecture review?

You should escalate a production bug or build integration issue to an architecture review after 3 or more failed fix attempts. This decision guardrail prevents wasting further debugging time on symptom-focused guessing.

How do I prevent regressions when implementing a root-cause fix for an unexpected behavior issue?

To prevent regressions when implementing a root-cause fix, apply the smallest single root-cause change and pair it with a dedicated regression test and verification checks. This ensures the unexpected behavior is resolved without hidden regressions.