Créer un dépôt de compétences d’agents d’IA qui évaluent la qualité des sites web

## Découper le dépôt en une compétence par thème de qualité web Traitez le dépôt comme un ensemble de capacités d’agent autonomes plutôt que comme un unique fichier d’instructions monolithique. Séparez les audits généraux des compétences ciblées sur les performances, l’accessibilité, la découvrabilité, la qualité globale et les métriques d’expérience utilisateur, afin qu’un agent ne charge que la capacité nécessaire à la tâche. Conservez à la racine la documentation générale du dépôt, les règles de contribution, la licence et les consignes destinées aux agents. Chaque répertoire de compétence contient son fichier d’instructions principal, ses scripts d’automatisation et ses références détaillées. Ne dissimulez pas les consignes destinées aux utilisateurs, les utilitaires exécutables ou les documents sources dans des répertoires sans rapport. Avant de modifier une compétence, identifiez son contrat d’activation, les fichiers dont elle est responsable, ses dépendances, son parcours de validation et sa relation avec les autres compétences. ## Nommer dossiers et fichiers et remplir l’en-tête de SKILL.md Fournissez à chaque compétence un fichier `SKILL.md` doté d’un frontmatter YAML valide contenant : - un `name` en kebab-case ; - une `description` d’une phrase qui indique quand utiliser la compétence et comprend des formulations de déclenchement réalistes ; - les métadonnées de licence lorsque cela est requis ; - des métadonnées stables d’auteur et de version lorsque le dépôt les suit. Appliquez systématiquement les conventions de nommage exactes : - les répertoires de compétences utilisent le kebab-case ; - le fichier d’instructions principal se nomme exactement `SKILL.md` ; - les noms des fichiers de script utilisent le kebab-case et une extension exécutable appropriée ; - les noms des fichiers de référence suivent la convention documentée du dépôt en majuscules. Gardez le paquet autonome et vérifiez que chaque chemin mentionné par la compétence se résout dans l’organisation de dépôt prise en charge. ## Garder SKILL.md sous 500 lignes et déplacer les détails dans des références Limitez la compétence principale à moins de 500 lignes. Placez l’activation, le flux de travail essentiel, les contraintes critiques et la navigation dans `SKILL.md` ; déplacez les explications détaillées, les exemples volumineux et le contenu spécialisé dans les références. Rédigez des consignes précises et exécutables. Chaque consigne doit comporter un titre court, une instruction directe et toute valeur ou tout seuil nécessaire à son application. Privilégiez les consignes qui expliquent ce qu’il faut inspecter, quelle décision prendre et quelles preuves attestent l’achèvement. Utilisez des scripts pour les tâches déterministes ou répétitives lorsque leur résultat consommerait autrement le contexte de raisonnement. Ne dupliquez pas la même procédure dans la compétence principale et plusieurs références. ## Montrer le code avant et après et des tableaux de seuils bons et mauvais Présentez le problème et le modèle corrigé chaque fois qu’une consigne régit un comportement exécutable. Gardez les exemples assez courts pour être compris isolément et vérifiez qu’ils fonctionnent réellement. Par exemple, une consigne sur la stabilité des images doit opposer une image insuffisamment spécifiée à une autre qui déclare ses dimensions et des métadonnées de chargement utiles : Problème : un élément image contenant uniquement `src="hero.jpg"`. Amélioration : le même élément avec `width="1200"`, `height="600"`, `alt="Hero image"` et `loading="lazy"`. Présentez les seuils de qualité comparables dans un tableau indiquant explicitement les plages bonnes, intermédiaires et mauvaises. Précisez l’unité et les opérateurs de limite afin que les lecteurs n’aient pas à déduire si une limite est inclusive. ## Écrire des scripts shell qui s’arrêtent sur erreur et renvoient du JSON Les utilitaires shell doivent échouer immédiatement, produire des sorties lisibles par une machine et permettre un nettoyage sûr : - déclarez le shell prévu à l’aide d’un shebang ; - activez un comportement d’échec immédiat tel que `set -e` ; - envoyez les messages de progression et d’état vers la sortie d’erreur standard ; - envoyez les résultats lisibles par une machine, comme du JSON, vers la sortie standard ; - créez les fichiers temporaires de manière sûre et enregistrez des gestionnaires de nettoyage ; - restez autonomes ou documentez chaque dépendance externe et chaque prérequis. N’incluez pas les diagnostics destinés aux humains dans le flux lisible par une machine. Testez les comportements en cas de réussite, d’échec, d’entrée mal formée et de nettoyage avant de considérer un utilitaire comme une automatisation réutilisable. ## Limiter chaque référence à un sujet et la relier depuis la compétence Attribuez à chaque référence un sujet ciblé, des exemples pratiques et des liens vers des ressources faisant autorité. Limitez si possible chaque référence à moins de 200 lignes, afin qu’un agent puisse la charger indépendamment sans récupérer de contexte sans rapport. Reliez chaque référence depuis la compétence principale ou un index maintenu. Supprimez les liens obsolètes et les consignes dupliquées, et faites de la source faisant autorité la plus proche la propriétaire des faits susceptibles d’évoluer. Utilisez les références pour approfondir, et non comme un fourre-tout. Une référence doit aider l’agent à prendre ou à exécuter une décision distincte. ## Vérifier en-tête, exemples, liens et scripts avant de publier une compétence Avant de soumettre ou de publier une compétence : 1. Analysez et validez le frontmatter YAML. 2. Confirmez que la description contient des déclencheurs d’activation utilisables. 3. Exécutez ou vérifiez autrement chaque exemple exécutable. 4. Confirmez que chaque fichier référencé existe et que chaque lien interne se résout. 5. Testez les scripts via leur interface documentée et vérifiez le comportement de leurs canaux de sortie. 6. Validez le paquet par rapport à la spécification des compétences d’agent qui le régit. Considérez une vérification syntaxique réussie comme nécessaire, mais insuffisante. La description d’activation, les exemples, les références et les scripts doivent correspondre au comportement promis par la compétence. ## Classer les problèmes de critique à faible et garder des conseils indépendants des frameworks Classez les constats de manière cohérente : 1. **Critique :** vulnérabilités de sécurité ou défaillance fonctionnelle totale. 2. **Élevé :** graves problèmes de performances ou obstacles majeurs à l’accessibilité. 3. **Moyen :** possibilités significatives d’amélioration des performances, de la découvrabilité ou de la qualité de la recherche. 4. **Faible :** style du code et possibilités d’optimisation mineures. Gardez les consignes Web indépendantes des frameworks. Présentez d’abord le HTML, le CSS et le JavaScript standards, placez les remarques propres aux frameworks dans des sections distinctes et privilégiez les API standard de la plateforme, sauf si une dépendance à un framework est indispensable à la tâche. Examinez les problèmes d’exactitude et les obstacles d’accès ayant le plus fort impact avant de consacrer des efforts aux améliorations stylistiques. ## Mettre à jour une compétence sans casser les phrases qui la déclenchent Préservez la rétrocompatibilité lors de la mise à jour des descriptions de compétences et veillez à ce que les formulations de déclenchement établies continuent de fonctionner. Actualisez les métadonnées de version avec l’implémentation et documentez les changements incompatibles dans le journal des modifications requis par le dépôt ou dans la description du commit. Lorsque la structure change, mettez à jour ensemble la compétence principale, les références, les scripts, les exemples et les liens concernés. Examinez le diff final pour détecter tout élargissement accidentel du périmètre, contenu généré obsolète ou consigne dupliquée. Réexécutez la liste de contrôle de validation ciblée après chaque modification comportementale. N’affirmez pas qu’une compétence mise à jour est prête tant que son parcours d’activation, ses exemples ou ses ressources référencées n’ont pas été vérifiés.