Mistral Skills : créer, partager et réutiliser des compétences pour vos agents

TL;DR

• Un skill est un ensemble d’instructions réutilisables qui apprend à un agent comment réaliser une tâche précise.
• Dans Mistral Vibe Code CLI, un skill est un répertoire contenant au minimum un fichier SKILL.md avec un frontmatter YAML et des instructions Markdown.
• La documentation Mistral suit la spécification Agent Skills, ce qui vise à rendre les skills portables vers d’autres agents compatibles.
• La vidéo montre une autre facette du sujet : création dans Studio, versionnement, partage dans un workspace, activation dans une conversation et association à un agent.
• Un skill n’est ni un modèle entraîné, ni un LoRA, ni un agent autonome. C’est du contexte structuré et réutilisable.
• Il faut examiner les outils autorisés, les sources et les instructions d’un skill avant de l’activer, surtout s’il peut écrire des fichiers ou exécuter des commandes.

La vidéo de référence

La vidéo de Xavki suit un cas d’usage concret : la création d’un skill pour produire un courrier de réclamation. L’objectif n’est pas seulement d’obtenir une lettre une fois, mais de capitaliser une méthode réutilisable : structure du courrier, informations attendues, contrôles, éventuelles références et règles de prudence.

La démonstration parcourt plusieurs dimensions importantes :

• la création du skill dans Studio ;
• sa conservation dans un workspace ;
• ses modifications et son historique de versions ;
• l’utilisation d’alias comparés à des tags Git ;
• son partage avec d’autres utilisateurs ;
• son activation dans une conversation ;
• son association à un agent spécialisé ;
• son utilisation depuis les interfaces de la suite Mistral.

L’interface montrée dans la vidéo correspond à un état précis du produit. Les noms d’écrans et certains parcours peuvent évoluer. La documentation officielle doit donc rester la référence pour les chemins, options et comportements actuels.

Mistral Skills : c’est quoi exactement ?

Un skill est un module de savoir-faire pour un agent. Il décrit une méthode, des règles, des ressources et éventuellement les outils nécessaires pour accomplir une tâche.

On peut le résumer ainsi :

Un prompt ponctuel :
  « Écris-moi une lettre de réclamation. »

Un skill réutilisable :
  « Voici la structure, les informations à demander,
   les contrôles à effectuer, les sources à employer,
   les précautions à respecter et le format de sortie. »

La documentation de Mistral définit les skills comme des ensembles d’instructions réutilisables capables d’étendre Vibe Code avec de nouveaux workflows, des commandes slash personnalisées et des ensembles d’outils limités.

Le mot important est « réutilisable ». Le skill évite de recopier un long prompt à chaque conversation. Il donne également un point commun à une équipe : la même méthode peut être relue, versionnée et améliorée collectivement.

Skill, prompt, outil et agent : quelles différences ?

Élément	Rôle principal
Prompt	Demande ou contexte envoyé pour une interaction
Skill	Méthode réutilisable pour réaliser une tâche
Outil	Capacité d’action : lire, rechercher, écrire, exécuter
Agent	Entité qui raisonne, sélectionne des skills et appelle des outils
Modèle	Moteur de langage qui produit les réponses

Un skill ne remplace pas le modèle. Il ne modifie pas les poids du modèle comme le ferait un fine-tuning ou un LoRA. Il fournit des instructions et des ressources au bon moment.

Un agent peut utiliser plusieurs skills. Par exemple, un agent de support pourrait combiner :

1. un skill pour analyser une réclamation ;
2. un skill pour vérifier les informations obligatoires ;
3. un skill pour rédiger la réponse ;
4. un outil pour créer un ticket ou envoyer un message, si cette action est autorisée.

La vidéo évoque ce type d’enchaînement, mais démontre volontairement un scénario plus simple : un agent spécialisé utilise essentiellement le skill de courrier de réclamation.

Le format d’un skill dans Mistral Vibe Code CLI

Dans Vibe Code CLI, un skill est un répertoire contenant un fichier SKILL.md. Ce fichier commence par un frontmatter YAML, puis contient les instructions en Markdown.

Exemple adapté de la documentation Mistral :

---
name: code-review
description: Effectuer une revue de code structurée.
license: MIT
compatibility: Python 3.12+
user-invocable: true
allowed-tools:
  - read_file
  - grep
  - ask_user_question
---

# Revue de code

Analyse les risques fonctionnels, les régressions,
la sécurité et les tests manquants avant de résumer les changements.

