
When an OpenCLI adapter breaks because a website changed its DOM or API, this walks you through diagnostic mode, shows you how to patch the specific adapter file, and retries the command. It enforces safety boundaries (stops on auth errors, never touches core source files, max 3 repair rounds) and helps you distinguish real breakage from normal "empty result" responses that look broken but aren't. The workflow is systematic: run with OPENCLI_DIAGNOSTIC=1 to get a JSON context dump, use opencli browser to explore what changed, edit the adapter at the exact path it gives you, verify. Useful if you're running OpenCLI commands in automation and want to self-heal adapter drift instead of waiting for upstream fixes.
$ npx -y skills add joeseesun/opencli-skill --skill qiaomu-opencli-autofix --agent claude-codeInstalls into .claude/skills of the current project.
When an opencli command fails because a website changed its DOM, API, or response schema, automatically diagnose, fix the adapter, and retry — don't just report the error.
Before starting any repair, check these hard stops:
AUTH_REQUIRED (exit code 77) — STOP. Do not modify code. Tell the user to log into the site in Chrome.BROWSER_CONNECT (exit code 69) — STOP. Do not modify code. Tell the user to run opencli doctor.Scope constraint:
RepairContext.adapter.sourcePath — this is the authoritative adapter location (may be clis/<site>/ in repo or ~/.opencli/clis/<site>/ for npm installs)src/, extension/, tests/, package.json, or tsconfig.jsonRetry budget: Max 3 repair rounds per failure. If 3 rounds of diagnose → fix → retry don't resolve it, stop and report what was tried.
opencli doctor # Verify extension + daemon connectivity
Sponsors