systematic-debugging

Diagnose software bugs using hypothesis-driven investigation and isolation techniques.

1|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/dominionism/Noesis --skill systematic-debugging-dominionism
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/dominionism/Noesis/tree/main/assets/skills/systematic-debugging
Command: npx skills add https://github.com/dominionism/Noesis --skill systematic-debugging-dominionism

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Debugging often devolves into random code changes until the bug seems to disappear, masking root causes and wasting hours. This Skill enforces a disciplined, hypothesis-driven methodology that finds the actual root cause instead of treating symptoms. ## Core Features & Use Cases - Five-Step Method: Reproduce the bug, form a falsifiable hypothesis, test one variable at a time, isolate the root cause with Five Whys, then fix and verify with a regression test. - Isolation Techniques: Choose from binary search (git bisect), differential debugging, trace logging, rubber duck explanation, and minimal reproduction based on what you know about the bug. - Cognitive Bias Guardrails: Built-in countermeasures for confirmation bias, anchoring, recency bias, and availability bias that derail investigations. - Time-Boxing Rules: Escalation triggers at 15 minutes, 30 minutes, 1 hour, and 2 hours to force approach changes before you get stuck. - Use Case: A production bug where order data appears stale. Instead of guessing, you reproduce it, hypothesize that cache invalidation is missing after order creation, confirm with a single log line, trace the root cause to missing integration test coverage, and ship both the fix and the test. ## Quick Start Ask the AI to apply the systematic debugging method to investigate why your endpoint returns stale data, starting with reproduction steps and a falsifiable hypothesis.

Frequently Asked Questions about systematic-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a bug systematically instead of guessing?▼

Follow the five-step method: reproduce the bug reliably, form a specific falsifiable hypothesis naming a location and mechanism, test it by changing one variable, trace the root cause with Five Whys, then fix and verify with a regression test.

How to find which commit introduced a regression?▼

Use binary search via git bisect. Mark a known good commit and the current bad commit, then git tests midpoints automatically until it identifies the exact breaking change. This works best when you have an automated test to run at each step.

What should I do when a bug works on my machine but fails in production?▼

Use differential debugging. List every difference between the working and broken environments (data, config, versions, users), then align one dimension at a time. When aligning a dimension fixes the broken case, that dimension contains the cause.

Why does changing multiple things at once make debugging harder?▼

Changing multiple things simultaneously means you cannot tell which change fixed the bug, and you may have masked it instead of fixing it. Test one variable at a time so each experiment proves or disproves a single hypothesis.

When should I stop debugging and try a different approach?▼

Follow the time-boxing rules: re-check reproduction steps at 15 minutes, switch isolation techniques at 30 minutes, explain the problem out loud at 1 hour, and step away or pair with someone after 2 hours without progress.

How do I know when debugging is actually complete?▼

Debugging is complete when the root cause is identified, a test exists that fails before the fix and passes after, the original reproduction no longer shows the bug, related code patterns are checked, and the fix contains no unrelated changes.