BugDoctor for Openclaw

BugDoctor guides an AI coding agent from a reported software failure to an evidence-supported diagnosis, scoped remedy, and verified outcome.

redrookai
v0.1.0
Oct 12, 2026
0
55
0

Install & Download

1. ClawHub CLI

The fastest way to install a skill directly from the registry.

npx clawhub@latest install bugdoctor

2. Manual Installation

Copy the skill folder to one of these locations

Global
~/.openclaw/skills/
Workspace
<project>/skills/

Priority: Workspace > Local > Bundled

3. Prompt Installation

Copy this prompt to OpenClaw to install it automatically.

Help me install bugdoctor using Clawhub. If Clawhub is not installed, install it first (npm i -g clawhub).

Prefer to download?

Get the raw skill files in a ZIP archive.

What is BugDoctor?

BugDoctor is an investigation and repair workflow for software errors, regressions, and recurring failures. It helps an agent combine local evidence—such as logs, code, configuration, tests, and runtime behavior—with applicable documentation, incident history, and focused web research to identify a supported cause and the smallest suitable remedy.

Unlike a generic troubleshooting checklist, BugDoctor emphasizes applicability: it checks the actual target, version, trigger, and operational context; distinguishes observations from assumptions; and verifies the original failing behavior after an authorized repair. Among Openclaw Skills, it is designed to keep debugging focused, preserve useful work, and avoid unsupported fixes or unnecessary changes.

BugDoctor Use Cases

  • Diagnose an error, regression, or recurring failure using supplied context and accessible local evidence.
  • Trace a visible symptom through logs, code, configuration, or runtime behavior to its initiating cause.
  • Investigate whether a dependency, release, configuration, permission, or authentication behavior applies to the affected setup.
  • Compare plausible causes with a targeted, low-cost check when evidence is inconclusive.
  • Research distinctive errors, symbols, incidents, releases, and relevant technical prior art.
  • Apply a repair when the user has authorized changes, then check the reported failure and relevant contract boundaries.
  • Provide a concrete next diagnostic check when access or evidence is insufficient for a supported conclusion.

How BugDoctor Works

  1. Establish the attempted operation, expected and actual behavior, target version or build, environment, recent changes, and prior attempts.
  2. Gather relevant local evidence from logs, code, configuration, tests, documentation, or observed state; retain useful source and event pointers without dumping irrelevant data.
  3. Research only uncertainties that could change the diagnosis or remedy, checking current authoritative sources and applicable prior incidents or published work as warranted.
  4. Compare explanations against the actual trigger, operation, failure stage, environment, and version; distinguish verified outcomes from hypotheses and proposed fixes.
  5. If needed, run a targeted check or collect relevant runtime evidence to separate plausible explanations, then revise the diagnosis based on the result.
  6. Select the smallest supported remedy, checking compatibility, persisted state, running work, and whether an operation is safe to retry.
  7. If repair is authorized, make the minimum necessary change and verify the originally failing behavior, relevant boundary cases, and supported behavior that could be affected.
  8. Report the diagnosis or unresolved question first, followed by concise evidence, the applicable remedy or next check, and useful supporting links.

BugDoctor Setup

BugDoctor defines no package installation command, dependency, or standalone configuration format. Load it through the host agent's standard skill mechanism and use the agent's configured model and available tools. No additional collector, service, or dependency is required by the workflow.

Before using it, provide the reported failure and any relevant context available, such as the command or operation, expected result, actual result, software version, environment, recent changes, and previous attempts. The agent should obtain accessible evidence itself and ask only for missing information that could change the diagnosis. Repairs must remain within the user's authorization and existing permissions.

BugDoctor Data Schema & Taxonomy

BugDoctor specifies no mandatory database, generated file layout, or persistent metadata schema. It works with existing project and incident evidence, keeping relevant records scoped to the affected operation.

  • Evidence: Relevant logs, code, configuration, tests, documentation, observed state, and runtime traces. Preserve useful error codes, stable symbols, event sequences, and source, line, event, or run pointers.
  • Research: Applicable incidents, issue reports, discussions, pull requests, releases, technical sources, and—when relevant—published prior art. Track applicability to the actual project, dependency, provider, distribution, version, and setup.
  • Optional incident record: When asked to record an incident, use the existing format and include the trigger, target and version, decisive evidence, remedy, verification, relevant failed attempts, and exclusions.
  • Persistence boundaries: Running the skill alone does not authorize persistent instruction changes or creation of a new logging system. Remove only task-owned temporary instrumentation after it is no longer needed.

BugDoctor Advanced Features

  • Evidence-led differential diagnosis: Compare plausible causes against the real trigger and failure stage, then choose a low-cost check that can distinguish them.
  • Focused runtime investigation: Use existing debugger state, targeted logs or assertions, traces, profilers, query plans, or browser inspection when static evidence leaves a material question unresolved.
  • Research with applicability checks: Consult current primary documentation, incident histories, releases, implementations, and relevant arXiv prior art without treating search snippets or similarity as proof.
  • Contract and boundary validation: Trace values or state to where a contract first breaks, test another supported entry path, and use a contrast case to expose shared defects.
  • Repair authorization and scope controls: Make changes only when requested, preserve useful work, and avoid broad upgrades, restarts, or cleanup without demonstrated need.
  • Release and fix verification: Distinguish reported, proposed, merged, released, and locally verified fixes; account for branches, backports, forks, and custom builds.
  • Safe operational reasoning: Check whether work already completed before retrying, assess idempotency, and distinguish a checker or setup failure from a product failure.
  • Flexible evidence access: If browsing or source access is unavailable, use supplied or cached evidence with its date and state the relevant access gap.

SKILL.md


Loading

Related Openclaw Skills

METADATA

Github Stars: 0
forks: 0

Featured*