Skip to main content
You need the to11 binary on your PATH and one to11 init — Receiving skills covers both. For what a skill is, and why the browser reads them but does not write them, see Skills.

​
Write the folder

A skill is a directory whose entry document is SKILL.md:
Write it yourself, or let a coding agent write it — New skill on the project’s prompts list hands you a prompt to paste into one. Either way, the folder is what gets stored. Stay inside the limits: at most 128 files, 512 KB in any one file, 4 MB across all of them, UTF-8 text with \n line endings. Do not reach for template syntax — a skill has no variables, and publishing one containing {{ … }} is refused rather than delivered literally to an agent.

​
Store a version

Exactly one content source is required: --dir for a folder, --from <file> (or - for stdin) for a single file, --body <text> for inline text. A new skill needs a description, and the flag is one of two ways to give it. Creating takes --description when you pass it and the entry document’s frontmatter when you do not — with any content source, since --from and --body both become a SKILL.md too. Only an empty result is an error. Afterward the order reverses for a directory. --dir takes the description from the entry document and reports the flag ignored, while --from and --body take it from the flag. So changing an existing skill’s description through a directory store means changing it in SKILL.md; passing it on the command line will not. An entry document carrying no description changes nothing — the stored description stays as it was, without an error. Storing moves no label, so nobody else receives it. The version lands on this machine too, pinned, so you can use the skill before anyone else sees it — pass --no-install if you would rather it did not. On an existing skill, --dir replaces the file set. A file missing from the directory is missing from the new version. Read the first word of the output before going further:
created where you expected stored means a typo made a second skill. Nothing is published yet, so store into the right slug and leave the stray one unreleased. If the slug is already taken by a chat prompt, the store fails and names it. A skill’s slug can be changed and a chat prompt’s cannot, so the skill is what moves aside.

​
Release it

That moves the project’s configured label to the newest stored version, and everyone who follows that label receives it on their next sync. Use --label <slug> for a different label, and --version <n> for a version other than the newest. This is the only command that makes a skill reach anyone else.

​
Change one later

Edit the folder and store again. Every store adds an immutable version and moves nothing, so releasing is a separate decision each time. To take a release back, point the label at an earlier version with to11 skill release <slug> --version <n>. If you edited an installed skill in place, sync leaves the whole of it alone and the row reads dirty. Keep your edit with to11 skill store, or discard it with to11 skill sync --force.

​
Next steps

Skills

What a skill is, what it cannot carry, and what the dashboard shows.

CLI commands

Every command and flag, and what each one refuses to do.

Versions & releases

How labels, versions and rollbacks work for both kinds of prompt.

Receiving skills

Configure a machine so released skills land where an agent reads them.