debugging-patterns

Enforce root-cause investigation before applying fixes in debugging workflows.

161|25|Updated Oct 22, 2025

Search Tags:#debugging #trace #diagnostics #evidence #phases #root-cause

Ready to run

npx skills add https://github.com/romiluz13/cc10x --skill debugging-patterns-romiluz13

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: debugging-patterns
Source: https://github.com/romiluz13/cc10x/tree/main/plugins/cc10x/skills/debugging-patterns
Command: npx skills add https://github.com/romiluz13/cc10x --skill debugging-patterns-romiluz13

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Systematic debugging patterns that prevent patchwork fixes and ensure root cause investigation before applying changes.

Core Features & Use Cases

Iron Laws: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
Four Phases: Root Cause Investigation, Pattern Analysis, Hypothesis & Testing, Implementation.
Evidence gathering: Logs, traces, and data flow at each boundary.
Use Case: Debugging a flaky API where symptoms point to multiple components.

Quick Start

Always complete Phase 1 (Root Cause Investigation) before proposing fixes; gather evidence and trace data to identify the failing component.

Frequently Asked Questions about debugging-patterns

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

FAQPage Schema

How do I debug issues systematically instead of applying quick fixes?▼

Root-cause debugging enforces a structured four-phase process: investigate the root cause first, analyze patterns in evidence, form and test hypotheses, then implement a minimal fix. This prevents patchwork solutions by gathering logs, traces, and data flow evidence across component boundaries before any change.

What's the best way to troubleshoot flaky tests and production bugs?▼

Apply mandatory diagnostic phases: trace failures across all components, capture evidence at each boundary, reproduce the issue consistently, and identify the single failing component. Only after root cause is confirmed do you propose and verify a fix addressing the actual problem, not symptoms.

How do I gather evidence and trace data when debugging performance problems?▼

Collect logs, traces, and data flow at component boundaries during the Root Cause Investigation phase. Document reproducibility steps and cross-component evidence before hypothesis testing. This data capture ensures you identify whether the issue originates in a specific component or emerges from interactions between systems.

Why does my debugging often lead to incomplete fixes that create new problems?▼

Patchwork debugging skips root cause investigation and applies surface-level fixes. The structured process enforces mandatory evidence gathering and reproducibility before implementation, ensuring fixes address root causes. Verification steps confirm the fix resolves the actual failure, not just a symptom.

Can I apply this debugging approach to build failures and integration issues?▼

Yes, the four-phase workflow applies to all technical issues: test failures, production bugs, unexpected behavior, performance problems, and build or integration failures. The same root-cause investigation, pattern analysis, hypothesis testing, and verification steps work across any domain where rapid guessing tempts quick patches.

What happens if I skip the Root Cause Investigation phase?▼

Skipping phase one violates the core law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. Without evidence and traced failure data, you risk implementing fixes that address symptoms rather than root causes, perpetuating patchwork debugging and creating cascading failures.