> ## Documentation Index
> Fetch the complete documentation index at: https://to11.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Receiving skills

> Configure the to11 CLI once so the skills your company publishes land in the directories your coding agent reads, and stay current from then on.

You need the `to11` binary on your `PATH` and a to11 account in your company's organization. Nothing else — [skills](/docs/skills/concepts) 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.

<CodeGroup>
  ```bash macOS theme={null}
  brew install to11ai/tap/to11
  ```

  ```bash Ubuntu & Debian theme={null}
  echo "deb [trusted=yes] https://apt.fury.io/to11/ /" | sudo tee /etc/apt/sources.list.d/to11.list
  sudo apt update
  sudo apt install to11
  ```

  ```bash Fedora & RHEL theme={null}
  sudo tee /etc/yum.repos.d/to11.repo <<EOF
  [to11]
  name=to11 Repository
  baseurl=https://yum.fury.io/to11/
  enabled=1
  gpgcheck=0
  EOF

  sudo dnf install to11
  ```
</CodeGroup>

### Install with `asdf`

```bash theme={null}
asdf plugin add to11 https://github.com/to11ai/asdf-to11
asdf install to11 latest
asdf set --home to11 latest
```

`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](https://github.com/to11ai/to11-cli/releases) carries one archive per platform, `to11_<version>_<os>_<arch>.tar.gz`, a `checksums.txt`, and that file's [cosign](https://docs.sigstore.dev/cosign/installation/) 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:

```bash theme={null}
VERSION=0.9.0 OS=darwin ARCH=arm64
ARCHIVE="to11_${VERSION}_${OS}_${ARCH}.tar.gz"
BASE="https://github.com/to11ai/to11-cli/releases/download/v${VERSION}"

curl -fsSLO "$BASE/$ARCHIVE"
curl -fsSLO "$BASE/checksums.txt"
curl -fsSLO "$BASE/checksums.txt.sigstore.json"

grep -qF "  $ARCHIVE" checksums.txt || { echo "no checksum entry for $ARCHIVE" >&2; exit 1; }

cosign verify-blob \
  --bundle checksums.txt.sigstore.json \
  --certificate-identity-regexp '^https://github\.com/to11ai/platform/\.github/workflows/cli-release-binaries\.yml@.*$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  checksums.txt \
  && grep -F "  $ARCHIVE" checksums.txt | shasum -a 256 -c - \
  && tar -xzf "$ARCHIVE" to11 \
  && mkdir -p ~/.local/bin \
  && install -m 0755 to11 ~/.local/bin/to11 \
  && ~/.local/bin/to11 version
```

`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 `grep`s 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.

<Note>
  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.
</Note>

## Configure this machine

```bash theme={null}
to11 ui
```

`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](/docs/instrument/coding-agents) covers it.

If a published skill would land on a directory name you already use, set [`prefix`](/docs/reference/cli/configuration#where-skills-land) 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:

```text theme={null}
Where do you want to set up to11?
> [Repository]  ~/src/acme/web  committed, for everyone who works here  not set up
  [Your  Home]  ~/.to11         only you, in every directory
```

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](/docs/reference/cli/configuration), 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](/docs/reference/cli/configuration) yourself and set `TO11_API_KEY`. API keys are for machines like these; nothing stores one any more, and [the credential order](/docs/reference/cli/configuration#which-credential-a-command-uses) says which one a command uses:

```bash theme={null}
mkdir -p ~/.to11
cat > ~/.to11/skills.yaml <<'EOF'
version: 1
organization: acme
projects:
  - project: sre/runbooks
    label: prod
EOF
to11 skill sync
```

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

```bash theme={null}
to11 skill list
```

One row per skill, with its version, its [state](/docs/reference/cli/output#states), 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

<CardGroup cols={2}>
  <Card title="CLI overview" icon="terminal" href="/docs/reference/cli">
    What the CLI puts where, how refresh works, and what it never does.
  </Card>

  <Card title="Configuration" icon="file-code" href="/docs/reference/cli/configuration">
    The file that decides what you receive — including how to turn a skill off.
  </Card>

  <Card title="Publishing skills" icon="pen-line" href="/docs/skills/publishing-skills">
    Writing a skill, and releasing one to the people who follow a label.
  </Card>

  <Card title="Errors & exit codes" icon="triangle-alert" href="/docs/reference/cli/errors">
    What a failure looks like, and what keeps working when one happens.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.