systematic-debugging

Enforce root cause investigation before proposing fixes to bugs.

Updated Apr 10, 2026
One-click install
npx skills add https://github.com/LuizEduPP/skills --skill systematic-debugging-luizedupp
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/LuizEduPP/skills/tree/main/systematic-debugging
Command: npx skills add https://github.com/LuizEduPP/skills --skill systematic-debugging-luizedupp

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Root cause investigation is skipped when bugs appear, costing time and creating regressions and lingering symptoms in tests, builds, and production flows. This Skill forces pause, evidence gathering, and mandated research before any code change.

Core Features & Use Cases

  • Structured four-phase workflow: Phase 1 documents evidence, Phase 2 compares working references, Phase 3 formulates single hypotheses, and Phase 4 implements tests-only fixes.
  • Pressure-resistant guardrails: Anti-patterns, human partner signals, and architectural stop points prevent irrational shortcuts, even under urgent incidents or noisy leadership.
  • Real-world support docs: References like root-cause tracing, defense-in-depth, and condition-based waiting provide deeper guidance for layered validation and instrumentation.

Quick Start

Ask for systematic-debugging before touching the code whenever you observe a failing test, error message, or unexpected behavior and need a reliable 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 failing test instead of just patching the symptom?

Root cause investigation requires documenting evidence, comparing working references, and testing single hypotheses before changing code. This structured debugging approach enforces evidence gathering and failing tests to guarantee regressions are avoided.

What is the best way to debug production outages without introducing new regressions?

Debugging production outages safely demands pressure-resistant guardrails and single-hypothesis testing before any fix. This method mandates evidence collection and condition-based waiting to prevent irrational shortcuts during urgent incidents.

How do I stop hasty patches from causing test failures and integration regressions?

To stop hasty patches, enforce a four-phase workflow: document evidence, compare patterns, formulate single hypotheses, and implement tests-only fixes. This prevents bug investigation shortcuts that introduce lingering symptoms in builds.

Does systematic debugging work for integration failures and test-driven development pipelines?

Systematic debugging targets integration failures and test-driven development pipelines by enforcing root cause tracing. It mandates failing tests documented before changes, ensuring fixes address unexpected behavior across testing environments.

When should I not use trial-and-error patching for unexpected behavior in my build?

Avoid trial-and-error patching whenever a failing test, error message, or unexpected behavior appears. Skipping root cause investigation costs time and creates regressions, demanding disciplined evidence gathering and architectural stop points instead.