debugging-systematic

Enforce a four-phase hypothesis-driven debugging loop with a three-strikes escalation rule.

Updated Feb 20, 2026
One-click install
npx skills add https://github.com/jota-batuta/batuta-dots --skill debugging-systematic-jota-batuta
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debugging-systematic
Source: https://github.com/jota-batuta/batuta-dots/tree/main/BatutaClaude/skills/debugging-systematic
Command: npx skills add https://github.com/jota-batuta/batuta-dots --skill debugging-systematic-jota-batuta

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Replaces guesswork with a disciplined, hypothesis-driven debugging methodology that guides engineers through a repeatable four-phase workflow for investigating and resolving bugs, including a hard-gate when three fix attempts fail.

Core Features & Use Cases

  • The Four-Phase Debugging Loop: Investigate, Analyze, Hypothesize and Test, Fix, with a mandatory evaluation gate after three failed fixes.
  • The Three Strikes Rule: escalates to architectural review when fixes fail thrice to prevent patching systemic issues.
  • Loop Detection: circuit-breaker style safeguards that halt repeated failing attempts and surface root-cause classifications.
  • Error Classification & Decision Trees: structured categorization to guide investigation, experimentation, and logging.
  • Strategic Logging Guidance: minimum, purpose-driven logs at decision points and boundaries to capture reasoning and results.
  • Git Bisect for Regressions: recommended practice to identify the exact commit introducing a bug.
  • Escalation & Documentation Paths: clear routes for multi-tenant and architectural concerns to ensure safe handoffs.

Quick Start

Start by identifying the bug, then follow the four-phase debugging loop—Investigate, Analyze, Hypothesize and Test, Fix—and apply the three-strikes rule if fixes fail.

Frequently Asked Questions about debugging-systematic

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

FAQPage Schema
What is hypothesis-driven debugging and how does it reduce guesswork?

Hypothesis-driven debugging replaces guesswork with a disciplined, four-phase loop—Investigate, Analyze, Hypothesize and Test, Fix—enforcing structured error classification and decision trees to guide systematic bug resolution.

How do I stop repeatedly applying failing fixes to production bugs or flaky tests?

To stop repeated failing fixes, apply a three-strikes escalation rule that halts patching after three failed attempts and triggers an architectural review to address systemic root causes instead of symptoms.

What's the best way to find the exact commit that introduced a regression?

The best way to identify the exact commit introducing a regression is using git bisect, a recommended practice within the debugging workflow to systematically narrow down the commit range and pinpoint the root cause.

Can I use this systematic debugging workflow for multi-project triage scenarios?

Yes, this hypothesis-driven debugging workflow is applicable to software development teams facing flaky tests, production bugs, regressions, or complex triage scenarios across multiple projects with clear escalation and documentation paths.

How do I detect when I am stuck in a debugging loop with no progress?

Debugging loop detection uses circuit-breaker style safeguards to halt repeated failing attempts, surfacing root-cause classifications and preventing cyclical fixes when three consecutive attempts fail to resolve the bug.

When should I escalate a bug fix instead of continuing to patch it?

You should escalate a bug fix when three consecutive fix attempts fail, triggering the three-strikes rule for architectural review, or when the investigation surfaces multi-tenant and architectural concerns requiring safe handoffs.

Related Skills