菜单
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when managing the Claude CLI Proxy (ban protector) — start, stop, restart, status, logs, backup, test, setup, or register the proxy in OpenClaw. Triggers on: 'proxy status', 'ban protector', 'start proxy', 'stop proxy', 'proxy health', 'antiban', 'cli proxy'.
Run stateful multi-agent graph workflows using LangGraph (linear, supervisor, parallel, conditional). Use when tasks need dynamic routing, branching logic, or a supervisor agent delegating work. All LLM calls use OpenClaw's existing provider config — no API keys needed. Choose over autogen-collab (debate) and crewai-collab (fixed pipelines) when you need conditional edges, a supervisor making routing decisions, or parallel fan-out with synthesis.
Run multi-agent AutoGen-style debates when tasks need consensus across specialists. Uses OpenClaw's existing provider configuration — no API keys or extra setup needed. Use when: architecture decisions, design reviews, root cause analysis, or complex research where multiple expert perspectives improve the answer. Triggered automatically by Cooper for high-complexity tasks or explicitly via [autogen] tag or "debate this" / "get consensus" instructions.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Run structured multi-agent workflows using CrewAI (sequential, hierarchical, consensus). Each agent has a defined role, goal, and backstory. Tasks have explicit expected outputs. Use when: structured pipelines (research → design → implement), manager-supervised workflows, or consensus-building with clear acceptance criteria. All LLM calls use OpenClaw's existing provider config — no API keys needed.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
| name | systematic-debugging |
| description | Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes |
| metadata | {"openclaw":{"emoji":"🔍"}} |
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 (CI to build to signing, API to service to database):
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
WHEN error is deep in call stack:
See references/root-cause-tracing.md for the complete backward tracing technique.
Quick version:
Find the pattern before fixing:
Find Working Examples
Compare Against References
Identify Differences
Understand Dependencies
Scientific method:
Form Single Hypothesis
Test Minimally
Verify Before Continuing
When You Don't Know
Fix the root cause, not the symptom:
Create Failing Test Case
Implement Single Fix
Verify Fix
If Fix Doesn't Work
If 3+ Fixes Failed: Question Architecture
Pattern indicating architectural problem:
STOP and question fundamentals:
Discuss with the user before attempting more fixes
This is NOT a failed hypothesis - this is a wrong architecture.
If you catch yourself thinking:
ALL of these mean: STOP. Return to Phase 1.
If 3+ fixes failed: Question the architecture (see Phase 4.5)
| 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'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. |
| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
| "I see the problem, let me fix it" | Seeing symptoms does not equal understanding root cause. |
| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
| 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 |
If systematic investigation reveals issue is truly environmental, timing-dependent, or external:
But: 95% of "no root cause" cases are incomplete investigation.
These techniques are part of systematic debugging and available in references/:
references/root-cause-tracing.md - Trace bugs backward through call stack to find original triggerreferences/defense-in-depth.md - Add validation at multiple layers after finding root causereferences/condition-based-waiting.md - Replace arbitrary timeouts with condition pollingRelated skills:
From debugging sessions: