Systematic methodology for debugging bugs, test failures, and unexpected behavior. Use when encountering any technical issue before proposing fixes. Covers root cause investigation, pattern analysis, hypothesis testing, and fix implementation. Use ESPECIALLY when under time pressure, "just one quick fix" seems obvious, or you've already tried multiple fixes. NOT for exploratory code reading.
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.
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
BEFORE attempting ANY fix:
Read Error Messages Carefully
Reproduce Consistently
Check Recent Changes
Gather Evidence in Multi-Component Systems
When system has multiple components (CI -> build -> signing, API -> service -> database):
For EACH component boundary:
- Log what data enters component
- Log what data exits component
- Verify environment/config propagation
Run once to gather evidence showing WHERE it breaks
THEN analyze to identify failing component
Trace Data Flow
See references/root-cause-tracing.md for backward tracing technique.
Quick version: Where does bad value originate? Keep tracing up until you find the source. Fix at source, not symptom.
Create Failing Test Case - Simplest reproduction, automated if possible
Implement Single Fix - ONE change, no "while I'm here" improvements
Verify Fix - Test passes? No regressions?
If Fix Doesn't Work:
If 3+ Fixes Failed: Question Architecture
Pattern indicating architectural problem:
STOP. Discuss with user before attempting more fixes.
If you catch yourself thinking:
ALL of these mean: STOP. Return to Phase 1.
When you fix a bug, validate at EVERY layer:
| Layer | Purpose | Example |
|-------|---------|---------|
| Entry Point | Reject invalid input at API boundary | if (!dir) throw new Error('dir required') |
| Business Logic | Ensure data makes sense for operation | Validate before processing |
| Environment Guards | Prevent dangerous ops in specific contexts | Refuse git init outside tmpdir in tests |
| Debug Instrumentation | Capture context for forensics | Log with stack trace before dangerous ops |
Single validation feels sufficient, but different code paths bypass it. Make bugs structurally impossible.
Flaky tests guess at timing. Wait for actual conditions instead:
# BAD: Guessing at timing
await asyncio.sleep(0.05)
result = get_result()
# GOOD: Wait for condition
await wait_for(lambda: get_result() is not None)
result = get_result()
Pattern:
async def wait_for(condition, timeout_ms=5000):
start = time.time()
while True:
if condition():
return
if (time.time() - start) * 1000 > timeout_ms:
raise TimeoutError("Condition not met")
await asyncio.sleep(0.01) # Poll every 10ms
| Excuse | Reality | |--------|---------| | "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. | | "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. | | "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. | | "I see the problem, let me fix it" | Seeing symptoms != understanding root cause. | | "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
Run: python scripts/verify.py
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer