Comment on teste les skills Claude : le protocole SkillProof

Tout le site a démarré avec un skill qui ne faisait rien. Fin 2025, un skill de productivité circulait sur X avec quelques milliers d'étoiles derrière lui. Nous l'avons installé, redémarré Claude Code, tapé le cas d'usage exact du README, et regardé Claude répondre comme si le skill n'existait pas. Vérifié le répertoire : fichiers présents, frontmatter valide. Tapé une autre formulation. Rien. Le skill ne s'est jamais déclenché une seule fois en quarante minutes, et rien sur la page du dépôt ne l'aurait laissé prévoir. Les étoiles mesurent si un README est excitant. Elles ne disent rien sur si le dossier en dessous fonctionne.

Cette soirée-là a laissé une question qu'on n'a pas pu chasser : si un skill avec autant d'attention peut être mort-né, à quoi ressemble le reste de l'écosystème ? Alors on a commencé à installer des skills sur une machine vierge et à noter ce qui se passait. La réponse, documentée dans nos données d'échec, est qu'environ la moitié des skills communautaires échoue avant d'aider qui que ce soit. Cet article est l'autre face de ce constat : le protocole exact derrière chaque verdict sur SkillProof, avec assez de détail pour que vous puissiez l'exécuter sur votre propre skill avant de le livrer.

Le protocole, étape par étape

Un test complet prend entre 45 minutes et plusieurs jours, selon la catégorie. Un skill de documents fait ses preuves en une session ; un skill de revue hebdomadaire doit survivre à une vraie semaine. Dans les deux cas, les étapes sont les mêmes, et l'ordre compte, parce que chacune conditionne la suivante. Il n'y a aucun intérêt à noter le résultat d'un skill qui ne se déclenche jamais.

Étape 0 : un environnement neuf

Chaque test commence sur un profil de machine avec un répertoire de skills vide et les paramètres par défaut de Claude Code. Ça ressemble à de la cérémonie jusqu'à la première fois que ça vous sauve. Les skills interagissent : l'un peut sembler fonctionner parce qu'un autre skill sur la machine fait discrètement le gros du travail. Nous l'avons appris en testant un skill de proposition sur une machine qui avait déjà le skill docx installé. Le résultat avait l'air excellent. Sur un profil vierge, la moitié de la valeur a disparu, parce que le skill de document produisait le .docx soigné depuis le début.

Étape 1 : installer depuis les propres instructions de l'auteur

Nous ouvrons le README du dépôt et le suivons littéralement. Pas « on trouve comment l'installer ». On fait exactement ce que l'auteur a écrit, coquilles y compris, parce que c'est ce que fera chaque utilisateur réel. Si les commandes produisent réellement ~/.claude/skills/name/name/SKILL.md, un répertoire de trop, c'est une installation ratée, même si n'importe qui connaissant le format pourrait le corriger en dix secondes. Nous pourrions le corriger aussi. Le fait est que le nouvel arrivant qui suit le guide à 23h ne le peut pas, et il conclura que les skills Claude sont cassés plutôt qu'un seul chemin était faux.

Tout ce que le README ne mentionne pas compte contre lui : dépendances non déclarées, instructions écrites pour une version de Claude Code vieille de deux versions. Nous notons le temps entre le clone et un skill qui fonctionne, et si nous avons dû quitter le README pour y arriver.

Étape 2 : la batterie de déclenchement

Un skill installé qui ne s'active jamais est de la décoration. Donc avant toute vraie tâche, nous lançons une batterie de cinq prompts : trois formulations qui devraient le déclencher, deux qui ne devraient pas.

Les trois prompts positifs sont délibérément variés. Pour un skill de document Word : « transforme ces notes en un rapport que je peux envoyer en .docx », puis « rédige ce contrat comme un fichier Word », puis quelque chose d'oblique comme « j'ai besoin que ce soit formaté correctement pour une revue juridique ». Le premier est l'exemple propre du README. Le second utilise un vocabulaire différent pour la même intention. Le troisième ne nomme jamais le format de fichier, ce qui teste si la description couvre le travail plutôt que les mots-clés.

Les deux prompts négatifs sondent le sur-déclenchement, l'échec dont personne ne parle. Un skill de document qui se déclenche quand vous demandez « résume ce document » (texte collé, aucun fichier impliqué) injecte des instructions dans des conversations où elles n'ont rien à faire, et vous le payez en contexte et en résultats bizarres. Un skill qui se déclenche sur tout est pire qu'un skill qui ne se déclenche jamais ; au moins celui qui est mort est facile à diagnostiquer.

