From CORAL
Registers local agent runtimes (Claude, Codex, Cursor, etc.) as named bindings with `coral setup`, validates them with `coral agents doctor`, and references from tasks via `agents.binding`. Use when configuring agent runtimes or troubleshooting runtime/auth errors.
How this skill is triggered — by the user, by Claude, or both
Slash command
/coral:setting-up-coralThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
After installing the `coral` CLI, the one-time machine setup is **registering which agent runtimes you have** as named *bindings*. A binding bundles a runtime + CLI command + default model + runtime options under a short name, stored at:
After installing the coral CLI, the one-time machine setup is registering which agent runtimes you have as named bindings. A binding bundles a runtime + CLI command + default model + runtime options under a short name, stored at:
~/.config/coral/agents.yaml # honors $XDG_CONFIG_HOME; override with $CORAL_AGENTS_CONFIG
Tasks then reference a binding by name (agents.binding: claude-opus) instead of repeating runtime/model in every task.yaml. This keeps task.yaml portable (topology: how many agents, which roles) and machine-specific details (which CLIs are installed here) in a user-level file that's never committed.
Bindings store no credentials. Authentication stays with each runtime's native login (
claude,codex,cursor-agent login,kiro-clisetup).coral setuponly records runtime/command/model metadata. If a run fails to auth, fix it via the runtime's own login, not coral.
coral setup
Scans PATH for every supported runtime (claude, codex, cursor-agent, opencode, kiro-cli, pi), prints a detection report (✓ = found), then offers a numbered wizard. For each pick it asks for a binding name, model, and an optional role-seed file. After each one it asks "Add another binding for X?" — say yes to make several bindings for the same runtime (e.g. claude-opus and claude-sonnet). The first binding created becomes the default.
coral setup --non-interactive — just print the detection report (CI / piping); creates nothing.For a custom command path, model, or runtime option — or for CI where you can't use the wizard:
coral setup agent --name claude-opus --runtime claude_code --model opus
coral setup agent --name codex-high --runtime codex --option model_reasoning_effort=high
coral setup agent --name claude-opus --runtime claude_code --model opus --default # make it the default
--runtime accepts a builtin (claude_code | codex | cursor_agent | opencode | kiro) or a custom module.path:ClassName. Re-running with an existing --name updates that binding. Each coral setup agent finishes with a lightweight doctor pass on that binding.
coral agents list # numbered; default marked
coral agents show claude-opus # one binding's resolved fields
coral agents doctor # validate ALL bindings
coral agents doctor claude-opus # validate one
doctor runs five checks per binding: the binding resolves to a valid spec, the CLI is on PATH (or at the configured command), --version works, the role file exists (if set), and — by default — a live hello-ping that spawns the runtime with a one-word prompt and waits for a reply. The live ping is what catches the failures the cheap checks miss: expired auth, broken provider credentials, network issues, model-name typos.
--no-live — skip the hello-ping (CI / quick sanity check; costs one LLM round-trip per binding otherwise).--timeout SECS — per-ping wait (default 30s).When the ping fails, doctor points you at the runtime's login flow rather than asking for credentials.
coral agents remove # interactive numbered wizard
coral agents remove claude-opus codex-high # delete one or more by name
doctor tells you which of the five checks failed — match it to the fix:
| Failed check | What it means | Fix |
|---|---|---|
| binding resolves | agents.yaml entry is malformed or names an unknown runtime | coral agents show <name>; recreate with coral setup agent --name ... --runtime .... |
| CLI on PATH | the runtime binary isn't found | install the runtime, or point the binding at it with --command /abs/path. |
--version works | binary found but won't run | reinstall the runtime; check it runs standalone. |
| role file exists | a configured role-seed file was moved/deleted | fix the path or drop the role file from the binding. |
| live hello-ping | binary runs but the model call fails | almost always auth or a model typo — log in via the runtime (table below) and check the model name. Re-run; add --no-live only to skip the check, not to fix it. |
Bindings store no credentials — each runtime owns its own login. The hello-ping failing means you log in here, not in coral:
| Runtime | --runtime | Log in with |
|---|---|---|
| Claude Code | claude_code | claude (interactive login) |
| Codex | codex | codex login flow |
| Cursor Agent | cursor_agent | cursor-agent login |
| Kiro | kiro | kiro-cli setup |
| OpenCode | opencode | opencode auth |
Codex reasoning effort is a runtime option, not a model: coral setup agent --name codex-high --runtime codex --option model_reasoning_effort=high. For custom or self-hosted models across runtimes, route through the LiteLLM gateway (agents.gateway in task.yaml): https://docs.coralxyz.com/guides/gateway
Single runtime:
agents:
binding: claude-opus
count: 4
Mixed team — one binding per assignment:
agents:
assignments:
- binding: researcher
count: 1
- binding: implementer
count: 3
Precedence when a binding expands: explicit task.yaml fields win → binding fields → runtime defaults. So binding: claude-opus plus model: sonnet uses the binding's runtime/options but the overriding model. Bindings are purely additive — agents.runtime / agents.model / agents.assignments still work unchanged, and after expansion the run's stored config.yaml holds only concrete fields (so resumes and the dashboard never depend on your local bindings file).
coral-quickstart (install) → setting-up-coral (bindings, here) → creating-a-coral-task (author) → running-coral-experiments (run). Setup is optional — you can put runtime/model straight in task.yaml — but bindings + coral agents doctor are the reliable way to confirm a runtime is installed and authenticated before you launch agents. Full reference: https://docs.coralxyz.com/guides/agent-bindings
npx claudepluginhub human-agent-society/coral --plugin coralLaunches, monitors, and manages CORAL agent experiments via CLI commands like start, status, log, and stop. Use when running or steering agent evaluations.
Performs first-time setup of a ClaudeClaw instance: installs dependencies, authenticates messaging channels, registers the main channel, and starts background services.
Deploys and manages AI agents on GreenNode AgentBase, covering Custom Agent Docker runtimes and OpenClaw chatbot templates. Handles build, push, scaling, versions, endpoints, and container registry operations.