Pourquoi une méthode, et pas juste un fichier
À l'étape 2, vous avez vu l'anatomie : frontmatter, description, corps, scripts. On pourrait croire qu'il suffit de remplir les cases. C'est le piège dans lequel tombent la plupart des premières skills — et la raison pour laquelle tant d'entre elles finissent en fichiers morts : jamais chargées, ou chargées à contretemps, ou chargées mais trahies par des instructions ambiguës.
Une skill est un petit objet, mais un objet testable, avec un cycle de vie. La méthode qui suit la traite comme telle. Cinq temps, chacun avec son livrable et son critère de sortie :
Déroulons chaque temps sur notre fil rouge — la skill de compte-rendu de réunion — jusqu'au fichier complet en fin d'étape.
① Cadrer : une skill, une tâche, un critère
Avant d'écrire la moindre ligne du fichier, une page de cadrage qui répond à trois questions :
Quelle tâche, au singulier ? « Rédiger le compte-rendu d'une réunion à partir de notes brutes. » Pas « gérer la documentation des réunions » (trois tâches déguisées : rédiger, archiver, diffuser), pas « aider l'équipe à mieux communiquer » (un vœu, pas une tâche). Le test du singulier : si votre phrase de cadrage contient un « et », vous avez probablement deux skills.
Quel savoir-faire implicite ? C'est la question la plus rentable du cadrage. Interrogez la personne qui fait bien cette tâche aujourd'hui : qu'est-ce qu'elle sait qu'un nouveau venu raterait ? Pour notre CR : « jamais d'action sans porteur ni échéance », « on n'interprète pas les intentions », « les sujets RH ne vont pas dans un CR diffusé ». Ces règles tacites sont le cœur de la valeur — une skill qui ne capture que l'évident ne vaut pas son coût de maintenance.
Comment jugera-t-on le résultat ? Un critère observable, écrit avant de commencer : « un lecteur absent de la réunion sait quoi faire lundi matin, en moins d'une page ». C'est lui qui servira d'arbitre au temps ④ — sans critère posé à froid, le test devient un concours d'impressions.
Livrable du temps ① : la page de cadrage. Critère de sortie : les trois réponses tiennent chacune en une phrase.
② Décrire : le déclencheur avant tout
Contre-intuitif mais capital : on écrit la description avant les instructions. Parce qu'une skill au corps parfait mais à la description ratée n'est jamais chargée — elle n'existe pas, comme on l'a vu à l'étape 2. Le déclenchement est la fonctionnalité numéro un ; on la conçoit en premier.
La méthode en trois gestes :
Collecter les formulations réelles. Pas celles que vous trouvez élégantes : celles que vos utilisateurs tapent. Relevez cinq à dix demandes authentiques — messages Slack, mails, tickets. Pour notre fil rouge : « tu peux me faire le CR ? », « il me faut le compte-rendu de la réu produit », « balance-moi le relevé de décisions », « synthèse de la réunion de ce matin stp ». Le vocabulaire de déclenchement est là-dedans, pas dans votre tête.
Écrire quoi + quand. Première phrase : ce que la skill produit, concrètement. Seconde : les situations qui doivent la déclencher, avec les mots collectés — « compte-rendu », « CR », « relevé de décisions », « synthèse de réunion ».
Passer le test de la porte. Relisez votre description en vous demandant : sur chacune des demandes collectées, un modèle qui ne voit que ces lignes chargerait-il la skill ? Et sur une demande voisine mais hors périmètre — « rédige l'ordre du jour de la prochaine réunion » — la laisserait-il passer ? Une bonne description est une porte : elle ouvre sur le périmètre, elle reste fermée à côté.
Livrable du temps ② : 3 à 5 lignes de description. Critère de sortie : le test de la porte passe mentalement sur vos dix formulations collectées.
③ Instruire : le corps du manuel
Maintenant seulement, les instructions. La structure éprouvée, celle de l'anatomie de l'étape 2, dans l'ordre où le modèle en a besoin :
La procédure nominale d'abord — la structure de sortie attendue, section par section, avec les règles de forme (« une décision par puce, au passé composé »). C'est le chemin heureux, celui de 80 % des exécutions.
Le ton et les limites ensuite — factuel, une page maximum, pas d'interprétation des intentions. Court : chaque règle de style doit se justifier par un écart réellement constaté ou redouté.
Les cas limites enfin — et c'est ici que se joue la différence entre une skill correcte et une skill de production. Reprenez le savoir-faire implicite du temps ① et transformez chaque règle tacite en conduite écrite : notes contradictoires → produire le CR des points clairs et lister les zones d'ombre ; information sensible → exclure du CR, signaler au demandeur. La règle d'or : chaque ambiguïté tranchée dans le fichier est une improvisation évitée en production.
Un exemple de référence complet (un CR modèle dans templates/) vaut souvent dix règles supplémentaires : le modèle imite mieux qu'il n'interprète.
Livrable du temps ③ : le corps du SKILL.md + l'exemple de référence. Critère de sortie : un collègue qui découvre la skill peut exécuter la tâche à la main en suivant uniquement le fichier.
④ Tester : le déclenchement d'abord, le contenu ensuite
Le temps que tout le monde saute — et qui distingue une skill artisanale d'une skill d'équipe. Deux campagnes, dans cet ordre :
Campagne de déclenchement. Constituez votre grille : les cinq à dix formulations réelles du temps ② (qui doivent déclencher), plus trois à cinq demandes voisines hors périmètre (qui ne doivent pas). Soumettez-les une par une, dans des conversations neuves, et notez : chargée / pas chargée. Un faux négatif (demande légitime, skill ignorée) se corrige en enrichissant le vocabulaire de la description ; un faux positif (demande voisine, skill chargée à tort) se corrige en resserrant le « quand ».
Campagne de contenu. Une fois le déclenchement fiable — et seulement là — testez la qualité de la sortie contre le critère du temps ① : prenez de vraies notes de réunion (dont un cas tordu : notes incomplètes, aparté RH glissé au milieu) et vérifiez que le CR produit respecte structure, ton et cas limites.
Tester dans ce sens n'est pas un caprice de méthode : si vous testez le contenu d'abord, chaque itération sur les instructions peut aussi modifier le comportement de déclenchement que vous n'avez pas encore mesuré — vous courez deux lièvres. Déclenchement stabilisé, puis contenu : une variable à la fois.
Livrable du temps ④ : la grille de test remplie. Critère de sortie : 100 % des formulations légitimes déclenchent, 0 faux positif sur les voisines.
⑤ Itérer : un écart, une modification
En production, tenez un journal des écarts : chaque fois que la skill déçoit (pas chargée, mal appliquée, cas limite non prévu), une ligne — la demande, le comportement observé, le comportement attendu. Puis, périodiquement :
- L'écart vient d'un déclenchement raté → on ajuste la description (souvent : un mot du vocabulaire réel qui manque)
- L'écart vient d'une exécution ratée → on ajuste le corps (souvent : un cas limite à ajouter)
- Une modification à la fois, re-test de la grille du temps ④ après chaque changement — la grille devient votre test de non-régression
Et une hygiène : datez une ligne de changelog en fin de fichier. Trois mois plus tard, savoir pourquoi une règle existe évite de la supprimer par erreur.
Le livrable : la SKILL.md complète du fil rouge
Voici le fichier intégral, assemblé au fil des cinq temps. C'est votre gabarit de départ — remplacez le métier, gardez la structure :
---
name: compte-rendu-reunion
description: Rédige les comptes-rendus de réunion au format maison —
sections Décisions / Actions / Points ouverts, ton factuel, une page
maximum. À utiliser dès qu'on demande un compte-rendu, un CR, un
relevé de décisions ou une synthèse de réunion.
---
# Compte-rendu de réunion — format maison
## Structure obligatoire
1. **Contexte** — une ligne : date, participants, objet.
2. **Décisions** — ce qui a été tranché. Une décision par puce,
au passé composé, sans conditionnel.
3. **Actions** — qui / quoi / pour quand. Jamais d'action sans
porteur ni échéance ; si l'un des deux manque, l'inscrire
en Points ouverts avec la mention de ce qui manque.
4. **Points ouverts** — ce qui reste à trancher, avec la
prochaine étape prévue et son responsable si connu.
## Ton et style
- Factuel. Ni commentaire, ni interprétation des intentions.
- Phrases courtes, voix active.
- Une page maximum. Au-delà, résumer davantage — pas
d'annexes.
## Cas limites
- Notes brutes illisibles ou contradictoires : produire le CR
des points clairs, lister explicitement les zones d'ombre en
Points ouverts. Ne jamais inventer une décision.
- Informations RH ou individuelles sensibles : ne pas les
inclure ; signaler leur existence au demandeur, hors CR.
- Réunion sans aucune décision : le dire tel quel dans la
section Décisions (« Aucune décision actée ») plutôt que de
promouvoir des discussions en décisions.
- Doute sur un porteur d'action : marquer « porteur à
confirmer » — ne jamais attribuer par déduction.
## Vérification avant livraison
- Les quatre sections sont présentes, dans l'ordre.
- Chaque action a un porteur et une échéance (ou figure en
Points ouverts).
- Le document tient sur une page.
## Changelog
- v1.0 — création, format validé sur 3 réunions test.Et le compagnon templates/exemple-cr.md : prenez le meilleur CR réellement produit par votre équipe, anonymisez-le, rangez-le à côté. Modèle d'imitation fourni, moitié du chemin faite.
📚Pour aller plus loin
Pour les geeks : versionner ses skills dans Git. Une skill est du texte : elle mérite le même traitement que le code. Un dépôt skills/ (ou un dossier dans le monorepo), un sous-dossier par skill, et la discipline standard — branche, PR, revue par un pair qui exécute mentalement le test de la porte, merge. Deux conventions qui payent : des messages de commit qui citent l'écart corrigé (« fix: déclenche sur ''relevé de décisions'', écart du 12/08 »), et un tag par version majeure du format de sortie — le jour où le CR change de structure, les consommateurs avals (archivage, recherche) veulent savoir quand. Bonus revue : exiger dans la PR la grille de test remplie du temps ④, comme on exige les tests unitaires. Une skill sans grille, c'est du code sans test : ça marche jusqu'au jour où.
📚Pour aller plus loin
Pour les geeks : anatomie d'une grille de déclenchement. Formalisons le temps ④. Colonnes : formulation soumise · attendu (charge / ignore) · observé · verdict. Lignes : vos 5-10 formulations légitimes, vos 3-5 voisines hors périmètre, plus deux catégories qu'on oublie : les formulations dégradées (fautes de frappe, abréviations : « cr reu de se matin ») et les collisions si vous avez plusieurs skills proches (une demande d'ordre du jour ne doit charger ni la skill CR, ni être orpheline si une skill ordre-du-jour existe). Ce dernier point est le test d'intégration du monde des skills : à mesure que la bibliothèque grandit, les périmètres se touchent, et c'est la précision relative des descriptions qui départage. Re-jouez la grille complète à chaque modification de description — c'est votre CI mentale, en attendant de l'automatiser (on en reparle à l'étape 9 avec l'outillage de l'écosystème).
📍 Parcours Skills & MCP — étape 3/9
- 🗺️ La carte avant le territoire
- 🔬 Anatomie d'une skill
- 🛠️ Créer sa première skill ← vous êtes ici
- 🏛️ Skills en entreprise : gouvernance
- 🔌 MCP : le protocole expliqué
- ⚡ Utiliser un serveur MCP existant
- ⚙️ Créer son serveur MCP minimal
- 🛡️ Sécuriser ses MCP
- 📡 L'écosystème : où trouver, où ça bouge
Prochaine étape → Skills en entreprise : gouvernance — qui écrit, qui valide, qui maintient — et pourquoi une skill malveillante est une injection permanente de comportement. La gouvernance, angle sécurité compris.
Votre skill est écrite ? Le test de sécurité des agents IA vous dira si votre organisation est prête à l'héberger.