customize

Customize cc-multi-cli-plugin

cc-multi-cli-plugin is a multi-plugin marketplace: one hub plugin (multi) plus one thin plugin per AI CLI the user has wired up. Customization is explicit file edits across those plugins. There is no runtime config layer and no buildPrompt() function — a CLI's behavior is assembled from a few small, separate files, and you edit the one that owns the thing you want to change.

This skill is CLI-agnostic. Every instruction below works for any CLI in the marketplace — the four shipped defaults (Codex, Cursor, Antigravity, OpenCode) and any CLIs added later via the multi-cli-anything skill (Aider, etc.). Concrete examples use specific CLI names for clarity; apply the same pattern to any CLI.

The four moving parts every customization touches

A /<cli>:<action> invocation flows through four artifacts. Each owns one concern. A customization edits whichever one owns what you're changing — usually one or two.

| Artifact | Path | Owns | Edit it to… | |---|---|---|---| | Slash command | plugins/<cli>/commands/<action>.md | The user-facing entry point. Dispatches to the subagent via the Agent tool. | add/rename/disable a /<cli>:<action> command | | Subagent (forwarder) | plugins/multi/agents/<cli>-<role>.md | The multi:<cli>-<role> forwarder. Loads the multi-cli-runtime skill, optionally frames the prompt, and builds exactly ONE companion Bash call. Its model: is tuned by role (see below). | change a role's prompt framing, its model, its tools, or which --cli/--role it forwards to | | Adapter | plugins/multi/scripts/lib/adapters/<cli>.mjs | The CLI's transport, plus the role→flag/sandbox mapping (read-only vs write, mode flags). Registered in registry.mjs. | change how a role maps to the CLI's own flags/permissions | | Shared contract | plugins/multi/skills/multi-cli-runtime/SKILL.md | The flag-handling, routing, and failure-line contract every forwarder obeys (--model, --effort, --write/--read-only, --resume, --until-done, --plan, 2>&1, the <CLI> <role> failed: … line). | change behavior shared across all CLIs (rare — it affects everything) |

Two facts that the old buildPrompt() model got wrong and that you must internalize:

• **Prompt shape lives in the subagent .md, not the adapter. Each write-role forwarder (e.g. cursor-delegate.md, codex-execute.md) contains a fenced framing block** ("You are Cursor in agent mode…") that it prepends to the user's task. To change how a role frames its prompt, edit that block. Read-only forwarders (codex-review, antigravity-researcher) usually have little or no framing.
• **Role behavior (read vs write, CLI flags) lives in the adapter** — and is done differently per CLI. Codex switches on a sandbox (read-only vs danger-full-access) selected by the --write flag in lib/commands/task.mjs; Cursor maps roles to headless flags in buildHeadlessArgs() plus a READ_ONLY_ROLES set in cursor.mjs; Antigravity is always read-only; OpenCode maps roles in buildHeadlessArgs() plus READ_ONLY_ROLES in opencode.mjs (no --read-only flag — enforced via env injection). Verify the specific CLI's mechanism before editing (Step 2).

Step 0 — Locate the plugin repo

Before editing anything, determine WHICH files to edit. Three scenarios:

1. Check claude plugin marketplace list — find the installLocation for cc-multi-cli-plugin.
2. Classify the install:
3. If installLocation is a local directory the user controls (dev clone, fork they own) — edit those files directly. Changes are live.
4. If installLocation is under ~/.claude/plugins/marketplaces/cc-multi-cli-plugin/ and sourced from a GitHub repo the user does NOT own — edits there will be overwritten on the next claude plugin marketplace update. STOP and tell the user they need to fork the repo, clone their fork, and re-register that clone as the marketplace source.
5. Ask the user if you can't tell which scenario applies.

Record the path you'll edit as $REPO. All subsequent file paths are relative to $REPO.

Step 1 — Discover the current inventory (don't rely on memory)

Users may have added CLIs via multi-cli-anything that aren't in any documentation, and the shipped roster shifts between versions. Always run these before planning changes:

ls $REPO/plugins/                                       # CLI plugins installed
ls $REPO/plugins/multi/agents/                          # subagents (forwarders)
find $REPO/plugins -name "*.md" -path "*/commands/*"    # slash commands
ls $REPO/plugins/multi/scripts/lib/adapters/            # adapters
cat $REPO/plugins/multi/scripts/lib/adapters/registry.mjs   # which adapters are registered
cat $REPO/.claude-plugin/marketplace.json               # marketplace registration

The output is ground truth for what exists. Planning against it avoids the "subagent not found" / "unknown CLI" class of bug. (As shipped: Codex roles execute/rescue/review/adversarial-review; Cursor roles delegate/research/explore; Antigravity roles research/explore; OpenCode roles delegate/research/explore. The Antigravity subagent files are named antigravity-researcher/antigravity-explorer; OpenCode subagents are named opencode-delegate/opencode-researcher/opencode-explorer. Confirm against your own ls — don't assume.)

Step 2 — Verify CLI-specific strings BEFORE hardcoding them

Before hardcoding any CLI-specific string (model IDs, effort levels, sandbox/mode names, flag names) as a default, verify it. Do not ask the user to confirm these — Claude can look them up faster.

The verification-trap: CLIs often accept version-qualified IDs (-preview, -beta, -exp suffixes). Dropping the suffix produces a runtime 4xx. A model ID like gpt-5.3 vs gpt-5.3-codex is not interchangeable, and Gemini-family IDs (which Antigravity surfaces) have historically used -preview suffixes that 404 when dropped. Every CLI has analogous traps.

Pick ONE source proportional to the question. Stop when confident.

The verification sources form a LADDER — start with the cheapest authoritative one for the question at hand and stop as soon as you have a confident answer. Do NOT run every source for every question.

Decision tree:

• Yes/no capability check — "does <cli> support --read-only?" or "does <cli> have an ask mode?" → ONE source. Usually <cli> --help | grep <term> in well under a second. Done. Don't escalate.
• Enumerating what exists — "what modes does <cli> have?" or "what models does <cli> accept?" → ONE source. Try <cli> --help (or <cli> models / <cli> --list-models) first, or a vendor-docs lookup via context7 if --help isn't exhaustive. Escalate only if the first comes up empty or suspicious.
• Exact canonical ID with version suffix (e.g. "the current stable Cursor model id for the medium tier") — up to TWO sources when a wrong suffix bricks the feature. Prefer the CLI's own listing, then cross-check with vendor docs. Only read source constants on disagreement.

The sources, in the order you'd try them

1. <cli> --help, <cli> models, <cli> about, <cli> --list-models — fastest. No network. Free. Authoritative for "what does this binary accept right now." Default choice for most questions.
2. Vendor docs via context7 — resolve-library-id → query-docs. Good for canonical names, deprecation context, and modes not surfaced by --help.
3. Web search via exa — for recent changelogs, forum posts, or obscure flags not covered by context7.
4. CLI source on GitHub — config/models.ts constants, etc. Use when 1–3 disagree or come up empty.
5. Prompt the CLI itself with <cli> -p "..." — LAST RESORT only. Costs the user API credits and is slow. Don't reach for it for routine customize questions; docs and web search cover 99% of what this skill needs