skill-debug

Debug software issues through a four-phase root-cause investigation workflow.

4.0k|369|Updated Jan 15, 2026
One-click install
npx skills add https://github.com/nyldn/claude-octopus --skill skill-debug-nyldn
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: skill-debug
Source: https://github.com/nyldn/claude-octopus/tree/main/skills/skill-debug
Command: npx skills add https://github.com/nyldn/claude-octopus --skill skill-debug-nyldn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Systematic debugging workflow to prevent patch-based firefighting by enforcing root-cause investigation before fixes.

Core Features & Use Cases

  • Phase 1: Root Cause Investigation – read error messages, reproduce consistently, check recent changes, and gather evidence across components.
  • Phase 2: Pattern Analysis – locate working examples, compare against references, and identify differences.
  • Phase 3: Hypothesis and Testing – form a single hypothesis, test minimally, and iterate until confirmed.
  • Phase 4: Implementation – create a failing test, implement a single fix, and verify the resolution.
  • Red Flags – guardrails to halt when fundamental architecture issues arise and promote systematic debugging.

Quick Start

Initiate Phase 1: root cause investigation to reproduce the bug, gather evidence, and trace data flow.

Frequently Asked Questions about skill-debug

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

FAQPage Schema
What is a systematic root-cause debugging workflow for software engineering?

A systematic root-cause debugging workflow enforces evidence gathering, pattern analysis, and hypothesis testing before implementing fixes. It prevents patch-based firefighting by requiring a structured four-phase process to identify and resolve bugs across software engineering projects.

How do I fix recurring production bugs without patch-based firefighting?

To fix production bugs without firefighting, reproduce the issue consistently, gather evidence across components, and form a single hypothesis. You then create a failing test, implement a single fix, and verify the resolution with guardrails to ensure the root cause is resolved.

Can I use this debugging workflow for performance problems and integration issues?

Yes, you can use this debugging workflow for performance problems, integration issues, test failures, and production bugs. It applies a structured pattern analysis and hypothesis testing approach to identify root causes across diverse software engineering scenarios.

What's the best way to verify a bug fix and prevent regressions?

The best way to verify a bug fix is to require a failing test before implementing the code change. After the single fix is applied, run verification tests and guardrails to validate the resolution and confirm the root cause is eliminated without regressions.

When should I stop debugging and reconsider my software architecture?

You should stop debugging and reconsider your architecture when red flags or guardrails indicate fundamental architecture issues. The workflow halts the debugging process if pattern analysis or hypothesis testing reveals systemic problems rather than isolated bugs.