trinity Plugin

/plugin marketplace add abilityai/abilities
/plugin install trinity@abilityai
/trinity:start-here

One command that concierges a newcomer through the whole path — it sequences the skills below rather than replacing them, so you never have to know which one comes next.

Already know what you want? The individual skills below work standalone, in any order.

When /trinity:onboard detects it is running inside a deployed Trinity agent - the agent's own workspace, with the platform's MCP tools already injected - it offers Onboard in place as the recommended goal (or take it directly with /trinity:onboard in-place, which is also the one-line form an orchestrator dispatches after deploying a bare repo). Nothing is created; the agent already exists. Instead it:

The trinity plugin is provided by the platform. The in-place path needs the plugin present in the container, and a bare repo declares nothing - so Trinity's agent image ships with it pre-installed, and every container boot re-installs it if missing, whether or not template.yaml declares it. A new agent therefore runs /trinity:onboard in-place straight away. Only an agent still running on an image built before the pre-install needs the one-time bootstrap from its terminal, followed by a fresh session:

claude plugin marketplace add abilityai/abilities && claude plugin install trinity@abilityai --yes

Onboarding in place is idempotent - if the push was refused, grant the agent write credentials and re-run.

The remote counterpart to Claude Code's built-in /loop. Where /loop re-invokes your local session on a cadence, /trinity:loop hands one bounded, sequential loop to a remote Trinity agent: it fires run_agent_loop once, returns a loop_id, and you can disconnect - the Trinity backend runs every iteration in order and exits on a hard cap or a stop signal. Use it for iterative refinement, agentic retry, and bounded polling that must outlive your session.

/trinity:loop [@agent] <message>             start a loop
/trinity:loop status <loop_id>               show per-run progress
/trinity:loop stop <loop_id>                 request a graceful stop
/trinity:loop local <message>                run the same bounded loop in this session

No @agent means this agent's remote copy - the usual case is looping your own remote counterpart on Trinity (resolved from .trinity-remote.yaml or by name match).

Modifiers, anywhere in the message:

Examples:

/trinity:loop @researcher draft section {{run}} of the report, 5 times
/trinity:loop @ci-agent run the test suite until it passes, max 10
/trinity:loop @monitor poll the deploy every 2m until it's healthy
/trinity:loop status loop_a1b2c3
/trinity:loop stop loop_a1b2c3

After firing, the skill starts a lightweight local watch by default - it polls the loop and reports run-by-run progress, stalls, and the final result. Say "fire and forget" to skip the watch; the remote loop runs either way and also appears on the agent's Loops tab in the Trinity web UI. Inside a deployed Trinity agent there is no watch - the wake-up tools it relies on are denied there - so poll with /trinity:loop status or a set_reminder instead.

local runs the same Fixed or Until loop natively in your Claude Code session - no Trinity connection, no loop_id. Use it when the task lives on this machine or Trinity is unreachable; if the loop must outlive your session, it is remote.

The loop mechanics - modes, template variables, stop signals, capacity, costs - are the platform's Sequential Agent Loops feature.

When to use what

/trinity:create-dashboard

Analyzes the agent's purpose and data sources, proposes a set of metrics, and - after your approval - scaffolds an agent-specific /update-dashboard skill that keeps dashboard.yaml current. Declare that skill's cron in template.yaml schedules:to keep the agent's dashboard live.

The generated skill writes only widget types Trinity renders - metric, status, progress, text, markdown, table, list, link, image, divider, spacer; anything else is stripped by the agent. There is no chart type: trend lines and sparklines come from the platform, which records each metric and progress widget's value on every fetch, keyed by the widget's stable id: - so the skill gives those widgets an id (reordering unkeyed widgets orphans their history) and never emits YAML anchors, which Trinity's hardened loader rejects. See Dynamic Dashboards.

/trinity:deploy-new-instance

Deploys a complete Trinity instance - on a cloud host, any server you can reach over SSH, or local Docker; fresh installs and existing instances both - and scaffolds a dedicated ops agent with 13 skills to manage it (health checks, updates, rollbacks, provisioning). It builds from source or pulls prebuilt images (start.sh --hosted with a pinned TRINITY_IMAGE_TAG), seeds the admin account from .env so there is no first-run setup screen, and needs only the frontend port opened in the firewall - the MCP server is reachable through it at /mcp. See Deploying Trinity and the Trinity Ops Agent.

You can also deploy via the command line:

# Install CLI
pip install trinity-cli

# Initialize (one-time)
trinity init

# Deploy agent
trinity deploy .

See Trinity CLI for details.

Agents must have:

Optional but recommended: dashboard.yaml (custom metrics dashboard), .mcp.json.template (MCP server configuration), template.yaml schedules: (declared recurring work, materialized at creation), and template.yaml plugins: (declared Claude Code plugins, re-installed on every boot - declare trinity@abilityai at minimum so the intent is in the repo; the platform provides that one plugin on every boot even when it is undeclared)

The authoritative verdict is the platform's compatibility report (Agent Detail → Overview), which /trinity:onboard runs at the end of every path. See Creating Agents.