Menu

Individual skill

multi-llm

Orchestrate plan reviews, task generation, implementation and code reviews across several LLM CLIs in parallel, or ask every model one free-text question about a plan. Use when the user says: review my plan, multi-llm, run a code review, generate tasks from a plan, implement this plan, ask the models about my plan.

plugins/beastlabai/multi-llm-plugin/skills/multi-llm/SKILL.md

Read pinned source

Source commit d780783eba4ecc7c8b9429f95c9362df95f07c61

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 4, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,532
Repository last updated
Nov 6, 2026
License
Apache-2.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Multi-LLM

Call the `multi_llm` tool with the argument text, converted to its four properties exactly
as that tool's own argument descriptions specify. The tool is the only supported entry point
on this host: it appends the flags this host requires, refuses the ones it owns, and
supervises the run to a terminal result. Do not reach the dispatcher any other way. The tool
runs outside the exec sandbox, and on the modes that apply changes it writes to the workspace. A call can run for up to its 15-minute budget. When you call this tool from an `exec` cell, start the cell with `// @exec: {"yield_time_ms": 900000}`, so the cell waits for the result. If a cell hands back "Script running" anyway, call `wait` until this call returns, and never end your turn while it is running.

Read the result's `exit` and `next` the way the dispatcher's own contract reads them; on `state: partial`, name the failed models and their reasons from `progress.models`; when the result carries `validation_counts` (a review phase's does), report them, and if `needs_human_decision` or `validation_failed` is non-zero point at `report.md` for those groups; they are decided later, when the suggestions are applied. A result without that key has no counts to report, so do not mention them. When the result carries a `notice` (`result.notice`, a finished run's: what it left out or could not check, such as items it did not apply or that nothing ran this repository's tests), report what it says, every part of it, as plain text. Put it above the closing section, and repeat nothing that section says.
On this host `next` arrives as arguments for this same tool, not as a command: "running" it means calling the tool again with exactly those arguments, never a shell.
Run `next` verbatim when it is not `null` on `0` and `2`. On `3` stop: report to the user which phase stopped, on which plan or commit range, the last error line it printed, whole (on a stop it says what stopped, what it reported, what did not run and whether anything ran the repository's tests), and the options its output names (`next` included); do not run a different mode. Do not perform the work this run was going to review, plan, or implement: doing it yourself is never a substitute for a failed run. Run an option only after the user has picked it. Never edit `driver.write_paths`, or any other multi-llm setting in `.multi-llm/providers.yaml`, yourself. At a stop, offer only the ways forward the stop itself names, as it words them: when it names a change to `driver.write_paths` that lets a refused file be written (adding it to `allow`, or removing or narrowing a deny rule that covers it), that is one of them and the user's call; add no advice about the write policy of your own. `user_next_step` is the phase after this one, for the user to type: never run it yourself; end your report with its `markdown`, copied as it is (its words and order, each command alone in its fenced block, each why and note plain text, the manual tasks it lists included, no caption of your own). Only that `markdown` says "Workflow complete.": never write those words yourself. Copy it word for word, never wrapped in a fenced block of your own (its commands are fenced already), and say none of it twice: its whys, notes, manual tasks and "Workflow complete." appear only in it, never above it. It is never a tool call, unlike `next`, which is one. At a stop, `resume_markdown` is the stop's options, already written: end your report with it the same way, in place of any list, recap or summary of the options or ways forward of your own.

If that tool is not listed, the plugin's server did not start: `codex mcp get multi_llm`
names the command it tried, and `python3 >= 3.9` must be on `PATH`.