Choisir la bonne procédure pour un premier skill
Le premier skill doit être une procédure que vous connaissez parfaitement : vous l'avez exécutée manuellement de nombreuses fois, vous en connaissez les étapes, les cas limites et les critères de succès. Ce n'est pas le moment de formaliser une procédure complexe ou récemment modifiée. L'objectif du premier skill est d'apprendre le processus de formalisation, pas de résoudre un problème difficile.
Un bon premier candidat est une procédure de cinq à dix étapes, avec des entrées et des sorties clairement définies, qui utilise un ou deux outils au maximum. Par exemple : lire un fichier de configuration, vérifier la présence de certaines clés, générer un rapport de vérification. Cette procédure est suffisamment simple pour être validée facilement mais suffisamment réelle pour être utile.
- Choisir une procédure connue et exécutée de nombreuses fois
- Cinq à dix étapes, un ou deux outils maximum pour un premier skill
- L'objectif est d'apprendre la formalisation, pas de résoudre un problème complexe
Décomposer la procédure avant de la coder
Avant de toucher à la configuration d'Hermes Agent, écrivez la procédure sur papier ou dans un document texte. Listez chaque étape dans l'ordre, précisez ce qui est nécessaire en entrée pour chaque étape, ce qui est produit en sortie, et comment vous savez que l'étape a réussi. Cette décomposition préalable est l'étape la plus importante et la plus souvent sautée.
Lors de cette décomposition, vous allez probablement découvrir des ambiguïtés que vous n'aviez pas remarquées en exécutant la procédure manuellement : des étapes dont le critère de succès n'est pas clair, des cas limites que vous gérez intuitivement sans règle explicite, des dépendances entre étapes que vous n'aviez pas formalisées. Ces découvertes sont précieuses : elles vous indiquent ce qui doit être clarifié avant de créer le skill.
- Écrire la procédure sur papier avant de configurer
- Préciser entrée, sortie et critère de succès pour chaque étape
- Les ambiguïtés découvertes lors de la décomposition doivent être résolues avant
Identifier et configurer les outils nécessaires
Une fois la procédure décomposée, identifiez les outils dont le skill aura besoin. Pour chaque outil, vérifiez qu'il est disponible avec `hermes mcp list`. S'il n'est pas encore configuré, ajoutez-le avec `hermes mcp add` et configurez-le avec `hermes mcp configure`. Testez chaque outil individuellement avec `hermes mcp test` avant de l'intégrer dans le skill.
Pour un premier skill, limitez-vous aux outils en lecture seule si possible. Un skill qui ne fait que lire et analyser des données est beaucoup plus sûr à tester qu'un skill qui modifie des fichiers ou appelle des APIs avec des effets de bord. Vous pourrez ajouter des outils d'écriture dans des skills ultérieurs, une fois que vous maîtrisez le processus de validation.
- `hermes mcp list` vérifie les outils disponibles
- `hermes mcp add` et `hermes mcp configure` pour les nouveaux outils
- `hermes mcp test` valide chaque outil avant intégration
- Préférer les outils en lecture seule pour un premier skill
Formaliser le skill dans Hermes Agent
La formalisation du skill consiste à traduire la procédure décomposée en configuration Hermes Agent : définir l'objectif du skill, les préconditions, les étapes avec leurs outils associés, les points de validation intermédiaires et les conditions d'arrêt. Cette traduction doit être aussi fidèle que possible à la procédure que vous avez documentée.
Lors de la formalisation, vous allez probablement devoir faire des choix sur la façon dont certaines étapes sont représentées. Documentez ces choix : pourquoi vous avez structuré telle étape d'une certaine façon, quels cas limites vous avez décidé de ne pas couvrir dans cette version. Cette documentation sera précieuse lors de la maintenance future du skill.
- Traduire fidèlement la procédure documentée en configuration
- Définir explicitement les préconditions et les conditions d'arrêt
- Documenter les choix de formalisation pour la maintenance future
Tester le skill sur des données réelles mais à faible risque
Le premier test d'un skill doit se faire sur des données réelles mais dans un environnement à faible risque : des fichiers de test, des données non critiques, un environnement de développement isolé. Tester sur des données de production dès le premier essai est une erreur fréquente qui peut avoir des conséquences difficiles à corriger.
Lors du test, observez chaque étape du skill : est-ce que l'agent fait ce que vous attendiez ? Est-ce que les outils sont appelés dans le bon ordre avec les bons paramètres ? Est-ce que les validations intermédiaires fonctionnent ? Si quelque chose ne correspond pas à vos attentes, c'est le moment de corriger la configuration, pas après plusieurs exécutions.
- Tester d'abord sur des données non critiques
- Observer chaque étape, pas seulement le résultat final
- Corriger les écarts dès le premier test, ne pas les accumuler
Itérer et affiner après les premiers tests
Les premiers tests révèlent presque toujours des ajustements nécessaires : une étape dont la description est trop vague, un outil qui retourne des données dans un format différent de ce qui était attendu, une condition de succès mal définie. Ces ajustements font partie du processus normal de création d'un skill et ne signifient pas que la procédure initiale était mauvaise.
Après chaque modification du skill, relancez `hermes doctor` pour vérifier que la configuration reste cohérente, puis retestez le skill complet. Ne modifiez qu'un élément à la fois entre deux tests : cela permet d'identifier précisément l'effet de chaque modification et d'éviter d'introduire de nouveaux problèmes en corrigeant les anciens.
- Les ajustements après les premiers tests sont normaux
- Relancer `hermes doctor` après chaque modification
- Modifier un élément à la fois entre deux tests
Documenter le skill terminé
Une fois le skill validé, documentez-le : son objectif en une phrase, ses préconditions, les outils qu'il utilise, les cas limites qu'il gère et ceux qu'il ne gère pas, et la procédure à suivre si le skill échoue. Cette documentation n'est pas du luxe : dans six mois, vous aurez oublié pourquoi vous avez fait certains choix, et cette documentation sera votre seule référence.
Versionnez le skill et sa documentation comme vous versionneriez du code : avec un historique des modifications et les raisons de chaque changement. Cette discipline de versionnement est particulièrement importante si le skill est utilisé par plusieurs personnes ou s'il est critique pour un processus métier.
- Documenter objectif, préconditions, outils et cas limites
- Préciser ce que le skill ne gère pas
- Versionner le skill et sa documentation
Sources et méthode
Cette page est une synthèse éditoriale indépendante. Les capacités et commandes doivent être vérifiées dans les sources officielles avant une utilisation en production.