How does this skill handle bugs in multi-layer systems?

It implements diagnostic instrumentation at every component boundary (e.g., API to Service to Database) to log entering and exiting data, pinpointing exactly where the failure occurs.

What happens if a fix doesn't work after several attempts?

If three or more fix attempts fail, the skill stops the process to question the underlying architecture, suggesting that the problem may be a fundamental design flaw rather than a simple bug.

What is the 'Iron Law' of systematic debugging?

The Iron Law states that no fixes may be proposed until a complete root cause investigation (Phase 1) has been finished and the cause is fully understood.

Does this skill require writing automated tests?

Yes, Phase 4 of the process requires creating a minimal failing test case to reproduce the bug before any fix is implemented, ensuring the solution is verified and prevents regressions.

Systematic Debugging

Name: Systematic Debugging
Author: darthmolen

bydarthmolen

Security & Testing

Implements a rigorous four-phase framework to identify root causes and eliminate trial-and-error debugging thrashing.

About

The Systematic Debugging skill enforces a disciplined 'Iron Law' that prevents the implementation of fixes before a root cause is fully understood. By guiding Claude through investigation, pattern analysis, hypothesis testing, and implementation, it ensures that bugs are permanently resolved rather than masked by superficial patches. This skill is essential for navigating complex, multi-component systems where issues often hide behind environmental variables or deep data-flow layers, significantly reducing the time spent on 'guess-and-check' cycles.

Key Features

Strict four-phase debugging workflow (Investigation, Pattern, Hypothesis, Implementation)
Backward data-flow tracing to identify the origin of bad values
0 GitHub stars
Automatic escalation to architectural review after three failed fix attempts
Diagnostic instrumentation for multi-component system boundaries
Mandatory failing test case creation before proposing code changes

Use Cases

Identifying root causes in complex API-to-database integration layers
Debugging non-deterministic test failures in CI/CD pipelines
Troubleshooting production emergencies where 'quick fixes' are tempting but risky

About

Key Features

Strict four-phase debugging workflow (Investigation, Pattern, Hypothesis, Implementation)
Backward data-flow tracing to identify the origin of bad values
0 GitHub stars
Automatic escalation to architectural review after three failed fix attempts
Diagnostic instrumentation for multi-component system boundaries
Mandatory failing test case creation before proposing code changes

Use Cases

Identifying root causes in complex API-to-database integration layers
Debugging non-deterministic test failures in CI/CD pipelines
Troubleshooting production emergencies where 'quick fixes' are tempting but risky