Guide original CODEZ / 01
Comment choisir la compétence d'un agent : du classement par étoiles à l'essai pratique
Les listes peuvent vous aider à affiner votre recherche. La sélection finale dépendra de la capacité d'une compétence à accomplir une tâche spécifique dans votre contexte. Ce guide propose une méthode de filtrage réutilisable.
Vérification des données:
Le format et les faits sur les projets proviennent des sources originales liées ; les étapes de sélection et les critères d’acceptation sont des conseils éditoriaux de CODEZ. Les candidats PDF sont des skills réellement répertoriés, comparés à partir de leurs sources à un commit fixé. Nous n’avons pas exécuté ces skills tiers ; les exemples ne sont pas des résultats de tests réels.
01 / Commencez par déterminer la compétence dont vous avez besoin
Les Agent Skills sont généralement organisés en dossiers. SKILL.md contient les métadonnées et les instructions ; des scripts, références et modèles peuvent l’accompagner. Le champ compatibility de la spécification indique les exigences de l’environnement, mais il est facultatif. Même absent, il faut vérifier le corps du document et les dépendances.
Commencez par décrire les méthodes de saisie, de sortie et de validation. Par exemple : « Extraire les tableaux des fichiers PDF contenant des calques de texte vers des fichiers CSV, en conservant les noms de colonnes. » « M’aider à traiter des documents » est une formulation trop vague qui ne permet pas de déterminer avec précision si un candidat convient.
02 / Ce que les étoiles d’un dépôt indiquent
Les étoiles GitHub permettent de mettre des projets en favoris et d'exprimer sa reconnaissance envers leurs responsables. Elles nous servent donc d'indicateur de la popularité d'un projet.
Le classement du site utilise les étoiles GitHub des dépôts. Un dépôt contenant des centaines de skills peut attirer l’attention grâce à une partie seulement de son contenu ; son total d’étoiles ne peut pas être attribué à chaque skill. Pour comparer des skills de deux dépôts, examinez d’abord leur adéquation à la tâche, puis utilisez la popularité comme information complémentaire.
La date de la dernière mise à jour peut seulement aider à trouver des informations. Une modification isolée et sans lien apparent avec le problème ne signifie pas que la fonctionnalité recherchée a été corrigée ; il est conseillé de consulter les commits, les exemples et les journaux d'incidents du répertoire concerné.
03 / Transformez les besoins en critères vérifiables
Les conditions suivantes sont plus faciles à interpréter et à vérifier qu'un simple classement de popularité. Il n'est pas nécessaire de combiner le nombre de conditions remplies par les candidats en un score total apparemment précis.
| Scénario | Premier contrôle | Observer pendant l'essai |
|---|---|---|
| Traitement de documents et de feuilles de calcul | Type d'entrée, format de sortie, dépendances système | Perte de noms de colonnes, d’encodage, de mise en page ou de données |
| Flux de travail de code et de développement | Langage cible, version du framework et outils requis | Étendue des modifications, retour d'information sur les erreurs et réussite de l'inspection du projet. |
| Recherche et compilation de données | Portée de la source, exigences de citation et conditions du réseau | Traçabilité des citations et conclusions qui dépassent les preuves |
04 / Ouvrez le fichier d'origine et vérifiez l'environnement et le périmètre d'exploitation.
Ouvrez SKILL.md depuis une fiche du site, puis le README du même dossier. Un README en chinois aide à comprendre les instructions, mais la disponibilité de plusieurs langues ne prouve pas que le skill convient. Sans version chinoise, confirmez les conditions essentielles dans l’original.
Notez ces informations avant d'essayer :
- Environnement d'exploitation : Clients pris en charge, systèmes d'exploitation, outils en ligne de commande et exigences de version explicitement spécifiées.
- Étendue des opérations : Quels fichiers seront lus ou modifiés, quels services externes seront appelés et si des identifiants sont requis.
- Ressources supplémentaires : Les scripts et fichiers de référence cités dans le texte existent-ils ? Que feront les commandes exécutées ?
- Conditions d’utilisation : lisez les licences du projet et du dossier du skill. Les mentions « Non précisé » et « À vérifier » indiquent des informations non confirmées.
- Reproductibilité : notez le dépôt, le chemin précis du skill et le commit utilisé pendant le test pour retrouver le même contenu plus tard.
05 / Comparez les candidats avec la même petite tâche
Sélectionnez deux ou trois candidats les plus adaptés à la tâche et testez-les avec les mêmes données non sensibles dans une copie de test récupérable. Activez uniquement les fonctionnalités dont vous avez besoin lors de la première utilisation, en suivant les instructions d'installation du client.
Définissez les conditions de réussite avant de commencer. Pour l'extraction de données d'une table, vérifiez le nombre de lignes, les noms de colonnes et les valeurs nulles ; pour les modifications de code, vérifiez la fonctionnalité cible, les fichiers modifiés et les contrôles existants du projet. En cas d'échec, consignez l'erreur et l'environnement ; n'attribuez pas immédiatement l'échec au modèle ou à la compétence elle-même.
Consignez toutes les corrections manuelles nécessaires, les outils supplémentaires, les coûts des services externes et le temps d'exécution. L'utilisation d'une méthode d'enregistrement systématique pour les tâches répétitives facilite la prise de décision par rapport à une simple impression du résultat.
- Candidat et version : dépôt / chemin du skill / commit.
- Entrée et environnement : Exemple / Système d’exploitation / Client et dépendances.
- Résultats et corrections : Quels éléments d’acceptation ont été validés et lesquels ont nécessité un traitement manuel ?
- Ressources et décisions : Services, temps et coûts utilisés, et raisons de l'adoption ou du report.
06 / Candidats réels : comment choisir entre deux skills PDF homonymes ?
Le site répertorie skills/pdf/SKILL.md dans anthropics/skills et skills/.curated/pdf/SKILL.md dans openai/skills. Les deux skills portent le nom pdf ; notez d’abord le dépôt et le chemin complet pour ne pas confondre ces entrées avec un même jeu d’instructions. Le tableau suivant compare les priorités décrites dans les sources, sans supposer que les capacités s’excluent mutuellement ni utiliser les étoiles pour désigner le plus précis.
Le document Anthropic fournit des exemples de diverses techniques de manipulation de PDF, notamment l'extraction de texte et de tableaux, la manipulation de pages, la génération et la reconnaissance optique de caractères (OCR) de documents numérisés, et renvoie au fichier FORMS.md pour le traitement des formulaires. Le document OpenAI met l'accent sur la lecture, la création et la vérification de la mise en page, exigeant des contrôles après le rendu des pages et après des mises à jour importantes ; l'extraction de texte est insuffisante pour garantir la validité de la mise en page.
| Candidat et chemin complet | Points saillants du texte original | CODEZ recommande de vérifier ceci en premier. | Reste à vérifier |
|---|---|---|---|
| anthropics/skills / skills/pdf/SKILL.md | Des exemples sont fournis pour chaque opération : extraction, traitement de page, génération et reconnaissance optique de caractères (OCR). | Lors de l'extraction de tableaux ou du traitement de documents numérisés, vérifiez d'abord les opérations et dépendances correspondantes. | Structure du tableau, langue et précision de la reconnaissance optique de caractères (OCR), disponibilité des sources citées et des outils |
| openai/skills / skills/.curated/pdf/SKILL.md | Créer, réviser et vérifier la mise en page par rendu. | Lorsqu'un rapport lisible est requis, vérifiez d'abord le processus de rendu et d'inspection. | Polices de caractères, tableaux, numéros de page et pagination ; la possibilité d’afficher le texte dans un environnement réel. |
anthropics/skills : skills/pdf/SKILL.md (commit fixé) ↗
openai/skills : skills/.curated/pdf/SKILL.md (commit fixé) ↗
07 / Décomposer « Extraction réussie » en éléments d'acceptation vérifiables.
Voici une proposition de test : comparez les candidats avec la même liste d’inventaire non sensible de deux pages. Incluez l’identifiant 0017, des noms de colonnes en chinois, une description vide, un en-tête répété en deuxième page et une cellule fusionnée. Vérifiez manuellement le résultat attendu et conservez les pages sources et une copie du fichier. Ce test n’a pas été exécuté.
Avant de commencer, vérifiez si le texte peut être sélectionné et essayez d’en extraire une petite partie. Ces vérifications ne donnent que des indices : une couche de texte ne garantit pas une structure de tableau correcte, et le texte OCR d’un document numérisé peut contenir des erreurs. Si un OCR est nécessaire, consignez la langue et les outils système utilisés ; notez les dépendances manquantes comme un problème d’environnement.
- Consignez le commit du candidat, le client, le modèle, les versions des outils et le type d’entrée pour ne pas confondre les différences d’environnement avec celles des skills.
- Consignez les lignes corrigées manuellement et les raisons de ces corrections, la durée d'exécution et les services réellement appelés ; les données non mesurées doivent être laissées vides.
- La conclusion correspondante ne sera acceptée que si tous les critères d'acceptation énumérés sont respectés. Même si un échantillon est validé, vos données d'entrée doivent encore être vérifiées.
| Éléments d'inspection | Résultats à vérifier | Comment gérer l'échec |
|---|---|---|
| Numéro de matériel | Conservez les zéros initiaux de 0017 ; ne le transformez pas automatiquement en 17 | Après avoir clarifié les types de champs, extrayez à nouveau les données et vérifiez chaque élément. |
| Tableau réparti sur plusieurs pages | L'en-tête de la deuxième page n'est pas comptabilisé comme donnée, et aucun enregistrement n'est perdu ou dupliqué. | Conservez les numéros de page, vérifiez le nombre de lignes sur chaque page, puis fusionnez-les. |
| Caractères chinois et valeurs nulles | Noms de colonnes lisibles et descriptions vides conservées, sans contenu deviné | Vérifiez l'encodage et les positions des champs, et marquez les positions qui ne peuvent pas être récupérées. |
| Fusionner les cellules | Les valeurs descriptives correspondent aux bons enregistrements, et les règles de séparation sont explicitement consignées. | Conservez la zone source et définissez manuellement les règles de correspondance |
| Format du rapport de sortie | Le contenu rendu ne présente aucune troncature, aucun chevauchement ni aucun caractère manquant. | Corrigez la police ou la mise en page et vérifiez le dernier rendu. |
08 / Les catégories, les licences et les dépendances font l'objet de trois vérifications distinctes.
Cette fois-ci, les deux entrées PDF ont été corrigées : « Conception » et « Développement » sont devenus « Document », conformément au texte original. Les fichiers d’entrée et de sortie principaux sont des PDF, et le code Python ainsi que des outils de rendu permettent de réaliser la tâche. Une seule catégorie permet uniquement de trouver des candidats, mais ne permet pas de déterminer si l’extraction ou la vérification de la mise en page est plus appropriée.
Chaque entrée possède son propre fichier LICENSE.txt dans le répertoire, et ce site affiche la mention « Fichier de licence en attente de vérification ». Veuillez consulter les licences originales de chaque répertoire ; ne présumez pas qu'elles sont librement utilisables simplement parce que le dépôt est public ou que l'organisation qui le gère est connue.
Il convient également de vérifier la liste des dépendances pour chaque opération. L'installation des bibliothèques Python ne garantit pas la disponibilité des outils de rendu système ni de l'environnement OCR ; ce document ne prouve pas la compatibilité avec les clients. Consignez dans votre journal de décisions tout outil manquant, toute étape non vérifiée et toute limitation d'utilisation.
Méthode d'examen et d'inclusion de la classification CODEZ ↗
09 / Skill Cloudflare : vérifier d’abord la configuration et les identifiants
Le 2026-10-14, cette section a vérifié le commit fixe de cloudflare/skills / skills/cf-cli/SKILL.md et la documentation officielle. Il s’agit de recommandations de sélection et d’essai de CODEZ ; ce Skill n’a pas été exécuté.
cf ne réutilise pas la connexion Wrangler. Vérifier d’abord le compte et les permissions du jeton ; consigner la version de la CLI, la configuration et les ressources cibles pour ne pas confondre différences d’environnement et différences du Skill.
| Scénario | Premier contrôle | Observer pendant l'essai |
|---|---|---|
| wrangler.jsonc, wrangler.json ou wrangler.toml existe, sans cloudflare.config.ts | Conserver d’abord le processus Wrangler pour dev, build et deploy ; les commandes de projet cf ne lisent pas cette configuration existante. | Examiner d’abord les commandes et modifications de fichiers proposées par le Skill ; décider séparément de la migration de configuration. |
| cloudflare.config.ts existe déjà | Vérifier dev, build et deploy selon le processus de projet cf ; la CLI est en beta, et une catégorie ne prouve pas la compatibilité. | Vérifier Node.js 22.18 ou ultérieur et le compte cible ; examiner le résultat de compilation et le Worker cible dans une copie de test. |
cloudflare/skills / skills/cf-cli/SKILL.md ↗
Cloudflare : comparaison officielle entre la CLI et Wrangler ↗
Cloudflare : exigences officielles d’installation et de connexion ↗