debug

Enforce a four-phase debugging process to identify and eliminate root-cause issues.

15|1|Updated Mar 29, 2026
One-click install
npx skills add https://github.com/duronext/jig --skill debug-duronext
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debug
Source: https://github.com/duronext/jig/tree/main/core/skills/debug
Command: npx skills add https://github.com/duronext/jig --skill debug-duronext

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Systematic debugging to consistently uncover the root cause of bugs, preventing guess-and-check thrashing by enforcing a four-phase process: investigation, pattern analysis, hypothesis testing, and implementation.

Core Features & Use Cases

  • Phase-driven debugging: Root Cause Investigation, Pattern Analysis, Hypothesis Testing, and Implementation guide the workflow.
  • Structured evidence gathering and data-flow tracing to isolate the failing component.
  • Reduces MTTR by driving systematic fixes and formal verification before deployment.

Quick Start

Describe the issue, then follow Phase 1 through Phase 4 to identify the root cause and implement a verified fix.

Frequently Asked Questions about debug

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

FAQPage Schema
What is systematic root-cause debugging and when do I need it?

Systematic root-cause debugging is a structured process to isolate and fix software failures by enforcing evidence collection and hypothesis testing. You need it to prevent guess-and-check thrashing when handling bug reports, test failures, or unexpected production behavior.

How do I debug software issues using a phase-based approach?

Debug software issues by following four phases: root cause investigation, pattern analysis, hypothesis testing, and implementation. This phased approach enforces structured evidence gathering, data-flow tracing, and formal verification before closing the issue to ensure reliable fixes.

What's the best way to reduce MTTR for unexpected production behavior?

The best way to reduce MTTR for unexpected production behavior is applying disciplined root-cause debugging. By driving systematic fixes through pattern analysis and requiring formal verification before deployment, teams resolve issues faster and prevent regressions.

How do I stop guess-and-check thrashing when fixing test failures?

Stop guess-and-check thrashing by enforcing a hypothesis-driven debugging workflow. Test failures are resolved by isolating the failing component through data-flow tracing, making minimal changes per hypothesis, and verifying the fix before closing the issue.

Can I use this debugging process for any software engineering project?

Yes, this debugging process applies across software engineering projects. It guides teams through investigation, analysis, hypothesis testing, and implementation regardless of the specific stack, requiring only structured phases and disciplined evidence collection to close issues.