systematic-debugging

Guide root-cause debugging through a four-phase investigation workflow.

1.4k|129|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/shiwenwen/hope-agent --skill systematic-debugging-shiwenwen
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/shiwenwen/hope-agent/tree/main/skills/systematic-debugging
Command: npx skills add https://github.com/shiwenwen/hope-agent --skill systematic-debugging-shiwenwen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents wasteful guess-and-check debugging by enforcing a disciplined root-cause investigation workflow before any fixes are proposed.

Core Features & Use Cases

  • Four-phase root-cause workflow: systematically investigates errors, analyzes patterns, tests a single hypothesis, and only then implements a fix verified by regression testing.
  • Evidence-first diagnosis: prioritizes reading error messages, reproducing reliably, checking recent changes, tracing data flow, and gathering multi-component evidence when failures cross boundaries.
  • Guardrails against thrashing: blocks symptom-fixing and stops escalation after repeated failed attempts by explicitly prompting for architectural reconsideration.

Quick Start

Tell the AI: diagnose the bug by reading the full error output, reproducing the failing test, tracing the data flow to the original source of the failure, and only then proposing a single root-cause fix with a regression test.

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 before changing code?

To find the root cause of a bug, follow a disciplined workflow: read error messages, reproduce the failure reliably, trace data flow to the original source, and validate a single hypothesis before proposing any fix.

What is the best way to troubleshoot multi-component test failures?

Troubleshooting multi-component test failures requires gathering evidence across boundaries by tracing data flow with grep and read commands, checking recent changes, and verifying a single hypothesis about the interaction before applying fixes.

How do I stop guess-and-check debugging when fixing production regressions?

Stop guess-and-check debugging by enforcing an evidence-first diagnosis: read full error outputs, reproduce the regression consistently via exec, and understand the root cause completely before writing a verified regression-tested fix.

How do you trace data flow to investigate unexpected technical behavior?

Trace data flow by using tools like grep and read to follow the execution path and data transformations from the point of failure back to the original source, gathering evidence to form a single validated hypothesis.

When should I escalate or reconsider the architecture during root cause investigation?

You should escalate and reconsider the architecture during root cause investigation when repeated debugging attempts fail, triggering guardrails that stop thrashing and block symptom-fixing in favor of architectural reevaluation.