Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →human-agent-society/setting-up-coral
One-time machine setup after installing the `coral` CLI — register local agent runtimes as named bindings with `coral setup` / `coral setup agent`, validate them with `coral agents doctor` (incl. a live hello-ping that catches expired auth and model typos), and reference them from a task via `agents.binding`.
Passed 21 of 23 test cases with the skill, and 11 of 23 without it.
and 12 more in the full report
11 fixed10 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
We want our automated provisioning script to scan the host environment and output a report of installed agent runtimes without starting an interactive prompts session or creating any binding entries on disk. Which flag should be passed to coral setup?
| Checked | Without skill | With skill |
|---|---|---|
| Includes the --non-interactive flag with coral setup. | Missed | Passed |
| States that non-interactive setup prints the detection report without creating any bindings. | Passed | Passed |
The instructions your model reads when the skill loads.
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
test cases passed, vs 11 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.