Méthode

Comment chaque skill est testé : trois bras, 18 exécutions notées sur Codex, une revue de sécurité et un verdict rédigé.

Ce qui est référencé

Un skill n'est référencé qu'après avoir été exécuté. Un dépôt de fichiers SKILL.md n'est pas un avis. Les pages d'exemple de ce dépôt sont des brouillons et restent non publiées. Les skills jugés dangereux à exécuter ne sont pas exécutés.

Le protocole

Chaque skill est exécuté sur trois petites tâches, en trois bras : sans skill (contrôle), sans skill mais avec la règle centrale du skill écrite en une phrase dans le prompt (prompt d'une phrase), et avec le skill installé (traitement). Les prompts ne nomment jamais le skill. Chaque tâche et chaque bras sont exécutés deux fois, soit 18 exécutions notées pour un avis complet. Les exécutions utilisent un projet temporaire neuf, un HOME et des caches temporaires, et aucun réseau.

La notation est basée sur des règles : tests unitaires cachés, rappel d'éléments plantés, vérifications de contraintes, ou contrôles de rendu et d'OCR, de 0 à 5 par exécution. Aucun modèle de langage ne décide d'un score. Les écarts inférieurs à environ 1 point sont du bruit à n=2.

Le score de chaque page est un total sur 30 : les six dimensions vont chacune de 0 à 5 et sont additionnées. Ces dimensions sont la qualité de sortie, le gain par rapport à sans skill, la fiabilité du déclenchement, l'installation et la portabilité, le coût en tokens et en temps (5 signifie bon marché et rapide), et l'hygiène de sécurité. À côté du total, la page affiche le gain : le score moyen des tâches avec le skill moins la moyenne sans, sur l'échelle de 0 à 5.

Le verdict est prononcé par le pipeline de test et utilise les chiffres affichés sur la page. Recommandé exige les trois conditions : un total d'au moins 22 sur 30, une qualité de sortie d'au moins 3.5 et un gain d'au moins +1.0. Non recommandé s'applique lorsque le total est inférieur à 14 sur 30, que la qualité de sortie est inférieure à 2.5, ou que le skill obtient un point de moins que sans skill. Tout le reste est Selon les cas. Un skill peut donc afficher 24 sur 30 et rester Selon les cas, parce que son gain est inférieur à +1.0 ; chaque page indique le critère manqué. Le bras « prompt d'une phrase » montre si le skill fait mieux que coller sa règle en une ligne ; il n'entre pas dans le score.

Chaque page liste ce qui a été modifié après coup, par exemple des contrôles assouplis puis re-notés, des exécutions non terminées, et des skills testés à un commit plus ancien.

Les paliers

Chaque skill est testé sur Codex. Une réussite y couvre aussi Claude Code. Nous ne recopions pas ce résultat vers d'autres agents.

| Palier | Testé avec | Une réussite couvre aussi | | ----------- | ---------- | ------------------------- | | Agents SOTA | Codex | Claude Code |

Un second palier sur un modèle moins coûteux (DeepSeek Flash) est en cours de nouveaux tests et sera ajouté une fois terminé. D'ici là, il apparaît comme non testé.

La page d'avis montre les sorties côte à côte : fichiers, captures d'écran, extraits avant/après, et vidéo avec un lecteur. La génération vidéo est une catégorie de premier niveau.

Revue de sécurité

Chaque skill reçoit aussi une revue de sécurité à partir de l'audit statique et de ce que l'exécution en bac à sable a réellement fait.

Audit statique : ce que le fichier du skill demande à l'agent de faire.
Permissions à risque : les noms signalés par l'audit, comme l'accès réseau ou des lectures hors de l'espace de travail.
Accès réseau et fichiers : ce que nous avons observé pendant l'exécution du skill.
Badge : Sûr, Prudence ou Dangereux. Le même badge figure sur la carte de la liste.

Ce qui est public

Le verdict, les scores, l'avis rédigé et les sorties intégrées à la page sont publics. Les transcriptions, les fichiers d'exécution téléchargeables et le score brut de chaque exécution sont réservés à Pro.

Ajouter un avis

Les vrais avis proviennent du pipeline de test. Voir le README pour l'arborescence. Un avis reste draft tant que les exécutions ne sont pas réelles.