OpenCLI AutoFix, Automatic Adapter Self-Repair

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.

Safety Boundaries

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.
• CAPTCHA / rate limiting, STOP. Not an adapter issue.

Scope constraint:

• Only modify the file at adapterSourcePath in the trace summary.md front matter, this is the authoritative adapter location (may be clis/<site>/ in repo or ~/.opencli/clis/<site>/ for npm installs)
• Never modify src/, extension/, tests/, package.json, or tsconfig.json

Retry budget: Max 3 repair rounds per failure. If 3 rounds of diagnose → fix → retry don't resolve it, stop and report what was tried.

Prerequisites

opencli doctor    # Verify extension + daemon connectivity

When to Use This Skill

Use when opencli <site> <command> fails with repairable errors:

• SELECTOR, element not found (DOM changed)
• EMPTY_RESULT, no data returned (API response changed)
• API_ERROR / NETWORK, endpoint moved or broke
• PAGE_CHANGED, page structure no longer matches
• COMMAND_EXEC, runtime error in adapter logic
• TIMEOUT, page loads differently, adapter waits for wrong thing

Before Entering Repair: "Empty" ≠ "Broken"

EMPTY_RESULT, and sometimes a structurally-valid SELECTOR that returns nothing, is often not an adapter bug. Platforms actively degrade results under anti-scrape heuristics, and a "not found" response from the site doesn't mean the content is actually missing. Rule this out before committing to a repair round: