systematic-debugging
This skill enforces disciplined debugging by requiring root cause investigation before any fix attempt. It walks through four phases: isolating the problem through error analysis and reproduction, comparing working patterns against broken code, forming and testing a single hypothesis, and finally implementing the fix while catching architectural issues that multiple failed attempts reveal.
Systematic Debugging guides you through a 4-phase root cause investigation before attempting any fix.
AI-generated summary based on this skill's SKILL.md
Install
moltis-org/moltis/systematic-debugging · repository language: Rust
git clone https://github.com/moltis-org/moltis
cp -r moltis/crates/skills/src/assets/software-development/systematic-debugging ~/.claude/skills/systematic-debuggingnpx skillfed install moltis-org/moltis/systematic-debuggingFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do I debug a failing test systematically?
systematic-debugging guides you through four phases: first, isolate the problem by analyzing error messages and reproducing the failure consistently; second, compare working patterns against broken code to spot differences; third, form and test a single hypothesis about the root cause; fourth, implement your fix while watching for architectural issues that repeated failures might reveal. This structured approach prevents wasted time on symptom fixes.
What's the right way to find the root cause of a bug before fixing?
systematic-debugging emphasizes investigating before implementing. Start by reproducing the bug consistently, then trace data flow to identify which component is actually failing—not where the symptom appears. Compare working and broken code paths, form one testable hypothesis, and verify it before touching any code. This discipline catches architectural problems that random patching would miss.
How can I trace data flow to find where a bug originates?
systematic-debugging teaches you to follow the four-phase process: isolate by reproducing the failure, compare working versus broken behavior, form a hypothesis about the root cause, then test it. By tracing function calls and data transformations systematically rather than guessing, you discover where the bug actually starts—not just where it shows up as a symptom.
Why should I investigate test failures before attempting fixes?
systematic-debugging enforces this discipline because investigating first reveals whether you're fixing a real root cause or just masking a symptom. The four-phase process—isolate, compare, hypothesize, test—helps you recognize when architectural problems exist rather than continuing to patch surface issues. This prevents wasted effort and catches deeper design flaws.
What's the systematic approach to fixing errors without guessing?
systematic-debugging provides a structured four-phase workflow: phase one isolates the problem through error analysis and consistent reproduction; phase two compares working patterns against broken code; phase three forms and tests a single hypothesis; phase four implements the fix while catching architectural issues. Following this methodology prevents random fixes and ensures you're solving the actual problem.
How do I know if my fix is addressing a real problem?
systematic-debugging requires you to trace the root cause before implementing any solution. By systematically investigating and reproducing issues, comparing working and broken code, and forming testable hypotheses, you verify the fix solves the actual problem rather than a symptom. This disciplined approach ensures your fix is real and prevents architectural problems from hiding under repeated failed attempts.
SKILL.md
rendered from the published skill — quoted content, verbatim
Systematic Debugging
Overview
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
Violating the letter of this process is violating the spirit of debugging.
The Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
When to Use
Use for ANY technical issue: - Test failures - Bugs in production - Unexpected behavior - Performance problems - Build failures - Integration issues
Use this ESPECIALLY when: - Under time pressure (emergencies make guessing tempting) - "Just one quick fix" seems obvious - You've already tried multiple fixes - Previous fix didn't work - You don't fully understand the issue
Don't skip when: - Issue seems simple (simple bugs have root
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 1 file
crates/skills/src/assets/software-development/systematic-debugging/SKILL.md