Cinq sur cinq est un résultat propre. En dessous, nous notons quelles formulations ont échoué ; le schéma est en général diagnostique. Un skill qui ne se déclenche que sur la formulation exacte du README a une description écrite comme un slogan plutôt que comme une spécification de déclenchement.

Étape 3 : l'essai de référence

C'est le cœur du test et la raison d'être du protocole. Nous prenons une vraie tâche du domaine du skill et l'exécutons deux fois : une fois avec le skill installé, une fois sur le modèle nu avec le prompt identique. Puis nous comparons.

La comparaison est la seule question qui compte : le résultat avec skill est-il clairement meilleur que ce que Claude produit de toute façon ? Claude est déjà bon dans beaucoup de domaines. Un skill « amélioration de l'écriture » qui rivalise avec un modèle qui écrit bien doit démontrer un écart, et la plupart n'y arrivent pas. Quand nous avons testé frontend-design, nous avons lancé le même brief de page d'atterrissage dans les deux versions. La version avec skill avait une vraie échelle typographique et une palette intentionnelle ; la référence avait le look néon-dégradé que tout le monde reconnaît. Cet écart a valu un 10. Quand les deux résultats sont difficiles à distinguer, le skill n'a aucune raison d'exister, quel que soit le charme de son README.

Les vraies données comptent autant que la comparaison. Un tableur avec des en-têtes malformés, un dossier de factures où un tiers des fichiers sont des scans. La performance sur données de démonstration, c'est du marketing ; nous testons la version mardi après-midi du travail, parce que c'est la version que vous allez lui confier.

Étape 4 : le contre-examen de la documentation

Enfin, nous lisons tout le SKILL.md et tout ce qu'il référence, puis comparons les affirmations à ce que nous avons observé. Le README promet-il des capacités que le skill n'a pas ? Divulgue-t-il ses dépendances ? Y a-t-il quelque chose d'enfoui au milieu du fichier qui ressemble moins à des conseils de tâche qu'à une injection de prompt, ou un appel réseau que la doc ne mentionne jamais ?

Cette étape signale peut-être un skill sur dix, mais ceux qu'elle attrape comptent le plus. Un skill, c'est du texte injecté dans le contexte de votre modèle. Lire chaque ligne avant de lui faire confiance est le minimum, et nous traitons cette lecture comme faisant partie du produit.

Les quatre scores, et pourquoi le résultat compte double

Chaque skill testé reçoit quatre chiffres, décrits sur notre page méthodologie. La version courte, avec ce qui sépare un 5 d'un 2 :

S'installe proprement (sur 5). Un 5 veut dire qu'un nouvel arrivant qui suit le README obtient un skill fonctionnel sur une configuration vierge sans détour. Un 2 veut dire qu'on a fini par le faire fonctionner grâce à des connaissances que le README ne contient pas : corriger des chemins, lire le code source. Le skill peut être excellent ; la porte pour y entrer est cassée.

Se déclenche de façon fiable (sur 5). Un 5 est cinq sur cinq à la batterie : les trois formulations positives se déclenchent, les deux négatives restent silencieuses. Un 2 ne se déclenche que sur des mots tirés de son propre README, ou se déclenche sur un travail sans rapport, ou les deux. Cause commune dans les deux sens : un champ description écrit pour impressionner des humains plutôt que pour informer le modèle.

Résultat vs référence (sur 10). Un 9 ou 10 veut dire que le résultat avec skill est indiscutablement meilleur sur une vraie tâche, le genre de différence qu'on remarquerait sans grille de notation. Un 4 veut dire qu'il a fallu plisser les yeux. Un 2 veut dire que l'essai de référence était aussi bon ou meilleur, ce qui arrive plus souvent que les auteurs aimeraient le croire.

Documentation et honnêteté (sur 5). Un 5 veut dire que le README correspond à la réalité : affirmations exactes, dépendances déclarées, rien de non divulgué. Un 2 veut dire des promesses que le skill ne peut pas tenir ou un comportement que la doc ne mentionne jamais.

Le résultat est noté sur 10 alors que tout le reste est sur 5, et cette pondération est délibérée : la qualité du résultat vaut autant que tous les autres critères combinés. Les problèmes d'installation ont des contournements. Les problèmes de déclenchement peuvent être corrigés en éditant un seul champ description. Mais un skill dont le résultat ne bat pas la référence est irréparable de toute façon qui compte. Les autres scores mesurent si vous pouvez atteindre la valeur. Le score de résultat mesure s'il y en a une.

Deux tests du journal : un 24 et un 17

Les chiffres parlent plus avec les tests attachés. En voici un de chaque bout du classement publié.

