systematic-debugging

Locate and validate root causes before implementing fixes.

130|8|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/sandgardenhq/sgai --skill systematic-debugging-sandgardenhq
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/sandgardenhq/sgai/tree/main/cmd/sgai/skel/.sgai/skills/systematic-debugging
Command: npx skills add https://github.com/sandgardenhq/sgai --skill systematic-debugging-sandgardenhq

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Debugging often devolves into guesswork, quick patches, and repeated failures that waste time and create new bugs. This Skill enforces a disciplined, evidence-driven process that prioritizes understanding root causes before any fix is attempted, reducing rework and preventing regressions.

Core Features & Use Cases

  • Four-Phase Framework: Root cause investigation, pattern analysis, hypothesis testing, and implementation with verification.
  • Evidence Gathering in Multi-Component Systems: Instrument boundaries to localize failures across workflows, services, and environments.
  • Guardrails Against Thrashing: Explicit stop conditions, single-hypothesis testing, and escalation when 3+ fixes fail to prompt architectural review.
  • Use Case: A CI build intermittently fails code signing; by instrumenting each pipeline boundary and tracing data flow, you identify a missing environment variable propagation rather than repeatedly tweaking signing flags.

Quick Start

Use the systematic-debugging skill to reproduce the failure, gather boundary evidence, trace data flow to the source, and propose a single, testable hypothesis before 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 find the root cause of intermittent software test failures instead of guessing at fixes?

Root cause analysis for software test failures requires reproducing the issue, instrumenting system boundaries, tracing data flow, and testing a single hypothesis before implementing any fix. This structured debugging process prevents thrashing and repeated patches that introduce new regressions.

What is the best way to debug production bugs across multi-component workflows and services?

Debugging production bugs across multi-component workflows requires boundary instrumentation to localize failures, data-flow tracing to identify the source, and verification with a failing test before and after applying a fix to ensure the true root cause is resolved.

How do I stop repeatedly patching build and integration issues that keep coming back?

To stop recurring build and integration issues, enforce a four-phase debugging framework: investigate root causes, analyze patterns, test a single hypothesis, and implement with verification. Escalate to architectural review if three or more fixes fail to resolve the issue.

When should I escalate a performance anomaly to an architectural review during incident response?

During incident response for performance anomalies, escalate to an architectural review after three or more attempted fixes fail. This stop condition prevents thrashing and ensures the debugging process transitions from localized patches to structural system evaluation.

Can I use hypothesis testing to debug CI pipeline failures and environment variable propagation issues?

Yes, hypothesis testing debugs CI pipeline failures by instrumenting each pipeline boundary, tracing data flow to identify missing environment variable propagation, and validating a single testable hypothesis with a failing test before and after implementing the actual fix.