Skip to main content
You need the to11 binary on your PATH and a to11 account in your company’s organization. Nothing else — skills arrive as files, so there is no runtime to install and no agent setting to edit by hand.

​
Install the CLI

The CLI runs on macOS and Linux, on x86-64 (amd64) and ARM (arm64). There is no Windows build yet.

​
Install with asdf

asdf set arrived in 0.16. On 0.15 and older the last command is asdf global to11 latest, and asdf --version says which applies. Both write the pin to $HOME/.tool-versions; the directory-local forms leave to11 resolving only under the current directory.

​
Manual installation

Each release carries one archive per platform, to11_<version>_<os>_<arch>.tar.gz, a checksums.txt, and that file’s cosign signature, checksums.txt.sigstore.json — keyless: the signature is tied to the exact CI workflow that produced it, not a key you have to trust or that to11 has to protect. Set the version, your OS (darwin or linux) and architecture (amd64 or arm64), then download, verify, and install:
Verified OK from cosign confirms checksums.txt came from that exact workflow, in that exact repository, unaltered — checked first, because a checksums.txt an attacker also rewrote would otherwise pass its own checksum line for a replaced archive. The greps isolate $ARCHIVE’s own line rather than checking every entry in checksums.txt: shasum -c’s --ignore-missing flag would otherwise report overall success as long as whatever files happen to be present match, even if $ARCHIVE itself was never named or never actually checked - a leftover archive from a prior download in the same directory could satisfy it without $ARCHIVE being verified at all. On Linux, use sha256sum in place of shasum -a 256. Both the grep guard and the checksum line must succeed for your archive; if any check fails, nothing after it runs — nothing is extracted or installed. The last step runs the installed copy directly, so it reports the version you just installed. Use the newest version from the releases page. To run to11 by name, ~/.local/bin must be on your PATH — it is not by default on macOS — or install into another directory that is.
On macOS, download with curl as shown, or use Homebrew or asdf. The binary is not notarized, so a copy downloaded through a browser is quarantined and macOS refuses to run it. If you downloaded the archive, checksums.txt, and checksums.txt.sigstore.json that way, cd into the folder that holds them, set VERSION, OS, ARCH and ARCHIVE as above, and run xattr -d com.apple.quarantine "$ARCHIVE" before the verification step. Skip the three curl lines.

​
Configure this machine

ui sets up to11 in a screen in your terminal. When nobody is signed in it opens your browser to sign you in, and continues on its own once you have. If you belong to several organizations it asks which one this location uses. The first run is onboarding, walked step by step. Each step saves as soon as you confirm it, so quitting part-way keeps what you finished:
  1. Skills — select the projects your skills come from, from the projects you can read, and pick each one’s label on its row with ←/→. You receive every skill a project publishes at that label; prod is chosen when the project has one. An entry in your file with no label, which takes only the skills it names, shows set in skills.yaml: it can’t be changed on this screen and is saved as it is. Below the projects, choose the targets that get your skills (Claude Code, Codex, or both); they apply to every project. A standard target in your file is listed there, not offered, and kept as it is. Saving writes ~/.to11/skills.yaml and fetches your skills.
  2. Code · to11 Plugin — install or update the to11 plugin for Claude Code and Codex, where they are on your PATH. It carries the refresh points that keep skills current while a session is open, and the skills that set up this CLI. It is installed for you, in every project. Leave it unselected and nothing is wrong — your skills update when you run to11 skill sync. Routing your coding sessions through to11 is not part of onboarding. The overview has a row for it per agent, Code · Claude Code and Code · Codex; Trace coding agents covers it.
If a published skill would land on a directory name you already use, set prefix in skills.yaml — acme delivers acme-<slug> instead of <slug> — and every delivery moves out of the way at once. to11 ui does not ask for it, and keeps it when it saves. Onboarding ends on All set, which says it is complete; Exit leaves. Running to11 ui again opens an overview of what is set up, marks anything that no longer holds, and lets you change any step. While a step is missing it offers to continue onboarding, walking only the missing steps. Esc leaves onboarding at any step; what you saved stays saved.

​
Configure a repository

To decide which skills apply to work in a repository, run to11 ui inside it. It asks first:
Choosing the repository writes <repo>/.to11/skills.yaml — and <repo>/.to11/code.claude.yaml or code.codex.yaml when you set up a Code row, or when the first to11 code session there sets one up — which are committed. Your own configuration still applies — both are in effect at once, each writing into its own directories — so a repository’s skills are added to a colleague’s own. The code.<agent>.yaml files are the exception: when a colleague runs to11 code claude or to11 code codex inside the repository, the repository’s file decides the routing instead of theirs. The plugin is still installed for you, never into the repository’s agent settings.

​
Configure without a terminal

to11 ui needs a terminal and a person to sign in. For CI, a container, or a provisioning script, write the configuration yourself and set TO11_API_KEY. API keys are for machines like these; nothing stores one any more, and the credential order says which one a command uses:
Inject the key from your CI provider’s secret store rather than writing it into the command or the script — a value on the command line reaches your shell history and the environment of everything the script starts.

​
Check what you received

One row per skill, with its version, its state, the target it went to and where it came from. A skill your configuration names but that did not arrive is a row too, and its state is the reason. If something needs putting right, to11 skill sync runs an explicit sync and reports what changed, what it left alone, and what it could not place.

​
Next steps

CLI overview

What the CLI puts where, how refresh works, and what it never does.

Configuration

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

Publishing skills

Writing a skill, and releasing one to the people who follow a label.

Errors & exit codes

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