systematic-debugging

Enforce a four-phase root-cause debugging workflow before proposing fixes.

Updated May 13, 2026
One-click install
npx skills add https://github.com/kimprobably/maestro-os --skill systematic-debugging-kimprobably
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/kimprobably/maestro-os/tree/main/hermes/distribution/maestro-operator/skills/systematic-debugging
Command: npx skills add https://github.com/kimprobably/maestro-os --skill systematic-debugging-kimprobably

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents wasted time and recurring failures by stopping symptom-chasing and forcing root-cause investigation before any changes are made.

Core Features & Use Cases

  • Guided four-phase debugging workflow: investigation, pattern analysis, hypothesis testing, and root-cause implementation.
  • Pressure-resistant guardrails: explicit “STOP and re-analyze” rules, anti-shortcuts, and failure handling for repeated unsuccessful fixes.
  • Multi-component evidence gathering: add instrumentation across boundaries and trace data flow to identify which layer fails.

Use it when you hit test failures, production bugs, unexpected behavior, performance issues, build failures, or integration problems—especially under time pressure or after quick fixes haven’t worked.

Quick Start

Use systematic-debugging when you notice an error and follow Phase 1 to read errors, reproduce the issue, and trace evidence before proposing 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 test failures instead of just patching symptoms?

Root cause debugging requires a systematic four-phase workflow: investigation, pattern analysis, hypothesis testing, and minimal-change implementation. You must gather evidence, trace data flow, and test a single hypothesis before proposing any fix.

What is the best way to debug multi-component integration issues across system boundaries?

Debugging multi-component systems requires adding instrumentation across boundaries and tracing data flow to identify which layer fails. Evidence gathering across components is mandatory before attempting any fixes in complex integration environments.

Why do my quick fixes keep failing when I try to resolve unexpected behavior under time pressure?

Quick fixes fail because they chase symptoms instead of root causes. A systematic debugging workflow enforces STOP and re-analyze rules after repeated unsuccessful fixes, preventing wasted time and recurring failures under pressure.

How do I systematically trace data flow to locate which layer is causing a production bug?

Tracing data flow requires systematic evidence gathering and instrumentation added across component boundaries. You must reproduce the issue, read errors carefully, and trace evidence through each layer before forming a single testable hypothesis.

When should I stop trying quick fixes and re-analyze a build failure or performance issue?

You must stop and re-analyze after repeated failed fixes. The systematic debugging workflow includes explicit STOP rules and anti-shortcut guardrails that trigger re-analysis when initial attempts to resolve build failures or performance issues fail.

Does systematic root cause debugging work for single-component bugs or only complex multi-component systems?

Root cause debugging applies to both single-component issues and multi-component systems. The four-phase workflow scales from isolated test failures to complex integration problems requiring evidence gathering across boundaries and data-flow tracing.