Gestion des skills : découverte, activation et priorité

Comment Vibe découvre les skills

Écrire un skill est une chose, savoir lequel s’exécute vraiment en est une autre. Mistral Vibe cherche les skills dans trois emplacements. Le répertoire global ~/.vibe/skills/ contient les skills disponibles dans tous vos projets. Le répertoire local .vibe/skills/, à la racine d’un dépôt, contient ceux qui n’ont de sens que pour ce projet. Enfin, des chemins custom définis dans votre config.toml permettent de pointer ailleurs sur le système.

Ces trois sources sont classées par ordre de priorité, et les skills locaux l’emportent sur les skills globaux en cas de conflit de nom. C’est ce qui vous permet de surcharger un skill global avec une version adaptée à un projet particulier, sans toucher à l’original.

Arborescence des skills

Les skills globaux vivent dans votre répertoire personnel, chacun dans son propre dossier contenant un SKILL.md. Ils sont disponibles partout, dans chaque projet où vous lancez Vibe.

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

Les skills locaux, eux, sont versionnés avec le code du projet. C’est l’endroit naturel pour un skill de déploiement ou de migration, qui dépend de l’infrastructure exacte du dépôt et n’aurait aucun sens ailleurs.

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

Restent les chemins custom, pour référencer des skills situés ailleurs sur votre système. Ils se déclarent dans la configuration :

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

C’est le mécanisme à privilégier pour partager des skills au sein d’une équipe, via un dossier réseau ou un dépôt Git cloné que chacun met à jour de son côté.

Activer et désactiver des skills

Par défaut, tous les skills découverts sont actifs. Deux réglages symétriques vous permettent de reprendre la main. Avec enabled_skills, vous passez en liste blanche : seuls les skills listés sont actifs, tous les autres sont ignorés.

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

Avec disabled_skills, vous restez en liste noire : tous les skills sont actifs sauf ceux que vous nommez. C’est le bon choix quand un seul skill vous gêne temporairement.

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

Patterns de filtrage

Ces deux champs acceptent trois formes d’écriture. La plus simple est le nom exact, qui convient tant que la liste reste courte :

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

Les patterns glob prennent le relais dès que vos noms suivent une convention. Le caractère * correspond à n’importe quelle séquence de caractères, ce qui permet de traiter une famille entière en une ligne :

# Activer tous les skills commençant par "test-"
enabled_skills = ["test-*"]

# Désactiver tous les skills expérimentaux
disabled_skills = ["experimental-*", "beta-*"]

Pour les cas que le glob ne couvre pas — une alternative, un motif au milieu du nom, un suffixe numérique — préfixez l’expression par re: afin d’utiliser une expression régulière :

# Activer les skills dont le nom contient "review" ou "audit"
enabled_skills = ["re:review|audit"]

# Désactiver les skills versionnés (ex: "tool-v1", "tool-v2")
disabled_skills = ["re:.*-v\d+"]

Priorité et résolution de conflits

Quand deux skills portent le même nom, Vibe tranche selon une hiérarchie fixe : le skill local dans .vibe/skills/ est prioritaire, un skill trouvé dans un chemin custom déclaré via skill_paths vient ensuite, et le skill global dans ~/.vibe/skills/ arrive en dernier. Autrement dit, plus un skill est proche du projet, plus il pèse lourd.

# Si code-review existe dans les trois emplacements :
.vibe/skills/code-review/SKILL.md          ← celui-ci est utilisé
~/shared/skills/code-review/SKILL.md       ← ignoré
~/.vibe/skills/code-review/SKILL.md        ← ignoré

Cette règle explique une confusion fréquente : vous modifiez votre skill global, rien ne change, parce qu’une version locale du même nom traînait dans le dépôt et continue de gagner.

Configuration par projet

Tous ces réglages se combinent dans un fichier .vibe/config.toml placé à la racine du projet. L’exemple ci-dessous montre les trois leviers ensemble : restreindre la liste aux skills pertinents, écarter ceux qui ne le sont pas, et ajouter le dossier partagé de l’équipe backend.

# mon-projet/.vibe/config.toml

# N'activer que les skills pertinents pour ce projet
enabled_skills = ["test-generator", "deploy-prod", "db-migrate"]

# Ou désactiver ceux qui ne sont pas pertinents
disabled_skills = ["doc-writer"]

# Ajouter des chemins supplémentaires
skill_paths = ["/home/equipe/backend-skills"]

Pour vérifier quels skills sont réellement disponibles dans votre contexte actuel, consultez la liste affichée par Vibe au démarrage, ou tapez la commande de listing dans la session interactive. C’est le premier réflexe à avoir quand une slash command attendue reste introuvable.

Points clés à retenir

• Vibe découvre les skills dans ~/.vibe/skills/, .vibe/skills/ et les skill_paths custom
• Les skills locaux ont priorité sur les skills globaux
• Utilisez enabled_skills ou disabled_skills pour contrôler l’activation
• Les patterns glob (test-*) et regex (re:review|audit) simplifient le filtrage
• Créez un .vibe/config.toml par projet pour personnaliser le contexte
• Partagez des skills en équipe via des skill_paths pointant vers un dossier commun