> ## 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. # Skills > Publish a coding-agent skill once, and every developer who follows it has the current version in the directories their agent reads. A coding agent is only as good as the instructions it has on hand: how your team triages an incident, reviews a migration, or names a feature flag. Those instructions usually live as a folder someone copied into `~/.claude/skills` months ago, and every copy drifts on its own schedule. to11 keeps them in one place. A skill is written once, stored as a version in a [project](/docs/platform/projects), and released on a label. Every developer who follows that label receives it — and receives the next version the same way — without anyone copying a file. ## How a skill travels ```text theme={null} author to11 project every developer ───────── ──────────── ─────────────── incident-triage/ incident-triage ~/.claude/skills/incident-triage SKILL.md ── store ──▶ v1 v2 v3 v4 ~/.agents/skills/incident-triage references/ ▲ │ release label: prod ─── sync ────▶ (current version, on disk) ``` Three separate acts move a skill from a folder to a machine: * **Store** writes a new immutable version of the whole folder. It moves no label, so nobody else receives it — the version lands on your own machine, pinned, so you can use it first. * **Release** points a label at a version. It is the one act other people feel: everyone following that label receives the version on their next sync. * **Sync** makes a machine match its configuration. It runs when a developer asks for it, and automatically while their agent is open. Keeping store and release apart is what lets you try a change on your own agent before it reaches anyone else, and roll a release back by pointing the label at an earlier version. ## Who decides what a machine receives What a developer receives is decided by configuration files, not by the platform: * **A developer's own file** (`~/.to11/skills.yaml`) names the projects and labels they follow, and which agents get the files. * **A repository's file** (`/.to11/skills.yaml`) is committed, so the skills a team relies on for work in that repository reach everyone who works there — in addition to their own. * **Turning a skill off always wins.** A developer can decline any skill, including one a repository asks for, and hold a skill at a version while the label moves on. The platform never pushes a file onto a machine that did not ask for it. See [Choosing which skills you receive](/docs/skills/choosing-skills) for the common cases, and the [configuration reference](/docs/reference/cli/configuration#precedence) for the exact precedence rules. ## Where the files land The CLI writes each skill where the agent already looks for skills, so there is no agent setting to change: | Agent | Directory | | - | - | | Claude Code | `.claude/skills/` | | Codex | `.agents/skills/` | Both are relative to your home directory for your own skills, and to the repository root for a repository's. A skill already in one of those directories that to11 did not write is left alone and reported. Only an explicit `to11 skill sync --force` replaces one that a published skill needs the name of. ## Staying current without asking The [to11 plugin](https://github.com/to11ai/to11-code-plugin), which `to11 ui` offers to install for Claude Code and Codex, refreshes skills while a session is open — when it starts, when you submit a prompt, and in Claude Code before a skill is used. A refresh inside the cache window (60 seconds by default) makes no request, and a refresh never blocks the work that triggered it. `to11 skill sync` refreshes on demand. ## Where to read and release them Skills are written as folders and stored from the [to11 CLI](/docs/reference/cli). The dashboard lists them beside your chat prompts, shows each file as a machine receives it, compares versions, and releases them. It does not edit them — a skill's source of truth is its folder. [What a skill is](/docs/skills/concepts) explains why, and what a skill can and cannot carry. Skills use the same permissions as prompts; there is no separate set. See [Roles & permissions](/docs/platform/roles-and-permissions). ## Next steps Receive a skill, publish your own, and release it — in one pass. The folder format, its limits, and what a skill cannot carry. Install the CLI and configure a machine or a repository. Store a version from a folder and release it on a label. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.