
Opencli Usage
Orient any OpenCLI session so the agent knows adapters, universal flags, browser subcommands, and which specialized skill to load next.
Overview
opencli-usage is a journey-wide agent skill that maps what OpenCLI can do and how to pick the right adapter or browser workflow—usable whenever a solo builder needs to automate a site or CLI before committing to a one-of
Install
npx skills add https://github.com/jackwener/opencli --skill opencli-usageWhat is this skill?
- Top-level map for `opencli <site> <command>` adapter commands and discovery paths
- Documents five adapter strategies: PUBLIC, COOKIE, INTERCEPT, UI, LOCAL
- Points to `opencli browser *` for open, state, click, type, extract, and network when no adapter exists
- Covers current-tab binding via `opencli browser <session> bind` for logged-in Chrome tabs
- Entry skill before loading opencli-browser and domain-specific adapter skills
- 5 adapter strategy labels: PUBLIC, COOKIE, INTERCEPT, UI, LOCAL
Adoption & trust: 13.4k installs on skills.sh; 23.8k GitHub stars; 0/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent knows it should use OpenCLI but cannot discover adapters, strategies, or which specialized skill to load for browser vs passthrough work.
Who is it for?
Builders standardizing agent access to many web apps and CLIs through OpenCLI from day one of a session.
Skip if: Sessions with no OpenCLI installed or tasks already covered by a single dedicated adapter skill with no discovery needed.
When should I use this skill?
Start of any OpenCLI session; when the agent asks what opencli can do or how to find the right command.
What do I get? / Deliverables
The agent loads a consistent mental model of pillars and flags, then invokes the correct specialized OpenCLI skill for the actual task.
- Correct specialized OpenCLI skill selection
- Documented command path for the user’s target site or CLI
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Discover whether a SaaS admin task has a COOKIE or UI adapter before writing custom scrapers.
Map browser subcommands to smoke-test a staging site through OpenCLI instead of manual clicks.
Re-orient after months away to recall bind semantics and external CLI passthrough paths.
Find the right adapter to pull billing or usage data from a vendor dashboard via agent.
Quickly check if a prototype’s third-party console is automatable via PUBLIC vs UI strategy.
How it compares
Orientation meta-skill—not a replacement for opencli-browser or site-specific adapter skills.
Common Questions / FAQ
Who is opencli-usage for?
Solo builders and agent operators who drive OpenCLI regularly and need a single entry map before deeper browser or adapter skills.
When should I use opencli-usage?
At the start of any OpenCLI session, during Build when wiring integrations, during Ship when validating flows in Chrome, or during Operate when re-automating admin consoles—whenever someone asks what opencli can do or how to find the right command.
Is opencli-usage safe to install?
It allows Bash on opencli and Read; downstream skills may drive browsers and cookies—review the Security Audits panel on this page before enabling in production accounts.
Workflow Chain
Then invoke: opencli browser
SKILL.md
READMESKILL.md - Opencli Usage
# opencli-usage OpenCLI turns any website, Electron desktop app, or external CLI into a uniform `opencli <site> <command>` surface that agents can drive without screen-scraping. This skill is the orientation layer — once you know what you want to do, load one of the specialized skills below. ## The three pillars - **Adapter commands** — `opencli <site> <command> [...]`. Built-in adapters live in `clis/`, user adapters in `~/.opencli/clis/`. Each is backed by a strategy (`PUBLIC | COOKIE | INTERCEPT | UI | LOCAL`) that tells you whether a Chrome session is needed. - **Browser driving** — `opencli browser *` subcommands (`open`, `state`, `click`, `type`, `select`, `find`, `extract`, `network`, …) for ad-hoc interaction and scraping when no adapter covers the task. See `opencli-browser`. - **Current-tab binding** — `opencli browser <session> bind` attaches the Chrome tab the user already opened/logged into to that browser session. Follow-up commands use `opencli browser <session> ...`. See `opencli-browser` before using it; bound sessions still block tab mutation. - **External CLI passthrough** — `opencli gh`, `opencli docker`, `opencli vercel`, etc. Managed via `opencli external install <name>` (auto-install from `external-clis.yaml`) or `opencli external register <name>` (bring your own). ## Install ```bash # npm global npm install -g @jackwener/opencli # binary: opencli, requires Node >= 21 opencli doctor # run before browser-dependent work (see below) # From source git clone git@github.com:jackwener/OpenCLI.git cd OpenCLI && npm install npx tsx src/main.ts <command> # same surface, no global install ``` `opencli doctor` prints a structured `DoctorReport` — daemon status, extension connection, version checks, and a live browser connectivity probe. Scope is narrow: it diagnoses the **browser bridge** (daemon + extension + Chrome wiring). `PUBLIC` / `LOCAL` adapters, `opencli list`, `validate`, `verify`, plugin commands, and external-CLI passthrough don't need it to be green — only `COOKIE` / `INTERCEPT` / `UI` adapters and the `opencli browser *` subcommands do. Flag: `-v` (verbose). ## Prerequisites by command type | Strategy tag on `opencli list` | What it needs | |--------------------------------|---------------| | `PUBLIC` | Nothing — pure HTTP, no browser. | | `COOKIE` | Chrome logged into the target site + **OpenCLI** extension installed from the [Chrome Web Store](https://chromewebstore.google.com/detail/opencli/ildkmabpimmkaediidaifkhjpohdnifk). Command captures the credential from your live session — no re-login. | | `INTERCEPT` | Same as COOKIE, plus opencli opens an automation window to capture a signed request. | | `UI` | Same as COOKIE, full DOM interaction. | | `LOCAL` | No browser; talks to a local/dev endpoint. | Electron desktop apps (cursor, codex, chatwise, discord-app, doubao-app, antigravity, chatgpt-app) route through CDP against the running app — same cookie-less flow as a logged-in browser. Make sure the app is running before invoking. ## Discover what's installed — don't read this file, run a command ```bash opencli list # table, grouped by site opencli list -f json # machine-readable; pipe to jq or your agent opencli list | grep -i twitter # find commands for a specific site opencli <site> --help # see that site's commands + flags opencli <site> <command> --help # see positional args and command-specific flags ``` Do not hard-code adapter lists — there are 100+ sites and the count moves every week. `opencli list -f json` is the