/multi-cli-anything

name: multi-cli-anything
description: Add a new CLI provider to cc-multi-cli-plugin (beyond the built-in Codex/Cursor/Antigravity/OpenCode). Use when the user asks to integrate another AI CLI like Aider, Qwen, or any CLI that can be driven headlessly (a `-p`/print mode with JSON output, an app-server/HTTP mode, or any structured transport). Trigger phrases include "add Aider to the plugin", "integrate Qwen", "hook up my custom CLI", "support another model via its CLI".

Add a new CLI to cc-multi-cli-plugin

cc-multi-cli-plugin is a **multi-plugin marketplace** with four built-in CLIs: Codex, Cursor, Antigravity, and OpenCode. Adding a new CLI beyond these means two things:

1. **A new adapter** in the `multi` hub — `plugins/multi/scripts/lib/adapters/<cli>.mjs` — that conforms to the adapter contract and is registered in `lib/adapters/registry.mjs`, plus a dispatch branch in `lib/commands/task.mjs`. 2. **A new thin plugin** — `plugins/<cli>/` with command files + a `plugin.json`, registered in the root `marketplace.json` — that forwards `/<cli>:<role>` into the hub via `multi:<cli>-<role>` subagents.

**The adapter interface is transport-agnostic.** The companion consumes only the five-method `adapter` object defined in `plugins/multi/scripts/lib/adapters/CONTRACT.md` (`name`, `isAvailable`, `isAuthenticated`, `invoke`, `cancel`, plus optional `getSession`). *How* the adapter talks to the CLI — headless print mode, spawn-and-read-files, app-server HTTP, or (legacy) ACP — is your choice, driven by what the CLI actually exposes. **Read `CONTRACT.md` first**; it's the source of truth for the result shape.

There is **no `buildPrompt()` function** and no slash-command-prefix layer (an older design that's gone). A role's read/write behavior is expressed as CLI flags/sandbox inside the adapter; a role's prompt framing lives in its subagent `.md`. Don't reintroduce a `buildPrompt`.

Step 0 — Research the CLI first

Before writing any code, pull everything you need so you don't guess or ask the user later:

• **Install status and binary name** — is the user's machine set up? What's the exact command (`agent`? `qwen`? `aider`? `opencode`?).
• **A drivable headless transport** — see Prerequisites below. This is the make-or-break question.
• **Exact model identifiers** the CLI accepts (or `auto` if offered). A wrong model string causes a 400/exit-1 at runtime.
• **Modes / permission flags** — read-only vs write, an `ask`/`plan` mode, a `--force`/`--yolo` auto-approve flag, a sandbox setting. These are what you'll map roles onto inside the adapter.
• **Runtime flags** — output format (`--output-format json`?), resume/session, background — what does `--help` actually list?
• **Authentication mechanism** — env var, OAuth keyring, device code, API key header.
• **Known quirks** (Windows shell requirements, PATH issues, empty-stdout-when-piped bugs, version-specific behavior).

**Pick sources proportional to the question.** Start cheap and authoritative; escalate only if unclear.

First: search for an existing Claude Code (or other) integration of this CLI

Before anything else, **search exa for an existing implementation**. The community has wired up many CLIs already — finding one collapses days of trial-and-error into "read their adapter, adapt to our marketplace structure."

Useful queries (try in order, stop when you find a working example):

<cli-name> claude code plugin
<cli-name> headless print mode json output
<cli-name> agent SDK / programmatic API
<cli-name> claude-code marketplace
<cli-name> @anthropic-ai claude

A reference implementation reveals things probes don't:

• **Spawn quirks** — does the CLI need `shell: true` on Windows? A specific env var to init? Does it want the prompt on stdin vs as an arg?
• **Output completeness** — does its `-p` mode actually print the answer, or (like `agy`) write nothing to stdout when piped? What's the JSON envelope shape?
• **Auth flow specifics** — env vars, token paths, OAuth dance details.
• **Model ID conventions** — version suffixes, deprecated aliases. (The Gemini family's `-preview` suffix trap — which Antigravity surfaces — is the canonical example.)

If you find one: 1. Read its full implementation. Note any "this CLI is weird about X" comments. 2. Note pre-flight config it requires (env, config-file entries, auth setup). 3. Cite the source (NOTICE attribution + a comment in the new adapter). 4. Adapt — don't blindly copy. Our marketplace structure differs; the principles transfer, the file paths don't.

If you don't find one (or it's stale), proceed with the verification ladder below. Looking is cheap.

Verification sources, in order of cost/authority

1. **`<cli> --help`, `<cli> models`, `<cli> about`, `<cli> --list-models`** — fastest, no network, authoritative for "what does this binary accept right now." 2. **Vendor docs via context7** — `resolve-library-id` → `query-docs`. Good for canonical names and deprecation context. 3. **exa web search** — for changelogs, forum posts, obscure flags context7 doesn't have. 4. **CLI source on GitHub** — config constants. Slowest; use only when 1–3 disagree or come up empty. 5. **Prompt the CLI itself** (`<cli> -p "List the exact model strings this CLI accepts."`) — only when no listing subcommand exists and docs are empty. Costs credits.

**Hard rules:**

• **Never ask one CLI about another CLI's features.** A CLI is a source only for itself.
• **Preview-suffix trap:** many CLIs qualify unstable IDs with `-preview`/`-beta`/`-exp`. Don't hardcode the unsuffixed variant — it 404s at runtime.
• **Resolving disagreements:** CLI wins for "does it work right now"; docs win for "should I use this."
• **Record the source you used** inline so the user can catch a bad citation.
• **Read the existing adapters** in `plugins/multi/scripts/lib/adapters/` — they're your worked examples (see the transport table at the end).

Proceed without asking the user to confirm facts you can verify y