> ## 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. # CLI overview > The to11 CLI keeps your company's skills current on your machine, and runs your coding agent through the to11 gateway. The **to11 CLI** is a single binary, `to11`. It does two things: * keeps the [skills](/docs/platform/prompts/skills) your company publishes current in the directories your coding agent reads; * runs your agent with its traffic going through the [gateway](/docs/reference/api), 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](/docs/platform/prompts/skills#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](https://asdf-vm.com) plugin lives at [`to11ai/asdf-to11`](https://github.com/to11ai/asdf-to11), and every [release](https://github.com/to11ai/to11-cli/releases) carries the archives and a `checksums.txt` directly. There is no Windows build. [Receiving skills](/docs/platform/prompts/receiving-skills#install-the-cli) 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](/docs/platform/prompts/receiving-skills) for the walkthrough, and [`to11 init`](/docs/reference/cli/commands#to11-init) for every flag. ## What it puts where | Path | Holds | | ---------------------------- | -------------------------------------------------- | | `~/.to11/skills.yaml` | your [configuration](/docs/reference/cli/configuration) | | `~/.to11/.skills.state.json` | what the CLI last wrote, per file | | `~/.to11/credentials.json` | your credential, alone, at mode `0600` | | `~/.claude/skills/` | installed skills, for Claude Code | | `~/.agents/skills/` | installed skills, in the portable form | 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 `/.to11/skills.yaml`, and **both apply at once** — see [Configuration](/docs/reference/cli/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](/docs/reference/cli/errors#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`](/docs/reference/cli/commands#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 Every command, its flags, its conflicts, and what each deliberately does not do. The file that decides what you receive — including how to turn a skill off. Plain versus JSON, and what the JSON contract promises. What a failure looks like, and what keeps working when one happens.