Automate

The team plugin — four role-scoped agents in Claude Code

One command installs a small research team into Claude Code: a researcher that turns rules text into a validated draft spec and Strategy Brief, a runner that submits what you approved and polls it, an audit-reader that explains stored audit verdicts citing check ids, and a chart-reader that reads a run's stored tables (trades, fills, summaries) row by row. No agent writes backtest code — the engine does the work — and no agent can approve or spend: role separation is enforced by per-agent tool allowlists, not prompt hope.

Install

Mint a machine token in the app (Settings → Agent access, fresh authenticator code required; the value is shown once). Grant strategies:read, strategies:write, runs:read, runs:write, notes:write, and journal:read, plus the project allowlist — a missing scope surfaces as a named 403.
Install from the marketplace. The repo is its own Claude Code plugin marketplace, so installing is two commands. Order matters: the plugin's bundled MCP config reads its environment from the claude process, so set the exports first, then launch claude from that same terminal:
```
export VERIRUNLAB_MACHINE_TOKEN="vrl_…"
export VERIRUNLAB_API_URL="https://api.verirunlab.com"
export VERIRUNLAB_REPO=/path/to/verirunlab   # marketplace installs run from a cache copy
claude
```
then, inside the session:
```
/plugin marketplace add verirunlabs/verirunlab
/plugin install verirunlab-team@verirunlab
```
(Installed from a session launched without the exports? Exit and relaunch claude from the exporting terminal — the install persists; the environment does not retro-apply to a running session.) For local development on a checkout, skip the marketplace — and the VERIRUNLAB_REPO export, since a direct install resolves the repo from the plugin's own location:
```
claude --plugin-dir /path/to/verirunlab/apps/mcp/plugin/verirunlab-team
```
Check the roster: the four agents appear namespaced by the plugin — verirunlab-team:verirunlab-researcher, …:verirunlab-runner, …:verirunlab-audit-reader, and …:verirunlab-chart-reader.

The loop — where the human sits

Researcher: paste a transcript or rules text. It validates the spec (validate_spec), dry-loads it to read back what the engine understood (dry_load_spec), renders the brief verbatim — including every "Not specified — defaults apply" line (render_brief) — then lands the draft as an immutable spec version (stored with source='ai', which puts it behind the strict AI gate) and saves the brief. The three checks are $0 and store nothing until the landing step.
You approve in the app. The plugin has no approval tool of any kind — an approval unlocks exactly one submission, and the researcher hands you the dashboard link and stops.
Runner: submits the approved brief, polls with the platform's suggested backoff, and writes its conclusions to the run notes. Refusals (tests not green, approval spent, missing data) are relayed verbatim — there is no way around a gate on this surface.
Audit-reader: reports the stored verdict with its version ("clean, v2 deep") and cites the check ids it draws on. It never recomputes, never averages checks into a score, and always carries the not-a-profit-promise line. It can also read a run's stored independent-review annotations (get_run_review) — findings there are leads to investigate beside the verdict, never verdicts themselves, and requesting a new review stays a human dashboard action.

Role separation is tested, not promised

Each agent's tool allowlist is a contract: the researcher has no run tools, the runner has no authoring or audit tools, the readers are strictly read-only, and no agent carries an approve/accept/spend capability — a test suite parses the shipped agent files and fails the build if any list drifts. The underlying MCP façade enforces the same rules server-side, so even a hand-edited plugin gains nothing.

Prefer a raw MCP connection for your own agent instead? See External agents (MCP) — the plugin is a curated roster on top of exactly that surface.