Gestion des skills : découverte, activation et priorité — Mistral Vibe Avancé — Agents, Skills et Mode Local

Leçon mise à jour le 2 novembre 2026 d’après la page Skills de la documentation de Vibe : emplacements .agents/skills/ ajoutés, ordre de découverte officiel (chemins personnalisés, projet, utilisateur) et commande /reload. La documentation ne fixe pas de règle de priorité entre deux skills du même nom : la version précédente en décrivait une. Source : Skills.

Comment Vibe découvre les skills

Écrire un skill est une chose, savoir lequel s’exécute vraiment en est une autre. La documentation donne l’ordre dans lequel Vibe découvre les skills :

les chemins personnalisés déclarés dans config.toml avec skill_paths ;
les skills du projet, dans ./.vibe/skills/ ou ./.agents/skills/, chargés seulement si le dossier est de confiance ;
les skills de l’utilisateur, dans ~/.vibe/skills/ ou ~/.agents/skills/.

Les dossiers .agents/skills/ suivent la spécification ouverte Agent Skills : un skill qui y vit est partagé avec les autres agents qui adoptent la même spécification. Une session en cours prend en compte les skills ajoutés ou modifiés ; si un changement n’apparaît pas, tapez /reload.

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+']   # chaîne littérale : la barre oblique inverse n'a pas à être échappée

Deux skills du même nom

La documentation ne décrit pas de règle de priorité entre deux skills qui portent le même nom dans des emplacements différents. Ne comptez donc pas sur une « surcharge » implicite : donnez des noms distincts (code-review-backend plutôt qu’un second code-review), et vérifiez ce qui est réellement chargé. Dans le menu /, la description de chaque skill commence par sa portée, project, user ou vibe, ce qui suffit à repérer un doublon. Un skill nommé comme une commande intégrée n’apparaît pas dans ce menu.

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, ouvrez le menu / dans la session : chaque skill y figure avec sa portée. C’est le premier réflexe quand une slash command attendue reste introuvable, avant /reload et la vérification de la confiance accordée au dossier.

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