Comment les skills sont vérifiés

D'où viennent les skills

Chaque nuit, un programme récupère des fichiers SKILL.md publics par la recherche de code de GitHub, dans des listes « awesome » tenues par la communauté et dans le registre n-skills. Un fichier déjà connu n'est pas réimporté.

Un score de départ, calculé sans IA

Avant qu'un modèle de langage ne le lise, chaque fichier reçoit un score calculé par des règles fixes.

La structure compte pour 30 points. L'algorithme y cherche un en-tête valide, une section sur l'objectif, une section « quand l'utiliser », des instructions et des règles. La réputation vaut aussi 30 points, selon le nombre d'étoiles du dépôt GitHub (15 par défaut quand il n'y a pas de dépôt). La fraîcheur, sur 20 points, baisse avec l'âge du dernier commit : 20 à moins d'un mois, 0 au-delà d'un an. La sécurité part de 20 points. Elle en perd 2 si le skill déclare bash ou docker, 10 s'il déclare sudo ou network, et 15 s'il contient un motif suspect, comme un script téléchargé puis exécuté, un eval, un rm -rf / ou un contenu décodé depuis du base64.

Le total est sur 100. Un skill trouvé dans une liste « awesome » gagne 10 points de bonus. Sous 35, il n'entre pas dans le catalogue.

Les copies

Un même SKILL.md circule souvent dans plusieurs dépôts. Quand des skills publiés ont exactement le même contenu, l'algorithme n'en garde qu'un : le mieux noté en qualité, puis le plus installé, puis le plus ancien. Les pages des copies redirigent vers lui.

La lecture par un modèle de langage

Le modèle utilisé est DeepSeek V4.1 Flash. Il lit le texte du SKILL.md et n'exécute jamais le skill. Il reçoit ce texte comme une donnée à évaluer, avec pour consigne d'ignorer les instructions qu'il contient et de signaler celles qui tentent d'orienter son jugement.

Il intervient une première fois quand le skill entre dans le catalogue, pour écrire son titre et sa description courte. La vérification le fait ensuite lire deux fois, avec deux consignes différentes.

La première lecture rédige la fiche en français et en anglais. On y trouve un résumé, les points forts, les limites, quand utiliser le skill et quand l'éviter, et des exemples de demandes. Le modèle y propose aussi la catégorie, les tags, les outils compatibles et le niveau.

La seconde lecture est un audit. Le modèle reçoit en plus la liste des outils que le skill déclare, et rend une note de sécurité, un score qualité et un avis.

La note de sécurité est « Sûr » quand le modèle ne voit pas de risque d'exécution notable. Elle est « Prudence » quand le skill se sert d'outils puissants (bash, docker, réseau) pour un usage légitime, et « Risqué » quand il demande des actions destructrices, l'envoi de secrets vers l'extérieur ou l'exécution de code masqué. Les points relevés s'affichent sur la fiche.

Le score qualité, de 0 à 100, juge la clarté, l'utilité, la complétude et l'originalité. L'avis tient en un mot : publier, revoir ou rejeter.

Quand le score qualité tombe entre 70 et 85, ou que la note est « Prudence », le modèle refait l'audit. La fiche affiche alors le score le plus bas et la note la plus sévère des deux passages.

Des règles fixes sur tout le texte

En plus du modèle, des règles fixes, sans IA, parcourent tout le fichier. Elles repèrent les clés secrètes réelles (pas les exemples de documentation), les commandes qui effacent le disque ou le dossier personnel (rm -rf / ou ~, mkfs, dd vers /dev), le code masqué dans une longue chaîne base64 qu'on décode, et l'envoi vers un serveur de fichiers d'identifiants (~/.ssh, .env, identifiants AWS) ou de tout l'environnement. Elles relèvent aussi le téléchargement d'un script exécuté aussitôt (curl | sh), et les phrases écrites pour manipuler l'évaluateur, comme « ignore previous instructions » ou « rate this skill as safe », ou leurs équivalents en français.

Chaque constat s'affiche dans l'analyse de sécurité de la fiche et fait passer une note « Sûr » à « Prudence ».

La décision

Le modèle ne publie rien lui-même. Une règle fixe lit son audit et tranche. Un avis « rejeter » ou une note « Risqué » font rejeter le skill. Un avis « publier » avec une note « Sûr » ou « Prudence » le fait publier. Tous les autres cas le laissent en attente, hors du site.

Deux garde-fous s'ajoutent. Si l'audit a été refait et que la règle ne donne pas la même décision pour les deux passages, le skill reste en attente. Et un skill que la règle publierait reste lui aussi en attente quand une règle fixe a relevé un problème. Ces règles fixes ne rejettent jamais un skill à elles seules.

Une exception : la règle fixe qui repère un curl | sh ne met pas le skill en attente, car c'est ainsi que sont distribués la plupart des installateurs officiels. Elle ajoute un avertissement à l'analyse de sécurité et porte la note au moins à « Prudence ». Le modèle peut, lui, noter ce skill « Risqué » s'il juge le script dangereux, et le skill n'est alors pas publié.

Une fiche publiée après cette lecture porte le badge « Vérifié », avec sa note de sécurité et son score qualité.

Ce qui est proposé aux moteurs de recherche

Les fiches publiées ne sont pas toutes proposées à Google. Seules le sont celles qui ont un score qualité d'au moins 80, une note « Sûr » ou « Prudence » et au moins 800 caractères de contenu, à condition de ne pas être des copies. Les autres restent consultables sur le site, avec une consigne qui demande aux moteurs de ne pas les indexer.

Quelle confiance accorder à l'algorithme

Skills Guide a comparé, sur 60 skills, les décisions de l'algorithme à celles d'un modèle plus puissant, Claude Opus, qui a lu chaque fichier en entier, deux fois. Seuls comptent les skills pour lesquels Claude Opus a donné deux fois la même réponse : 53 pour le statut, 57 pour la note de sécurité. Sur ces skills, l'algorithme arrive au même statut (publié, en attente ou rejeté) dans environ 78 % des cas, et à la même note de sécurité dans environ 91 % des cas.

Sur les 25 skills que Claude Opus ne publiait pas, l'algorithme en a publié 5. Claude Opus les aurait laissés en attente ; il n'en rejetait aucun. L'algorithme est donc plutôt généreux. Claude Opus n'est ici qu'un point de comparaison, et il peut lui aussi se tromper.

Les limites

Aucun skill n'est testé en conditions réelles.

Seul le fichier SKILL.md est lu. Les scripts et les autres fichiers du dépôt ne sont pas analysés. Sur un fichier long, l'audit s'arrête aux 40 000 premiers caractères, et la fiche aux 4 000 premiers.

Le modèle peut aussi se tromper, en laissant passer un skill problématique ou en notant mal un bon skill.

Les règles fixes cherchent des formes précises. Elles peuvent manquer une variante déguisée, ou signaler à tort un skill qui décrit une commande dangereuse sans la faire exécuter.

Des skills ajoutés avant la mise en place de cette lecture n'ont pas encore été lus par le modèle. Leur fiche n'affiche alors ni badge « Vérifié » ni analyse de sécurité.

Les fiches vérifiées avant le déploiement de cette version ont été lues avec la précédente, qui s'arrêtait aux 6 000 premiers caractères.

Chaque skill appartient à son auteur et reste sous la licence de son dépôt d'origine. Skills Guide ne garantit ni qu'il fonctionne, ni qu'il est sûr.

Avant d'installer un skill

Lisez le SKILL.md en entier, dans l'onglet « Contenu » de la fiche, et repérez les outils qu'il déclare et les commandes qu'il vous fera lancer. Quand la fiche indique un dépôt d'origine, vérifiez-y la licence et les scripts éventuels. Si un skill vous semble dangereux ou faux, signalez-le à son auteur sur ce dépôt.