| name | debug-for-openclaw |
| description | Triage and resolve failures inside an OpenClaw workspace with a disciplined debugging loop. Use when the request sounds like "help me debug this", "this test is failing", "the build broke", "this works sometimes and I do not know why", or when logs suggest a problem but not the cause. |
Debug For OpenClaw
Debug by narrowing uncertainty, not by guessing fixes.
Process
- Reproduce the problem as concretely as possible.
- Define the observed behavior and the expected behavior.
- Localize the failure surface before editing code.
- Reduce the problem to the smallest reproducible case you can get.
- Form one strong hypothesis at a time.
- Change the narrowest possible surface.
- Re-run the proof.
- Add a guard so the same class of failure is less likely to return.
OpenClaw Guidance
- Prefer first-class tools for inspection when available.
- Use browser-based inspection for UI/runtime bugs when the issue is visible in the browser.
- Use logs and traces as evidence, not as a substitute for reproduction.
- If the bug spans many files, re-enter the planning loop before patching blindly.
Reference Files
Read references/triage-loop.md when debugging is getting noisy or speculative.
Read references/failure-patterns.md when the failure is intermittent, followed a refactor, or appeared after config or environment changes.
Read references/localization-strategies.md when the bug surface is still too broad and you need to shrink the search space.
Bad Patterns
- changing code before reproducing the bug
- stacking multiple speculative fixes
- using a passing unrelated test as proof
- stopping at symptom removal without understanding cause
