> ## 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. # Choosing which skills you receive > Turn a skill off, hold one at a version, take a single skill from a project, or share a set of skills with everyone who works in a repository. Which skills reach a machine, and at which version, is decided by lines in a configuration file — not by commands. Each task below is one edit to `skills.yaml`, followed by: ```bash theme={null} to11 skill sync to11 skill list ``` `sync` applies the change and reports what it did; `list` shows the result, one row per skill and agent. Your own file is `~/.to11/skills.yaml`; a repository's is `/.to11/skills.yaml`. If you have neither, run `to11 ui` first — see [Receiving skills](/docs/skills/receiving-skills). Every key used here is described in the [configuration reference](/docs/reference/cli/configuration#every-key). ## Turn a skill off Name it under the project entry it comes from, with `disabled: true`: ```yaml theme={null} projects: - project: sre/runbooks label: prod skills: legacy-migration: { disabled: true } ``` The next sync removes the files it installed. Any file in that directory you changed or added stays, and the skill reads `orphaned` until you delete it yourself. A disable in your own file always wins. It also keeps the skill out of a repository whose configuration asks for it, when both configurations name the same organization and the same project. Both must name the project the same way: by `workspace/project`, or by id. ## Hold a skill at a version Pin it with `version`: ```yaml theme={null} skills: incident-triage: { version: 4 } ``` The skill stays at v4 while the label moves on. `to11 skill list` shows `pinned 4 (prod: 7)` once the label is ahead, and sync leaves it alone. Remove the line to follow the label again. A pin in your own file is a preference: a repository's configuration can still decide the version in that repository's tree. To insist, add `enforced: true` — see [Precedence](/docs/reference/cli/configuration#precedence). ## Follow a different label for one skill Give that skill its own `label`, and the rest of the project keeps following the project's: ```yaml theme={null} - project: sre/runbooks label: prod skills: incident-triage: { label: beta } ``` ## Take one skill without the whole project Leave `label` off the project entry. Only the skills named under it are installed, and each says what it follows: ```yaml theme={null} - project: web/checklists skills: release-checklist: { label: prod } ``` ## Share a set of skills with a repository Run `to11 ui` inside the repository and choose **Repository**: ```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 ``` It writes `/.to11/skills.yaml`. Commit it, and everyone who works in the repository receives those skills in the repository's own `.claude/skills` and `.agents/skills` directories — in addition to their own. A repository's file never changes a colleague's own directories, targets or refresh behavior, and it cannot override a skill they have turned off. ## Avoid a name you already use If a published skill would land on a directory name you already have, set a `prefix`. Every skill from to11 then lands as `-`: ```yaml theme={null} prefix: acme ``` A directory in a skills folder that to11 did not write is not touched by a normal sync. `to11 skill list` shows it as `unmanaged`, or as `conflict` when a skill your configuration asks for wants its name — and only `to11 skill sync --force` replaces a `conflict`. ## Next steps Every key, and exactly how your file and a repository's combine. What each state in `to11 skill list` means, and how to fix the ones that need you. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.