Tester un skill

Trois sources proposent aujourd'hui une méthode pour qualifier un skill avant de le mettre en service : le guide officiel d'Anthropic, le skill skill-creator publié par Anthropic, et le skill writing-skills du dépôt communautaire superpowers. Ce chapitre les présente, puis les examine avec les outils statistiques des parties précédentes.

Les trois méthodes

Le guide d'Anthropic : l'évaluation d'abord

Le guide Skill authoring best practices (source) pose une règle : construire les évaluations avant d'écrire la documentation. La démarche proposée tient en cinq étapes :

1. lancer l'agent sans skill sur des tâches représentatives et noter ses lacunes ;
2. créer trois scénarios qui testent ces lacunes ;
3. mesurer la ligne de base ;
4. écrire des instructions minimales ;
5. itérer en comparant à la ligne de base.

Le guide recommande aussi de tester avec tous les modèles auxquels le skill est destiné : ce qui suffit à un grand modèle peut manquer de détails pour un petit. Il propose de travailler avec deux instances : une qui conçoit le skill, une autre, fraîche, qui l'utilise sur des tâches réelles. Et il précise honnêtement qu'il n'existe « pas actuellement de moyen intégré d'exécuter ces évaluations ».

skill-creator : un banc d'essai avec ligne de base

Le skill skill-creator d'Anthropic (dépôt) outille cette démarche. Pour la qualité d'exécution :

