Managing skills: discovery, activation, and priority

Lesson updated November 2, 2026 based on the Vibe documentation Skills page: added .agents/skills/ locations, official discovery order (custom paths, project, user), and the /reload command. The documentation does not define a priority rule for two skills with the same name; the previous version described one. Source: Skills.

How Vibe discovers skills

Writing a skill is one thing; knowing which one actually runs is another. The documentation specifies the order in which Vibe discovers skills:

1. Custom paths declared in config.toml using skill_paths;
2. Project skills, located in ./.vibe/skills/ or ./.agents/skills/, loaded only if the folder is trusted;
3. User skills, located in ~/.vibe/skills/ or ~/.agents/skills/.

The .agents/skills/ folders follow the open Agent Skills specification: a skill stored there is shared with other agents that adopt the same specification. An active session picks up added or modified skills; if a change doesn’t appear, type /reload.

Skills directory structure

Global skills live in your home directory, each in its own folder containing a SKILL.md. They are available everywhere, in every project where you run Vibe.

~/.vibe/skills/
├── code-review/
│   └── SKILL.md
├── test-generator/
│   └── SKILL.md
└── doc-writer/
    └── SKILL.md

Local skills, on the other hand, are versioned with the project code. This is the natural place for a deployment or migration skill, which depends on the repository’s exact infrastructure and would make no sense elsewhere.

mon-projet/
├── .vibe/
│   └── skills/
│       ├── deploy-prod/
│       │   └── SKILL.md
│       └── db-migrate/
│           └── SKILL.md
├── src/
└── package.json

Finally, there are custom paths, used to reference skills located elsewhere on your system. You declare these in the configuration:

# ~/.vibe/config.toml
skill_paths = [
  "/home/equipe/shared-skills",
  "/opt/company-skills"
]

This is the preferred mechanism for sharing skills within a team, via a network folder or a cloned Git repository that everyone updates on their end.

Enabling and disabling skills

By default, all discovered skills are active. Two symmetric settings let you take back control. With enabled_skills, you switch to a whitelist: only the listed skills are active; all others are ignored.

# ~/.vibe/config.toml
enabled_skills = ["code-review", "test-generator"]

With disabled_skills, you stay on a blacklist: all skills are active except those you name. This is the right choice when a single skill is temporarily getting in your way.

# ~/.vibe/config.toml
disabled_skills = ["experimental-feature"]

Filtering patterns

Both fields accept three forms of input. The simplest is the exact name, which works as long as the list stays short:

enabled_skills = ["code-review", "test-generator", "doc-writer"]

Glob patterns take over once your names follow a convention. The * character matches any sequence of characters, letting you handle an entire family in one line:

# Enable all skills starting with "test-"
enabled_skills = ["test-*"]

# Disable all experimental skills
disabled_skills = ["experimental-*", "beta-*"]

For cases that globs don’t cover—an alternative, a pattern in the middle of a name, a numeric suffix—prefix the expression with re: to use a regular expression:

# Enable skills whose name contains "review" or "audit"
enabled_skills = ["re:review|audit"]

# Disable versioned skills (e.g., "tool-v1", "tool-v2")
disabled_skills = ['re:.*-v\d+']   # literal string: the backslash does not need escaping

Two skills with the same name

The documentation does not describe a priority rule for two skills bearing the same name in different locations. So don’t count on implicit “overriding”: give them distinct names (code-review-backend rather than a second code-review), and verify what is actually loaded. In the / menu, each skill’s description starts with its scope, project, user, or vibe, which is enough to spot a duplicate. A skill named like a built-in command does not appear in this menu.

Project-level configuration

All these settings combine in a .vibe/config.toml file placed at the project root. The example below shows all three levers together: restrict the list to relevant skills, exclude those that aren’t, and add the backend team’s shared folder.

# mon-projet/.vibe/config.toml

# Enable only skills relevant to this project
enabled_skills = ["test-generator", "deploy-prod", "db-migrate"]

# Or disable those that aren't relevant
disabled_skills = ["doc-writer"]

# Add additional paths
skill_paths = ["/home/equipe/backend-skills"]

To verify which skills are actually available, open the / menu in the session: each skill appears there with its scope. This is the first reflex when an expected slash command remains missing, before trying /reload and checking the trust status of the folder.

Key takeaways

• Vibe discovers skills in ~/.vibe/skills/, .vibe/skills/, and custom skill_paths
• Local skills take priority over global skills
• Use enabled_skills or disabled_skills to control activation
• Glob patterns (test-*) and regex (re:review|audit) simplify filtering
• Create a .vibe/config.toml per project to customize the context
• Share skills across a team via skill_paths pointing to a common folder