Systematic-debugging, de la collection Superpowers de Jesse Vincent, a obtenu 24 sur 25 : installation 5, déclenchement 5, résultat 9, doc 5. L'installation est deux commandes de plugin qui ont fonctionné exactement comme écrit, et la batterie de déclenchement est passée cinq sur cinq. L'essai de référence est la partie qu'on ramène encore en conversation : nous lui avons donné une condition de course que Claude nu avait déjà « corrigée » trois fois, chaque correction étant une supposition qui déplaçait le symptôme. Avec le skill chargé, Claude a arrêté de deviner. Il a formé une hypothèse, écrit un test pour la vérifier, regardé le test échouer, et suivi cette boucle jusqu'à trouver la vraie cause racine. La doc promet un processus de débogage discipliné et c'est précisément ce que nous avons observé. Il est un pilier de notre page code depuis.

Proposal-builder, un skill communautaire, a obtenu 17 : installation 3, déclenchement 4, résultat 7, doc 3. Le premier essai a été un échec au sens propre. Tel quel, sur un profil vierge, il ne pouvait pas livrer ce que son README promet : le résultat .docx soigné dépend silencieusement d'avoir le skill docx installé, et le formatage de marque dépend d'un modèle de proposition que le README mentionne à peine. Suivez les instructions littéralement, comme le ferait un nouvel utilisateur, et vous obtenez un mur de markdown là où une proposition devrait être. Une fois qu'on a installé le skill compagnon et configuré un modèle, il a assemblé une proposition de marque genuinement utile à partir de notes d'appel et de tarification. La capacité est réelle. Le chemin pour y arriver n'est pas dans le README, et les scores le disent exactement, jusqu'aux étapes manquantes détaillées dans les notes de test.

Cet écart est celui que le compte d'étoiles ne peut pas voir. Les deux dépôts semblent compétents de l'extérieur. L'un fonctionne dès qu'on suit ses propres instructions. L'autre ne fonctionne que si on sait déjà ce qu'il a oublié de dire.

Ce que signifie un verdict

Les scores se résument en l'un de trois verdicts. Le verdict du milieu déroute les gens, alors soyons précis.

Pass signifie que le skill s'est installé depuis les propres instructions de l'auteur, s'est déclenché correctement, et a battu la référence sans skill sur une vraie tâche. Sur les 73 skills du catalogue, 35 portent ce verdict.

Fonctionne avec configuration signifie que le skill livre une vraie valeur, mais pas directement. Il a besoin d'un skill compagnon ou d'une étape de configuration d'abord, et la fiche dit laquelle. Dix skills se trouvent ici, et le verdict n'est pas un euphémisme pour l'échec. Certains skills demandent une configuration par conception : un skill de charte de marque est censé être inutile jusqu'à ce que vous remplissiez votre palette et votre voix, et un skill de revue de pipeline ne peut pas revoir un pipeline qu'il ne voit pas. Le verdict existe pour que vous sachiez ce qu'une demi-heure honnête de configuration achète avant de la dépenser.

En file de test signifie que nous avons référencé le skill parce qu'il semble prometteur et n'avons pas fini de le tester. Aucun verdict n'est impliqué dans un sens ou l'autre ; 28 skills attendent. Les skills qui échouent le test carrément n'obtiennent pas non plus une suppression silencieuse : les notes de test disent ce que nous avons exécuté et ce qui a cassé, parce qu'un échec documenté vous est plus utile qu'un trou dans le catalogue.

Retester, parce que Claude ne cesse de changer

Un verdict est un instantané, et le sol en dessous bouge. Les skills reposent sur un modèle, et les modèles sont mis à jour. Une description qui se déclenchait de façon fiable dans une version de Claude Code peut commencer à mal se déclencher dans la suivante, parce que le déclenchement dépend de la façon dont le modèle lit les descriptions, et cette lecture change. La dérive n'est pas hypothétique ; nous avons vu un skill fiable commencer à ignorer une de ses trois formulations positives après une sortie, sans qu'un seul caractère du skill n'ait changé.

Donc chaque fiche porte une date de test et la version de Claude Code, et les sorties majeures remettent toute la liste des « pass » en file de retest, les skills les plus installés en premier. Quand un verdict change, la fiche change. Une date de test vieillissante est votre indice pour pondérer le verdict en conséquence ; c'est le coût honnête de tester contre une plateforme mouvante.

Ce que nous ne testons pas, et où la méthode est faible

Un protocole qu'on ne peut pas critiquer est un protocole que personne n'a décrit honnêtement. Les limites connues :

