What is the 'Iron Law' of this debugging skill?

The Iron Law mandates that no code fixes are proposed until a thorough root cause investigation is completed and the issue is consistently reproduced and understood.

What happens if three or more fix attempts fail?

The process triggers an architectural review. Instead of attempting a fourth fix, the skill prompts a discussion about whether the underlying pattern or architecture is fundamentally flawed.

When should I use the Systematic Debugging skill?

Use it for any technical issue, especially under time pressure, when simple fixes have already failed, or when dealing with complex systems where the root cause is not immediately obvious.

How does this skill handle multi-component system failures?

It uses diagnostic instrumentation at component boundaries to log data entry and exit points, allowing the AI to pinpoint exactly which layer is failing before investigating that specific component.

Systematic Debugging

Name: Systematic Debugging
Author: maslennikov-ig

bymaslennikov-ig

•

Security & Testing

Enforces a rigorous, four-phase debugging methodology to identify root causes and ensure reliable software fixes without guesswork.

About

The Systematic Debugging skill transforms Claude's troubleshooting capabilities by enforcing the 'Iron Law': no fixes without prior root cause investigation. It guides the AI through a structured workflow—Root Cause Investigation, Pattern Analysis, Hypothesis Testing, and Implementation—to prevent wasteful 'guess-and-check' cycles and architectural debt. This skill is particularly valuable for complex multi-component systems, intermittent failures, and deep-seated bugs where quick patches often fail or introduce new regressions, ensuring that every fix addresses the source rather than just the symptoms.

Key Features

Diagnostic instrumentation for evidence gathering across multi-component boundaries
Architectural 'circuit breaker' that triggers design reviews after three failed fix attempts
Recursive data-flow tracing to find the origin of corrupted values
29 GitHub stars
Strict four-phase investigation protocol to prevent premature code changes
Mandatory TDD-driven implementation requiring a failing test case before any fix

Use Cases

Identifying the source of data corruption across multiple API and database layers
Debugging complex race conditions or intermittent failures in distributed architectures
Troubleshooting unstable legacy codebases where 'quick fixes' have historically failed

About

Key Features

Diagnostic instrumentation for evidence gathering across multi-component boundaries
Architectural 'circuit breaker' that triggers design reviews after three failed fix attempts
Recursive data-flow tracing to find the origin of corrupted values
29 GitHub stars
Strict four-phase investigation protocol to prevent premature code changes
Mandatory TDD-driven implementation requiring a failing test case before any fix

Use Cases

Identifying the source of data corruption across multiple API and database layers
Debugging complex race conditions or intermittent failures in distributed architectures
Troubleshooting unstable legacy codebases where 'quick fixes' have historically failed