multi-cli-runtime

Multi-CLI Runtime

Use this skill only inside multi:* forwarding subagents (cursor-execute, cursor-planner, cursor-debugger, gemini-explorer, gemini-researcher, copilot-planner, copilot-researcher, copilot-reviewer, qwen-writer, etc.).

Primary helper

node "${CLAUDE_PLUGIN_ROOT}/scripts/multi-cli-companion.mjs" task --cli <cli> --role <role> [flags] --prompt "<text>"

Where <cli> is one of codex|gemini|cursor|copilot|qwen (or any CLI added via the multi-cli-anything skill) and <role> is the subagent's logical role (execute, planner, writer, debugger, researcher, reviewer, explorer, ask).

Execution rules

• Each multi:* subagent is a forwarder, not an orchestrator. Its only job is to invoke the companion once and return that stdout unchanged.
• Prefer the helper over hand-rolled git, direct CLI strings (cursor agent acp, gemini --acp, copilot --acp --stdio, codex exec), or any other Bash activity.
• Use exactly one Bash call per subagent dispatch. Do not chain cat, sleep, polling loops, or follow-up node calls.

Routing flag handling

Treat these as runtime controls — strip them from the task text before forwarding, then re-add them as flags on the companion call:

• --background / --wait — foreground vs background scheduling. Default foreground for clearly bounded tasks; default background for open-ended or long-running work.
• --model <name> — pass through verbatim. Leave unset unless the user explicitly asked for a model.
• --effort <level> — only Codex accepts this (none|minimal|low|medium|high|xhigh). Other adapters ignore it. Pass through verbatim if present.
• --resume — translate to --resume-last.
• --fresh — do not add --resume-last, even if the user's text sounds like a follow-up.
• --write — default to --write for execute/writer/debugger/reviewer roles (these need to edit files); omit for planner/researcher/explorer/ask (read-only by intent). Honor explicit user override either way.

Capturing diagnostics

Always append 2>&1 to the Bash call so the parent thread can see runtime diagnostics if the companion fails.

Safety rules

• Preserve the user's task text as-is apart from stripping routing flags and prepending the subagent's role-specific framing block.
• Do not inspect the repository, read files, grep, monitor progress, poll status, fetch results, cancel jobs, summarize output, or do any follow-up work of your own.
• Return the stdout of the task command exactly as-is.
• If the Bash call fails or the upstream CLI cannot be invoked, return a single short failure line: <CLI> <role> failed: <one-line reason from stderr or "no output">. Never silently return nothing — the parent thread needs to know the run failed.
• If the user asks for setup, status, cancel, or result, that is NOT a multi:* subagent dispatch — it is a /multi:* slash command the user runs directly. Do not call those subcommands from within a forwarding subagent.

Forbidden behaviors

• Do NOT paraphrase or rewrite the companion output, even if it looks like a status update or progress message.
• Do NOT add narration like "The task is running in the background", "I will be notified when it completes", or "The companion is handling all steps". The companion already prints whatever the user needs to see.
• Do NOT promise to deliver later results. The subagent exits when its Bash call returns; it cannot be re-woken by background jobs finishing. If the companion launched a background task, the user has the job ID — let them poll /multi:status themselves.
• Do NOT invent fabricated output if Bash returned empty or non-zero. Use the failure line format above.