// Systematic debugging methodology for diagnosing failures and root cause analysis. Triggers on: 2+ failed fix attempts, 'ultradebug', 'uld', debugging in circles, complex system failures, intermittent bugs.
MUST be used for ANY git workflow that involves committing code. This includes explicit commit requests AND implicit ones like 'ship it', 'wrap it up', or finishing implementation work. Handles staging, message generation, validation, and commit execution with conventional commit format.
How to handle code review feedback with technical rigor. Use when receiving review comments from code-reviewer agent, PR reviews, or external feedback. Triggers on: 'review feedback', 'address review', 'fix review comments', 'code review response'.
Systematic TDD methodology for writing tests first. Use when implementing features or fixes with OMC_TDD_MODE enabled, when unsure how to structure tests, or when test-first discipline needs reinforcement. Triggers on: 'tdd', 'test first', 'test driven', 'red green refactor'.
Evidence-based verification methodology before claiming work is complete. Use when about to claim work is done, before committing, before creating PRs, or when verification-reminder hook fires. Triggers on: 'verify', 'verification', 'is it done', 'complete', 'ready to merge'.
Methodology for creating effective skills using TDD principles. Use when creating new skills, editing existing skills, or authoring plugin components. Triggers on: 'create skill', 'write skill', 'new skill', 'skill authoring'.
Initialize or migrate to nested CLAUDE.md structure for progressive disclosure. Claude auto-loads CLAUDE.md from any directory it reads, enabling true contextual guidance. Triggers on: '/init-deep', 'deep init', 'initialize deeply', 'setup claude deeply', 'refactor claude.md', 'migrate claude.md', 'nested claude', 'progressive disclosure'.
| name | debugger |
| description | Systematic debugging methodology for diagnosing failures and root cause analysis. Triggers on: 2+ failed fix attempts, 'ultradebug', 'uld', debugging in circles, complex system failures, intermittent bugs. |
Systematic debugging methodology for diagnosing failures and root cause analysis.
Before investigating, articulate:
Always generate multiple hypotheses, ranked by likelihood:
Most Likely:
Possible:
Unlikely but worth checking:
Test hypotheses in order. For each:
When choosing between approaches:
| Factor | Weight | Considerations |
|---|---|---|
| Correctness | Critical | Does it actually solve the problem? |
| Simplicity | High | Prefer boring solutions over clever ones |
| Leverage | High | Use existing patterns/libraries/code |
| Developer Experience | Medium | How hard is it to debug/maintain? |
| Performance | Low* | *Unless performance IS the problem |
Tag recommendations by effort:
| Tag | Meaning | Example |
|---|---|---|
| [Quick] | <30 min | Add logging, check config |
| [Short] | 30min-2hr | Refactor function, add test |
| [Medium] | 2hr-1day | New component, integration |
| [Large] | >1 day | Architecture change |
| Pattern | Signal | Investigation Focus |
|---|---|---|
| Fix-break cycle | Each fix causes new problem | Root cause analysis - treating symptoms not cause |
| Confusion | "I don't understand why X happens" | Add logging, trace execution path |
| Tradeoff paralysis | Multiple valid approaches | Use decision framework above |
| Integration hell | System A + B don't work together | Interface contracts, data formats |
| Heisenbug | Works sometimes, fails randomly | Timing, state, race conditions |
When debugging, structure findings as:
## Problem Understanding
{Restate in own words. Challenge framing if wrong.}
## Hypotheses (Ranked)
1. Most Likely: {hypothesis} - Evidence: {support} - Test: {verification}
2. Possible: {hypothesis} - Evidence: {support} - Test: {verification}
3. Unlikely: {hypothesis} - Evidence: {limited} - Test: {quick check}
## Recommended Approach
{Specific next steps. Be prescriptive.}
## Traps to Avoid
{What NOT to do for this specific problem.}