Compétences de vérification

Pourquoi une Compétence de vérification est celle à construire en premier

Pensez à la façon dont vous vérifiez habituellement le travail de Claude. Vous lui demandez de refactoriser quelque chose, il termine, puis vous devez vous rappeler de vérifier à nouveau. Peut-être lui demandez-vous d'exécuter les tests. Peut-être lisez-vous vous-même le diff. Le problème, c'est que cette vérification dépend du fait que vous vous en souveniez. Sautez cette étape une seule fois, et du mauvais code passe entre les mailles du filet.

Une Compétence de vérification élimine cette dépendance. Voici à quoi cela ressemble. Vous demandez à Claude de refactoriser quelque chose. Une fois terminé, le changement correspond à la description de la Compétence, qui se déclenche donc d'elle-même. À partir de là, elle :

• Exécute la suite de tests.
• Lit le diff.
• Vérifie qu'aucun test n'a été affaibli juste pour faire passer les choses.
• Rapporte un succès ou un échec, avec les preuves à l'appui.

Tout le flux se déroule sans que vous ayez à le demander. La description de la Compétence est ce qui la déclenche, et une fois déclenchée, elle suit les mêmes étapes à chaque fois.

Remarquez la dernière vérification de cette chaîne. Il ne suffit pas d'exécuter les tests et de voir du vert. Un test peut être discrètement assoupli pour qu'il passe quoi qu'il arrive. La Compétence lit donc le diff et confirme que les tests n'ont pas été affaiblis. « Terminé » n'est pas « le code semble correct » d'après la seule lecture du diff. Terminé signifie que les contrôles ont été exécutés et observés, avec les résultats énoncés explicitement.

Cette même logique s'applique à toute procédure que votre équipe répète. Une liste de contrôle de mise en production. Une recette de migration. Une vérification pré-PR. La règle empirique : si vous avez tapé deux fois la même instruction à plusieurs étapes, c'est une Compétence.

Un dossier de Compétence peut contenir plus que des instructions

Une Compétence n'est pas qu'un simple fichier SKILL.md. Le dossier qui l'entoure peut contenir d'autres éléments, et c'est ce qui rend les Compétences utiles pour la vérification.

• Déposez un reference.md à côté de SKILL.md pour le contenu détaillé, puis faites-y un lien depuis SKILL.md. Claude ne le lit que lorsqu'il a besoin de cette profondeur. Votre fichier principal reste court.
• Placez aussi des scripts dans le dossier. Claude les exécute plutôt que de charger leur contenu dans le contexte. Cela signifie qu'une Compétence peut embarquer son propre outillage, comme un check.sh qui exécute tous les contrôles.

À retenir : gardez SKILL.md lui-même léger. Déplacez le contenu lourd (les longues explications et les scripts exécutables) dans des fichiers annexes. Le fichier léger décrit quoi faire. Les fichiers annexes contiennent la profondeur et les outils.

Quelle surface d'instruction porte quelle règle

À ce stade, vous disposez de trois endroits où placer des instructions, et il est facile de les confondre. Voici un moyen rapide de les distinguer.

Les conventions qui s'appliquent en permanence, comme les règles de nommage ou l'emplacement des fichiers, appartiennent à votre fichier CLAUDE.md. Les procédures et le contenu de référence liés à un type de tâche particulier appartiennent à une Compétence.

Il existe un troisième cas. Une règle que Claude ne doit absolument pas pouvoir contourner appartient à un hook, et non à l'un des deux précédents. En effet, CLAUDE.md et les Compétences sont tous deux des instructions que Claude suit, tandis qu'un hook est du code qui s'exécute réellement. Si le non-respect de la règle n'est pas acceptable, ne laissez pas cela dépendre du simple suivi d'instructions.

Récapitulatif

Une Compétence est un dossier contenant un SKILL.md : un nom, une description qui la déclenche, et la procédure elle-même. Seules les descriptions sont chargées dans le contexte jusqu'à ce qu'une Compétence soit nécessaire, donc il y a peu de coût à packager chaque procédure que vous répétez.

Commencez par la vérification. Construisez la Compétence, intégrez-la dans le .claude/skills de votre projet, et désormais toute l'équipe hérite de la même démarche. Le travail de chacun est vérifié de la même manière, automatiquement, sans que personne n'ait à se souvenir de le demander.