Les champs les plus utiles sont :

• name : nom du skill et identifiant d’invocation ;
• description : résumé visible dans la liste des skills ;
• user-invocable : expose le skill comme commande slash lorsqu’il vaut true ;
• allowed-tools : limite les outils accessibles au skill ;
• license et compatibility : précisent les conditions d’utilisation et les prérequis.

La commande devient alors accessible sous une forme proche de :

/code-review

Cette simplicité est importante : un skill peut être relu comme de la documentation, versionné comme du code et invoqué comme une commande.

Où placer les skills dans Vibe Code CLI ?

La documentation Mistral décrit plusieurs emplacements de découverte, avec un ordre de priorité :

Chemins personnalisés

Ils sont déclarés dans config.toml :

skill_paths = ["/chemin/vers/mes/skills"]

Skills du projet

Ils peuvent être stockés dans :

./.vibe/skills/
./.agents/skills/

La documentation précise que ces skills sont pris en compte lorsque le répertoire de travail est approuvé comme dossier de confiance.

Ce niveau convient aux compétences propres à un dépôt : conventions de tests, procédure de release, règles d’architecture ou format de revue de code. Le skill suit alors le projet et peut passer par une revue de code classique.

Skills de l’utilisateur

Les compétences personnelles peuvent être placées dans :

~/.vibe/skills/

Ce niveau convient aux méthodes utilisées dans plusieurs projets sans être imposées à toute l’équipe.

Activer, désactiver et filtrer des skills

Vibe Code CLI permet de contrôler les skills chargés avec des motifs :

enabled_skills = ["code-review", "test-*"]
disabled_skills = ["experimental-*"]

Les filtres prennent en charge :

• les noms exacts ;
• les motifs glob comme test-* ;
• les expressions régulières préfixées par re:.

Lorsque enabled_skills n’est pas vide, cette liste agit comme une liste d’autorisation. Sinon, les skills découverts sont disponibles, à l’exception de ceux correspondant à disabled_skills.

Ce mécanisme évite de charger sans discernement toute une bibliothèque de compétences. Il permet aussi de séparer des skills stables de skills expérimentaux.

Le cas pratique de la vidéo : un courrier de réclamation

Le skill construit dans la vidéo cherche à standardiser un courrier comprenant notamment :

1. les coordonnées de l’expéditeur ;
2. les coordonnées du destinataire ;
3. le lieu et la date ;
4. l’objet du courrier ;
5. les références du dossier ou du contrat ;
6. les faits et le problème rencontré ;
7. la demande formulée ;
8. les éventuelles références utiles ;
9. la formule de politesse ;
10. la signature.

Le skill ajoute également des contrôles : vérifier les informations, ne pas citer mécaniquement des textes juridiques, évaluer leur pertinence et relire le résultat avant envoi.

La démonstration montre un intérêt concret. L’utilisateur peut donner des informations « en vrac » dans la conversation. L’agent les réorganise selon la méthode définie dans le skill. Si une date ou une référence manque, elle peut être demandée ou ajoutée avant de finaliser le courrier.

La vidéo rappelle implicitement une règle essentielle : un skill améliore la cohérence d’un processus, mais ne garantit pas l’exactitude juridique. La vérification humaine reste nécessaire.

Ajouter des ressources et des modèles à un skill

La vidéo propose une évolution possible : accompagner les instructions d’un modèle de document.

reclamation-letter/
├── SKILL.md
└── templates/
    └── modele-courrier.txt

Le fichier SKILL.md pourrait expliquer :

• comment identifier les variables ;
• quelles informations demander à l’utilisateur ;
• quelles parties du modèle sont constantes ;
• quand le modèle est obligatoire ou seulement recommandé ;
• comment traiter une information manquante ;
• quelles vérifications effectuer avant de rendre le résultat.

Cette séparation évite de surcharger les instructions avec de longs exemples. Elle rend aussi le modèle de courrier modifiable indépendamment de la méthode générale.

Versionner et partager les compétences

L’un des apports les plus intéressants de la vidéo concerne la gouvernance. Le skill n’est pas présenté comme un prompt perdu dans un historique de chat, mais comme un actif réutilisable.

La démonstration montre :

• la modification d’un skill ;
• la création d’une nouvelle version ;
• l’affichage de l’historique ;
• le retour à une version antérieure ;
• l’ajout d’un alias comparable à un tag Git ;
• le partage au niveau du workspace ;
• la publication ou la mise à disposition dans les interfaces Mistral.

