Tech Bug Troubleshooting Team

Bug 排查工作流

Use this as the entry skill when the user wants a complete software bug investigation and fix, rather than a single error explanation.

Operating model

Start by choosing the smallest workflow that can solve the bug. For simple pasted errors, use nexus-error-explain or code-error-fixer locally. For repo bugs, build an evidence chain first, then edit. For broad failures, coordinate the specialized skills below.

When the user explicitly asks for multi-agent execution and subagents are available, split only independent sidecar work:

• Log timeline and error-pattern analysis: log-analyzer
• Reproduction and environment investigation: debug-pro
• Stack trace and code-level diagnosis: code-error-fixer
• Root-cause discipline and hypothesis testing: superpowers-systematic-debugging
• Fix implementation, impact scan, and regression verification: bug-fixing-openclaw

Keep the immediate blocking task in the main agent. Do not make multiple agents edit the same files. Ask worker agents to report changed files and evidence.

Workflow

1. Collect evidence

   • Read the exact error, logs, stack trace, failing test, route, request, or reproduction steps.
   • If logs are available, use log-analyzer to extract key events, timestamps, request IDs, repeated patterns, and first failure.
   • Capture current repo state before editing so user changes are protected.

2. Reproduce and isolate

   • Use debug-pro to confirm environment, run the failing command, and isolate the smallest reliable reproduction.
   • If reproduction is impossible, state what evidence is missing and continue only with a clearly labeled hypothesis.

3. Diagnose the code path

   • Use code-error-fixer for compiler/runtime/type/dependency errors and stack traces.
   • Trace bad values back to their source instead of fixing at the symptom site.
   • Compare with nearby working examples in the same repo.

4. Test hypotheses

   • Use superpowers-systematic-debugging to keep the investigation evidence-based.
   • Each likely root cause should have a verification step: command output, log change, failing/passing test, runtime screenshot, or code-path proof.

5. Fix with impact control

   • Use bug-fixing-openclaw for severity, affected-surface scan, fix implementation, and regression checks.
   • Keep fixes minimal and avoid unrelated refactors.
   • For UI bugs, gather runtime evidence before changing UI code when a browser or app runtime is available.

6. Verify and package the result

   • Re-run the failing command plus the narrowest relevant regression checks.
   • Confirm the fixed code path is actually loaded by the runtime when applicable.
   • Deliver a concise report with root cause, changed files, verification commands, residual risk, and follow-up recommendations.

External service guardrail

nexus-error-explain contains optional external paid-service instructions from the source package. In Codex, use local reasoning by default. Do not call network/payment endpoints unless the user explicitly asks to use NEXUS and confirms credentials, cost, and network access.

Final report shape

Use this shape for substantial bug work:

**Root Cause**
[What failed and why.]

**Fix**
[Files changed and behavior corrected.]

**Verification**
[Commands or runtime checks performed.]

**Notes**
[Residual risk, missing evidence, or follow-up.]