Les tâches d'échantillon ne peuvent pas couvrir tous les usages. Nous exécutons une ou deux vraies tâches par skill, choisies pour être représentatives, et un skill qui brille sur notre tableur de 40 000 lignes peut quand même trébucher sur votre tableur de 400 000 lignes. Le verdict est une preuve, jamais une garantie.

Le score de documentation s'appuie sur le jugement d'un seul testeur. Lire un SKILL.md pour l'honnêteté est plus proche de l'édition que de la mesure, et deux lecteurs attentifs peuvent peser la même phrase vague différemment. Nous publions les notes de test en partie pour que vous puissiez nous auditer.

Nous ne testons pas à l'échelle ou sur de longs horizons. Une machine vierge, des jours plutôt que des mois. La dégradation lente et les workflows impliquant plusieurs skills à la fois sont hors de portée de la méthode pour l'instant.

La revue de sécurité est une lecture, pas un audit. Nous vérifions les appels réseau non divulgués et les instructions en forme d'injection, mais un acteur malveillant déterminé pourrait faire passer quelque chose au travers d'une lecture manuelle. Traitez notre score de doc comme un filtre, et restez vigilant pour tout ce qui touche aux identifiants.

Et la référence elle-même bouge. « Bat Claude nu » veut dire Claude nu à la date du test ; à mesure que le modèle de base s'améliore, certains skills qui réussissent verront leur écart se réduire vers zéro. Une raison de plus pour laquelle retester n'est pas optionnel.

Exécuter le protocole sur votre propre skill

Si vous êtes sur le point de publier un skill, une version condensée de tout ça prend environ une heure et vous place devant la moitié de l'écosystème.

1. Profil vierge. Répertoire de skills vide, paramètres par défaut. Votre machine quotidienne cache vos bugs.
2. Installez depuis votre README seulement. Mieux : donnez le README à quelqu'un qui n'a jamais vu le dépôt et regardez. Chaque question qu'il pose est une phrase manquante.
3. Lancez la batterie de cinq prompts. Trois formulations qui devraient se déclencher, dont une qui n'utilise jamais vos mots-clés, plus deux prompts adjacents qui ne devraient pas. Corrigez les ratés en réécrivant le champ description, pas en ajoutant des mises en garde au README.
4. Faites la comparaison de référence. Même tâche, avec et sans votre skill. Si vous ne pouvez pas distinguer les résultats, repensez à quoi sert le skill avant de publier.
5. Relisez votre SKILL.md en sceptique. Chaque affirmation que vous ne pouvez pas démontrer, coupez-la. Chaque dépendance, déclarez-la.
6. Passez le format au linter. Les erreurs de frontmatter sont la classe d'échec la plus évitable qu'on voie, et un validateur les attrape en quelques secondes.

FAQ

Combien de temps faut-il pour tester un skill Claude ?

L'auto-test condensé prend environ une heure. Notre protocole complet tourne 45 minutes pour un skill de document simple et jusqu'à une semaine pour des skills dont la valeur ne se révèle que dans la durée, comme les skills de revue hebdomadaire. La batterie de déclenchement prend des minutes ; la comparaison de référence est là où passent les heures.

Puis-je tester un skill sans une seconde machine ?

Oui. Vous avez besoin d'un profil vierge, pas d'un matériel vierge. Pointez Claude Code vers un répertoire de skills vide (ou mettez le vôtre de côté) et vous obtenez l'isolation qui compte : aucun autre skill en concurrence pour les déclenchements, aucun qui couvre discrètement pour celui en test.

Quelle est la raison la plus courante pour laquelle les skills échouent au test ?

Un résultat qui ne bat pas la référence, environ 35% des échecs, suivi de près par des installations cassées à 30%. Les échecs d'installation piquent le plus parce qu'ils sont les moins chers à prévenir : l'auteur n'a jamais suivi son propre README sur une machine qui n'était pas la sienne.

Comment faire tester et référencer mon skill sur SkillProof ?

Soumettez-le ici avec le lien du dépôt. Il entre dans la file de découverte, est trié par traction et pertinence de catégorie, puis passe par le protocole de cette page. Faites l'auto-test d'abord et vos chances d'un verdict pass augmentent, parce que vous attraperez les mêmes défauts que nous attraperions.

Le protocole n'a rien de malin. C'est une machine vierge, un README pris au mot, cinq prompts, une comparaison honnête. Ce qui le fait fonctionner, c'est que personne d'autre dans le pipeline ne fait même ça : les auteurs testent sur leur propre machine, et les étoiles mesurent l'excitation. L'écart entre les deux est là où vivait ce skill de productivité mort-né fin 2025. On continue de le combler, une installation à la fois.