Dans une équipe, cette approche répond à plusieurs questions : qui maintient le skill ? Qui peut le modifier ? Quelle version est utilisée en production ? Comment revenir en arrière ? Comment relire une modification avant de la partager ?

Pour Vibe Code CLI, le stockage dans ./.vibe/skills/ ou ./.agents/skills/ apporte une réponse familière aux développeurs : les changements sont suivis par Git et examinés dans une merge request ou une pull request.

Utiliser un skill dans une conversation ou un agent

La vidéo présente plusieurs modes d’utilisation dans la suite Mistral :

• sélection explicite du skill dans une conversation ;
• activation par défaut ;
• activation obligatoire ;
• association du skill aux instructions d’un agent ;
• mise à disposition de l’agent dans une interface conversationnelle ;
• utilisation potentielle de plusieurs skills dans un processus plus large.

Dans Vibe Code CLI, un skill avec user-invocable: true devient une commande slash. L’utilisateur garde ainsi un déclenchement explicite et compréhensible.

Ces deux surfaces ne doivent pas être confondues : la vidéo montre principalement une expérience gérée dans la suite Mistral, alors que la documentation fournie décrit le format de fichiers et la découverte des skills dans Vibe Code CLI. Le concept est commun, mais les interfaces et les mécanismes d’administration diffèrent.

Sécuriser un skill avec allowed-tools

Un skill peut guider un agent vers des outils capables de lire, d’écrire ou d’exécuter des actions. Il faut donc appliquer le principe du moindre privilège.

Exemple limité à l’analyse :

allowed-tools:
  - read_file
  - grep
  - ask_user_question

Cette liste permet de lire et rechercher des informations, mais pas d’écrire un fichier ni d’exécuter une commande arbitraire.

La documentation Mistral recommande notamment :

• de relire un skill avant de l’activer s’il peut appeler des outils d’écriture ;
• de préférer une liste allowed-tools courte et explicite ;
• de conserver les skills spécifiques au projet dans le dépôt afin qu’ils puissent être examinés en revue de code.

Un skill est une entrée de confiance. Une instruction malveillante, une ressource compromise ou un outil trop puissant peut transformer une simple aide en risque opérationnel.

Skill ou simple prompt : quand investir ?

Un prompt ponctuel suffit lorsque :

• la tâche ne sera réalisée qu’une fois ;
• le format de sortie importe peu ;
• aucune source ou procédure commune n’est nécessaire ;
• la réponse ne déclenche pas d’action sensible.

Un skill devient intéressant lorsque :

• la tâche revient régulièrement ;
• plusieurs personnes doivent suivre la même méthode ;
• le contexte est long ou complexe ;
• des ressources et outils doivent être encadrés ;
• la compétence doit être versionnée, partagée et auditée ;
• le format de sortie doit rester stable.

Le coût de maintenance compte aussi. Un skill obsolète peut continuer à diffuser une mauvaise procédure. Il faut donc prévoir un propriétaire, des tests et une fréquence de révision.

Bonnes pratiques pour écrire un Mistral Skill

Définir une tâche étroite

« Aider sur Kubernetes » est trop vague. « Diagnostiquer un pod Pending à partir des événements fournis » est observable et testable.

Expliquer le résultat attendu

Définissez le format, les champs obligatoires, le niveau de détail et les cas où l’agent doit demander une clarification.

Séparer règles et ressources

Gardez la méthode dans SKILL.md et placez les modèles, exemples ou documents volumineux dans des fichiers distincts.

Limiter les outils

N’autorisez que les outils nécessaires. Un skill de rédaction n’a généralement pas besoin d’un shell complet.

Prévoir l’incertitude

Indiquez à l’agent de ne pas inventer une donnée absente et de demander confirmation avant toute action irréversible.

Tester avec plusieurs formulations

Un skill robuste doit fonctionner avec une demande complète, une demande désordonnée, des informations manquantes et un cas hors périmètre.

Versionner et relire

Traitez un skill comme du code : historique, revue, tests, propriétaire et possibilité de retour arrière.

Exemple minimal de skill réutilisable

Voici un exemple simple pour préparer un diagnostic Kubernetes sans autoriser de modification du cluster :

---
name: k8s-first-diagnosis
description: Préparer un diagnostic Kubernetes de premier niveau.
user-invocable: true
allowed-tools:
  - read_file
  - grep
  - ask_user_question
