Skill Hermes ou prompt réutilisable : le test pratique avant de standardiser
Tu as un prompt qui marche. Tu l’as testé trois fois, il donne le bon résultat. Tu te dis : je vais en faire un skill Hermes, comme ça je le retrouve en une commande.
C’est une bonne intention. Mais c’est souvent la mauvaise décision au bon moment.
Standardiser un prompt en skill, c’est figer une procédure. Si la procédure n’est pas encore stable, tu crées un skill que tu vas modifier trois fois par semaine. Et un skill qu’on modifie sans arrêt, ce n’est plus un standard. C’est un brouillon avec un joli fichier YAML.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Le vrai coût d’un prompt qu’on copie-colle
Le problème n’est pas le prompt. Le problème, c’est ce qui se passe autour.
Tu copies un prompt depuis tes notes. Tu changes deux variables à la main. Tu oublies la troisième. Le résultat est bancal, tu recommences. La semaine suivante, tu améliores le prompt mais tu oublies de mettre à jour ta note. Trois mois plus tard, tu as quatre versions du même prompt dans quatre dossiers différents.
Ce n’est pas un problème de prompt. C’est un problème de maintenance.
Un prompt réutilisable qui vit dans un fichier texte, c’est mieux que rien. Mais ça ne règle pas la question de fond : est-ce que cette procédure mérite d’être standardisée, ou est-ce qu’elle est encore en train de bouger ?
Ce qu’est un skill Hermes, et ce qu’il n’est pas
Un skill Hermes, c’est un document de connaissance que l’agent charge à la demande. La doc officielle le définit comme un document chargeable via un système de « progressive disclosure » : l’agent voit d’abord le titre et la description, puis charge le contenu complet seulement s’il en a besoin.
Concrètement, un skill contient :
- un fichier
SKILL.mdavec des instructions structurées ; - éventuellement des scripts, des templates, des fichiers de référence ;
- un frontmatter YAML qui déclare les outils requis, la plateforme, la catégorie.
Quand tu invoques /mon-skill, l’agent lit ces instructions et les applique à la tâche en cours.
Ce qu’un skill ne fait pas : garantir une exécution correcte. Le skill donne un cadre. L’agent l’interprète. Si la procédure est floue ou si le contexte varie trop, le skill ne compense pas.
Le critère de décision : prompt réutilisable ou skill ?
La question n’est pas « est-ce que ce prompt est utile ? ». La question est « est-ce que la procédure est stable et répétable ? ».
Voici les critères qui séparent les deux formats.
| Critère | Prompt réutilisable | Skill Hermes |
|---|---|---|
| Fréquence d’utilisation | Occasionnelle, quelques fois par mois | Régulière, plusieurs fois par semaine |
| Stabilité de la procédure | Encore en évolution, tu ajustes souvent | Stable depuis au moins 5 utilisations |
| Complexité | Un prompt simple, quelques lignes | Procédure en plusieurs étapes, avec variantes |
| Besoins en ressources | Aucun fichier externe nécessaire | Scripts, templates, ou fichiers de référence requis |
| Partage | Usage personnel uniquement | Partagé avec d’autres profils ou une équipe |
| Maintenance | Tu modifies le fichier texte, c’est réglé | Tu maintiens un SKILL.md, des scripts, des refs |
Si tu coches au moins quatre critères dans la colonne de droite, standardise. Sinon, garde ton prompt dans un fichier et continue d’itérer.
Le test pratique en trois étapes
Avant de créer un skill, fais ce test. Il prend dix minutes et il t’évite de maintenir un skill que tu n’utiliseras pas.
Étape 1 : documente la procédure sans skill. Écris les étapes dans un fichier texte. Pas de YAML, pas de frontmatter. Juste les instructions, dans l’ordre. Utilise ce fichier pendant une semaine.
Étape 2 : compte les utilisations réelles. Si tu utilises la procédure moins de trois fois dans la semaine, ce n’est pas un skill. C’est un prompt que tu ranges dans tes notes. Si tu l’utilises cinq fois ou plus, passe à l’étape 3.
Étape 3 : vérifie que la procédure n’a pas bougé. Relis ton fichier de l’étape 1. Est-ce que tu as modifié quelque chose pendant la semaine ? Si oui, la procédure n’est pas encore stable. Continue avec le fichier texte et refais le test dans deux semaines.
Si les trois étapes sont vertes, tu as un candidat skill. Tu peux le créer avec /learn ou en rédigeant un SKILL.md à la main.
Ce qu’un skill apporte en plus du prompt
Une fois que la procédure est stable, le format skill apporte trois choses qu’un prompt dans un fichier texte ne donne pas.
Le chargement progressif. L’agent ne charge le contenu complet que s’il en a besoin. Un skill de 300 lignes ne pèse pas dans le contexte tant que tu ne l’invoques pas. Un prompt copié-collé, lui, consomme des tokens à chaque fois.
Les ressources attachées. Un skill peut embarquer des scripts, des templates, des fichiers de référence. Si ta procédure a besoin d’un template de réponse ou d’un script de validation, le skill les transporte avec lui. Un prompt texte ne le fait pas.
La découverte automatique. L’agent voit la liste des skills disponibles et peut proposer le bon skill en fonction de la tâche. Un prompt dans un fichier, l’agent ne le connaît pas tant que tu ne le lui donnes pas.
C’est pour ça que le skill n’est pas un « prompt amélioré ». C’est un format différent, pour un besoin différent. Si tu n’as pas besoin des ressources attachées ni de la découverte automatique, un prompt dans un fichier fait le travail.
Comment créer un skill une fois le test passé
Si ton test est vert, tu as deux chemins.
Le chemin rapide : /learn. Tu décris ta procédure à l’agent, il génère le SKILL.md pour toi. C’est la méthode la plus directe, surtout si tu as déjà documenté les étapes dans un fichier.
Le chemin manuel : rédiger le SKILL.md. Tu crées un fichier avec le frontmatter YAML et les instructions. C’est plus de contrôle, mais aussi plus de travail. La doc Hermes détaille le format attendu.
Dans les deux cas, une fois le skill créé, tu peux le personnaliser : ajouter des scripts, des templates, des variantes par contexte. C’est ce que couvre l’article sur la création d’un skill Hermes personnalisé.
La suite
Un skill n’est pas un trophée. C’est un outil de maintenance pour une procédure qui a fait ses preuves.
Le test des trois étapes te donne un critère objectif : tu standardises quand la procédure est stable et répétée, pas quand tu es content du résultat. C’est la différence entre un skill que tu utilises depuis six mois et un skill que tu as créé un mardi soir et jamais rappelé.
Si tu veux apprendre à structurer tes skills, les maintenir dans la durée, et construire une vraie bibliothèque de procédures réutilisables, la formation Hermes Agent couvre tout le cycle : création, test, maintenance et partage. Tu peux faire une demande d’accès directement sur la page.
