Skip to main content
The to11 CLI is a single binary, to11. It does two things:
  • keeps the skills your company publishes current in the directories your coding agent reads;
  • runs your agent with its traffic going through the gateway, so the work is visible without changing how you write code.
It is how skills are created and changed. The browser reads them; the CLI writes them — see Reading a skill in the dashboard for the other half.

​
Where it comes from

The binary is published for Linux and macOS, on x86-64 and arm64. An asdf plugin lives at to11ai/asdf-to11, and every release carries the archives and a checksums.txt directly. There is no Windows build. Receiving skills has the commands.

​
Getting it configured

to11 init configures one location and runs a first sync. It authenticates with an API key, created in the dashboard under Settings → API keys and supplied once at a hidden prompt; $TO11_API_KEY supplies it without a terminal. With every flag given it asks nothing. See Receiving skills for the walkthrough, and to11 init for every flag.

​
What it puts where

Configuration never contains a secret, which is what makes a repository’s copy safe to commit. $TO11_HOME moves the first three. A repository’s own configuration lives at <repo>/.to11/skills.yaml, and both apply at once — see Configuration.

​
Staying current

An automatic refresh is a cache read, and cacheTtlSeconds is the window: inside it there is nothing to do and no request is made. It syncs when the window has passed, or when a configuration file that governs your machine has changed since the last write. The refresh runs from a hook in your own agent settings, installed once by to11 init. A repository can never install one on your machine or change how often yours runs: a team decides which skills apply to work in their repository, never how a colleague’s agent behaves. An automatic refresh does not block the work that triggered it. An update reaches the agent on the following message regardless, because the agent resolves a skill independently of when the file is written. A refresh that fails is silent. It writes nothing to either stream, and records nothing for a later command to report. See Failing while nobody is watching. to11 skill sync ignores the window entirely — an explicit sync always runs.

​
What it never does

  • Touch a directory it did not create. The state file records what the CLI wrote, per file; anything else in the same directory is never read and never removed. It is listed once — as unmanaged, or, when it stands exactly where a configured skill would go, as a conflict naming the path.
  • Replace something you edited. A file you changed inside an installed skill makes that skill a local variant, and sync leaves the whole of it alone until you commit it with to11 skill store or discard it with to11 skill sync --force.
  • Delete a skill directory you edited, on the way past. When configuration stops asking for a skill — or for one of the targets it went to — each directory is judged on its own: one still holding what the CLI wrote is taken back; one you have edited, or that cannot be read at all, is reported and left, on every run, until to11 skill sync --force says otherwise. Under --remove-all the command that finishes it is to11 skill sync --remove-all --force.
  • Publish anything implicitly. Only to11 skill release makes a skill reach anyone else.
  • Print your credential. Not in the process list, not in a log, not in the terminal.
Hidden files inside an installed skill are not protected, and are deleted with it.The CLI ignores dot-prefixed entries everywhere. They are never compared, which is what stops a .DS_Store an agent or your OS drops into a skill directory from marking it changed and blocking every published update after it.The cost of that rule is that they are not protected either. When an installed directory is removed — you dropped the skill, you dropped that target, or you ran --remove-all — it is removed whole, hidden files included, with no --force and no line naming them.A visible file you add to an installed directory prevents the removal: it makes the directory differ from what was written, and sync reports it and leaves it alone. A hidden one does not. So keep nothing you care about inside an installed skill directory — that is the CLI’s to write and to take back.

​
Next steps

Commands

Every command, its flags, its conflicts, and what each deliberately does not do.

Configuration

The file that decides what you receive — including how to turn a skill off.

Output formats

Plain versus JSON, and what the JSON contract promises.

Errors & exit codes

What a failure looks like, and what keeps working when one happens.