---

# Diagnostic Kubernetes

1. Résumer les symptômes fournis par l'utilisateur.
2. Distinguer les faits des hypothèses.
3. Proposer des commandes de lecture uniquement.
4. Expliquer le résultat attendu de chaque commande.
5. Ne jamais inventer une sortie de commande.
6. Demander confirmation avant toute proposition de modification.

Format de sortie :
- Symptômes
- Hypothèses classées
- Vérifications
- Interprétation attendue
- Prochaine étape sûre

Ce skill n’accorde pas de droit d’écriture et ne prétend pas agir sur le cluster. Il structure le raisonnement et rend la réponse plus facile à relire.

Limites à connaître

Un skill ne résout pas automatiquement :

• les hallucinations du modèle ;
• les informations absentes ou obsolètes ;
• les erreurs dans les sources fournies ;
• les permissions excessives accordées aux outils ;
• les conflits entre plusieurs instructions ;
• la nécessité d’une validation humaine dans un domaine sensible.

Il faut également distinguer un skill d’un système de recherche documentaire. Pour des informations qui changent fréquemment, une source actualisée ou une approche RAG peut être plus adaptée que des instructions statiques.

Liens utiles

• Vidéo : Mistral Skills, utilisation et gestion dans la suite
• Documentation officielle : Skills dans Vibe Code CLI
• Spécification Agent Skills
• Vue d’ensemble de Mistral Vibe
• Installation et configuration de Vibe Code CLI
• Sécurité, approbations et permissions de Vibe Code
• Dépôt des tutoriels vLLM de la chaîne Xavki
• Projets GitLab de Xavki

FAQ sur Mistral Skills

Qu’est-ce qu’un Mistral Skill ?

Un Mistral Skill est un ensemble d’instructions réutilisables qui apprend à un agent comment accomplir une tâche précise. Dans Vibe Code CLI, il est stocké dans un répertoire contenant un fichier SKILL.md.

Un skill entraîne-t-il le modèle ?

Non. Un skill ne modifie pas les poids du modèle. Il fournit du contexte, des règles, des ressources et éventuellement une liste d’outils autorisés au moment de l’utilisation.

Quelle différence entre un skill et un agent ?

Le skill représente une compétence ou une méthode. L’agent représente un rôle ou un processus capable d’utiliser un ou plusieurs skills et d’appeler des outils.

Où installer un skill Vibe Code ?

La documentation indique les chemins personnalisés configurés dans config.toml, les répertoires de projet ./.vibe/skills/ et ./.agents/skills/, ainsi que le répertoire utilisateur ~/.vibe/skills/.

Comment transformer un skill en commande slash ?

Ajoutez user-invocable: true dans le frontmatter YAML. Le nom du skill devient alors disponible comme commande slash dans le CLI et dans le sélecteur compatible de l’extension VS Code.

Peut-on limiter les outils utilisés par un skill ?

Oui. Le champ allowed-tools permet d’autoriser uniquement les outils nécessaires. Cette restriction est recommandée pour réduire les risques.

Les skills sont-ils portables vers d’autres agents ?

Mistral indique suivre la spécification Agent Skills. Les skills respectant cette spécification visent donc une meilleure portabilité vers les autres agents qui l’adoptent. Il faut néanmoins vérifier les noms d’outils et les extensions propres à chaque plateforme.

Faut-il vérifier la sortie d’un skill ?

Oui. Un skill structure la réponse, mais le modèle peut toujours se tromper. Les contenus juridiques, financiers, médicaux ou les actions d’administration doivent rester soumis à une validation humaine adaptée.

Conclusion

Mistral Skills transforme une instruction utile en compétence réutilisable. La vidéo montre l’intérêt organisationnel de cette approche : créer une méthode, la faire évoluer, la versionner, la partager dans un workspace et l’associer à un agent. La documentation Vibe Code CLI apporte la vue développeur : un répertoire, un fichier SKILL.md, un frontmatter clair, des commandes slash et des outils explicitement limités.

Le principal bénéfice n’est pas de rendre magiquement un modèle plus intelligent. Il est de rendre les méthodes plus cohérentes, plus visibles et plus gouvernables. Pour obtenir un skill réellement utile, il faut le traiter comme un petit produit logiciel : définir son périmètre, relire ses instructions, limiter ses permissions, tester plusieurs cas et maintenir ses versions dans le temps.