systematic-debugging

Trace root causes of bugs and test failures before implementing fixes.

Updated Jul 2, 2026
One-click install
npx skills add https://github.com/HexSleeves/skills --skill systematic-debugging-hexsleeves
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/HexSleeves/skills/tree/main/skills/staff-forensic-debugging
Command: npx skills add https://github.com/HexSleeves/skills --skill systematic-debugging-hexsleeves

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you investigate bugs, test failures, and unexpected behavior by finding the root cause before making any changes, avoiding guesswork and symptom-only fixes.

Core Features & Use Cases

  • Forces a four-phase workflow: root cause investigation, pattern analysis, hypothesis testing, and implementation.
  • Encourages evidence gathering through error reading, reproducibility checks, tracing data flow, and comparing against working examples.
  • Useful for production incidents, flaky tests, build failures, multi-component integrations, and any situation where a quick patch is tempting.
  • Helps you stop after failed attempts, create a failing test, and verify the fix before claiming success.

Quick Start

Use this skill to debug the issue by reading the error, reproducing it, tracing the root cause, and then testing a single minimal fix.

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 applying a fix?

To find the root cause of a bug, gather structured evidence by reading errors, reproducing the issue, and tracing data flow. Test a single hypothesis and create a failing test before implementing any fix to verify the root cause.

What is the best way to troubleshoot flaky tests and build pipeline failures?

Troubleshooting flaky tests and build failures requires a four-phase workflow: root cause investigation, pattern analysis, hypothesis testing, and implementation. Compare against working examples and trace data flow to eliminate guesswork.

How do I stop introducing regressions when debugging production incidents?

Stop introducing regressions during production incidents by halting after failed patch attempts, creating a failing test that reproduces the behavior, and verifying the fix before claiming success.

Why does applying a quick patch to unexpected behavior often create new bugs?

Applying a quick patch creates new bugs because it treats symptoms without investigating the root cause. A systematic approach forces single-hypothesis testing and post-fix verification to ensure the original issue is truly resolved.

Can I use systematic debugging for multi-component integration issues?

Yes, you can use systematic debugging for multi-component integration issues. It applies structured evidence gathering and data-flow tracing to diagnose complex technical incidents across workflows where guesswork creates regressions.

What should I do when my initial bug fix attempts fail to resolve the issue?

When bug fix attempts fail, stop patching and return to evidence gathering. Reproduce the error, trace the data flow, compare against working examples, and create a failing test to validate a new single-hypothesis before trying another fix.