• chaque cas de test est lancé deux fois en parallèle : avec le skill, et sans (ou avec l'ancienne version, pour une amélioration) ;
• des assertions vérifiables sont notées par un agent correcteur, qui doit citer une preuve ; le correcteur est aussi chargé de critiquer les assertions elles-mêmes : « une note de réussite sur une assertion faible est pire qu'inutile — elle crée une fausse confiance » ;
• un script agrège taux de réussite, temps et tokens, avec moyenne ± écart-type et écart à la ligne de base ;
• un agent analyste repère les assertions non discriminantes (qui passent avec ou sans skill) et les évaluations à forte variance (« peut-être instables ») ;
• un humain relit les sorties dans une visionneuse dédiée.

Pour le déclenchement, skill-creator optimise la description sur une vingtaine de requêtes, moitié qui doivent déclencher, moitié qui ne doivent pas — de préférence des quasi-positifs (des requêtes proches mais hors sujet, pas des requêtes évidemment hors sujet). Chaque requête est lancée 3 fois, les requêtes sont réparties en 60 % d'entraînement et 40 % de test, et la meilleure description est choisie sur le score de test, pour éviter le surapprentissage. Le standard agentskills.io reprend la même méthode (source), avec un seuil de taux de déclenchement à 0,5.

superpowers : le TDD appliqué aux skills

Le skill writing-skills du dépôt superpowers de Jesse Vincent (source) transpose le développement piloté par les tests :

Étape du TDD	Pour un skill
Écrire un test	Écrire un scénario de pression joué par un sous-agent
Le voir échouer (RED)	Observer l'agent sans le skill violer la règle, et noter mot pour mot ses justifications
Le faire passer (GREEN)	Écrire le skill ; l'agent respecte la règle
Refactoriser	Boucher les échappatoires sans casser le respect

Les scénarios combinent plusieurs pressions (urgence, coût déjà engagé, autorité, fatigue) pour reproduire les situations où un agent abandonne une discipline. Les règles de méthode sont très proches du SPC :

• « toujours inclure un témoin sans consigne : si le témoin ne présente pas la défaillance, il n'y a rien à corriger » ;
• « 5 répétitions ou plus par variante. Un échantillon unique ment » ;
• « la variance est une mesure » ;
• et l'observation déjà citée : ajouter une seule clause de nuance à une recette gagnante l'a fait passer « de stable à bruitée ».

Ce que la statistique dit de ces méthodes

Les trois méthodes ont la bonne architecture : ligne de base, témoin, répétitions, séparation entraînement/test. Le script de vérification permet de chiffrer ce que valent leurs paramètres par défaut.

Trois runs par requête pour le déclenchement

Avec 3 runs et un seuil de 0,5, une requête est classée « déclenche » si elle déclenche au moins 2 fois sur 3. Probabilité qu'une requête soit classée du mauvais côté (§8) :

Runs par requête	Requête déclenchant réellement 70 % du temps	Requête à 90 %
1	30 %	10 %
3	22 %	2,8 %
5	16 %	0,9 %
15	5 %	~0 %

Sur 20 requêtes dont le taux réel est de 70 %, 4,3 en moyenne sont mal classées avec 3 runs. Le score d'une description candidate sur 8 requêtes de test bouge donc de plusieurs requêtes d'un essai à l'autre sans que la description ait changé. Choisir « la meilleure » parmi cinq candidates sur ce score revient en partie à choisir la plus chanceuse.

La moyenne ± écart-type sur trois runs

Un écart-type estimé sur 3 runs est extrêmement imprécis. Avec 3 mesures, l'intervalle de confiance à 95 % du vrai écart-type va de 0,52 à 6,28 fois l'écart-type observé (§9) — un facteur 12 entre les bornes. La mention « 50 % ± 40 % » qu'on peut lire dans un rapport d'analyse ne dit presque rien de la variabilité réelle de l'évaluation.

Le calcul de puissance

Distinguer un skill qui fait passer un comportement de 70 % à 80 % de conformité demande 294 essais par version (§4). Les méthodes ci-dessus utilisent de 3 à 20 essais. Elles ne peuvent donc détecter que des effets massifs — de l'ordre de 33 % contre 83 %, l'exemple illustratif de la documentation agentskills.io.

Ce n'est pas une critique de fond

Pour la conception d'un skill, détecter des effets massifs est exactement ce qu'on veut : un skill qui n'a pas d'effet visible sur 5 runs ne vaut probablement pas son coût en tokens. La méthode superpowers le dit à sa façon : si le témoin ne présente pas la défaillance, il n'y a rien à corriger. Le problème apparaît seulement quand on utilise ces petites batteries pour comparer deux versions proches d'un skill, ou pour conclure à l'absence de régression.

Limite importante : l'absence de preuve

Une batterie de 3 à 20 essais qui ne montre pas de régression ne prouve pas l'absence de régression. Elle prouve l'absence de régression massive. Une dégradation de 10 points passera presque toujours inaperçue au stade du test, et ne pourra être vue qu'en production (chapitre suivant).

Le désaccord sur la description

Les trois sources ne s'accordent pas sur ce que doit contenir la description :

Source	Recommandation
Anthropic et agentskills.io	Ce que fait le skill et quand l'utiliser, à la troisième personne
skill-creator	Une description un peu « insistante », parce que Claude a tendance à sous-déclencher les skills
superpowers	Seulement quand l'utiliser ; jamais un résumé de la méthode, sinon l'agent suit le résumé au lieu de lire le skill

L'argument de superpowers est intéressant : sur un cas observé, une description qui résumait le déroulé a conduit l'agent à ne faire qu'une revue au lieu de deux, jusqu'à ce que la description soit réduite au seul « à utiliser quand… ».

Aucune des trois sources ne publie de mesure comparative. C'est précisément le type de question auquel la méthode de cette partie permet de répondre pour une bibliothèque donnée : deux variantes, une ligne de base, assez d'essais pour la taille d'effet cherchée.

À retenir

Les méthodes publiées (évaluation d'abord, ligne de base, témoin, répétitions, entraînement/test) sont méthodologiquement saines. Leurs paramètres par défaut (3 runs, 3 à 20 cas) détectent des effets massifs, pas des régressions modérées. Le bon usage : les petites batteries pour concevoir et qualifier un skill ; la surveillance en production pour détecter sa dégradation.