Skip to main content
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, 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

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 (<repo>/.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 for the common cases, and the configuration reference 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: 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, 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. 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 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.

​
Next steps

Quickstart

Receive a skill, publish your own, and release it — in one pass.

What a skill is

The folder format, its limits, and what a skill cannot carry.

Receiving skills

Install the CLI and configure a machine or a repository.

Publishing skills

Store a version from a folder and release it on a label.