hopper-setuplisted

Use when the user wants a Hopper vendor readiness check or doctor — which vendor CLIs are installed and authenticated, which support sandbox control or web search, cached/known models, and (with --deep) live model-catalog drift. Triggers: 'hopper setup', 'hopper doctor', 'are my vendors ready', 'check vendor health', 'which vendors can I dispatch to'.
litianyi-007/hopper-plugin · ★ 0 · AI & Automation · score 70

Install: claude install-skill litianyi-007/hopper-plugin

# Hopper Setup / Doctor Report per-vendor readiness before dispatching: installed? · authenticated? · sandbox control · web-search · models · capability freshness. This is the consolidated `--setup` / `--doctor` diagnostic — a read-only registry+filesystem check that does NOT need a `.hopper/` project directory, so it runs from anywhere. ## Steps 1. Locate `hopper-dispatch` from `PATH` or the plugin root near this `SKILL.md` (no `.hopper/` project lookup is required — `--setup` computes from the static adapter registry plus per-vendor install/auth checks). 2. Run the readiness report: - All vendors: `hopper-dispatch --setup` (alias: `hopper-dispatch --doctor`). - One vendor: `hopper-dispatch --setup <vendor>`. - Deep diagnostics: add `--deep` to also check flag/parameter drift (`<vendor> --help` vs the flags the adapter emits) AND reconcile each vendor's live-enumerated model catalog against the hardcoded `knownGood` defaults. `--deep` spawns `<vendor> --help` and the model-enumeration probe once per vendor and refreshes the probe cache. 3. Surface the table. Guidance for routing the next task: - Confirm Installed=yes + Auth=ok before routing to a vendor. For Grok, `auth_context` is deliberately `unverified` (`key-present-unverified`, `credential-artifact-present-unverified`, `not-detected`, or `unknown`): it is a zero-spawn local context signal for the Hopper Node parent, not remote-auth proof. Interactive/browser state in another session may not be inherited.