com um clique
debugger
// Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
// Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when coding standards, security patterns, or project conventions need to be discovered before implementation begins.
Install context files from registry. Use when user runs /install-context, says "install context", "setup context", or when context is missing and the user needs to get started.
Use when the task involves an external library or package and current API docs are needed before writing code.
Use before any implementation — understands the request, discovers project context, and proposes a concise plan for user approval before writing any code.
Use when starting any conversation — establishes how to find and use OAC skills, requiring Skill tool invocation BEFORE ANY response including clarifying questions, this is your secret weapon to best perform your tasks
Orchestrate multi-agent workflows for feature development using planning agents, context handoff, and stage management
| name | debugger |
| description | Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes |
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
Violating the letter of this process is violating the spirit of debugging.
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
Use for ANY technical issue:
Use this ESPECIALLY when:
Don't skip when:
You MUST complete each phase before proceeding to the next.
BEFORE attempting ANY fix:
Read Error Messages Carefully
Reproduce Consistently
Check Recent Changes
Gather Evidence in Multi-Component Systems
WHEN system has multiple components:
BEFORE proposing fixes, add diagnostic instrumentation:
For EACH component boundary:
- Log what data enters component
- Log what data exits component
- Verify environment/config propagation
- Check state at each layer
Run once to gather evidence showing WHERE it breaks
THEN analyze evidence to identify failing component
THEN investigate that specific component
Trace Data Flow
Find the pattern before fixing:
Scientific method:
Fix the root cause, not the symptom:
Create Failing Test Case — Simplest possible reproduction. MUST have before fixing.
Implement Single Fix — Address the root cause. ONE change at a time.
Verify Fix — Test passes? No other tests broken? Issue actually resolved?
If Fix Doesn't Work — STOP. Count fixes tried. If ≥ 3: question the architecture.
If 3+ Fixes Failed: Question Architecture
If you catch yourself thinking:
ALL of these mean: STOP. Return to Phase 1.
| Excuse | Reality |
|---|---|
| "Issue is simple, don't need process" | Simple issues have root causes too. |
| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check. |
| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. |
| Phase | Key Activities | Success Criteria |
|---|---|---|
| 1. Root Cause | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
| 2. Pattern | Find working examples, compare | Identify differences |
| 3. Hypothesis | Form theory, test minimally | Confirmed or new hypothesis |
| 4. Implementation | Create test, fix, verify | Bug resolved, tests pass |
Related skills:
oac:verification-before-completion — Verify fix worked before claiming successoac:test-generation — For creating failing test cases (Phase 4, Step 1)