Tune skill
L'affinage est un ensemble de petites modifications fondées sur des preuves apportées à une skill qui existe déjà. Ce n'est pas une réécriture. L'objectif est une skill qui se déclenche sur les bonnes requêtes, ne gêne pas ses voisines et transmet le travail selon un format défini.
Règles fondamentales
- Lisez d'abord le vrai SKILL.md. Les README, les descriptions de dépôt et les listes s'écartent du fichier que l'agent charge réellement. Toute affirmation concernant une skill doit provenir de son SKILL.md ou de ses références. Si vous ne pouvez pas ouvrir un fichier, nommez-le et dites ce que vous déduisez à la place.
- Vérifiez vos propres affirmations. Si un fichier que vous lisez plus tard contredit quelque chose que vous avez dit plus tôt, dites-le clairement et corrigez-le. Ne contournez pas silencieusement le problème.
- Modifications minimales, dans le style de l'auteur. Modifiez uniquement ce que l'audit a trouvé et rien d'autre. Conservez les clés de préambule que vous ne reconnaissez pas (
version,argument-hint,user-invocable). N'affaiblissez jamais les règles d'honnêteté, de sécurité ou de confidentialité. - Ne prétendez pas avoir exécuté ce que vous n'avez pas exécuté. Dites quels contrôles ont été effectués, quels cas de test ont seulement été rédigés et quels fichiers vous n'avez jamais vus.
Flux de travail
1. Collecter
Obtenez le SKILL.md de la skill cible et de chaque skill voisine qu'elle touche, ainsi que toutes les références que vous pouvez atteindre. Si l'utilisateur donne un lien que vous ne pouvez pas ouvrir, demandez le texte du fichier ou son URL. Si la skill est un dossier sur le disque, exécutez le script de vérification (étape 6) maintenant pour une première lecture.
2. Cartographier
Rédigez un court inventaire par skill : ce que promet sa description, ses modes ou commandes, les fichiers de référence qu'elle nomme, et ce qu'elle transmet et à qui. Mettez les descriptions des voisines et les listes de commandes côte à côte. Les chevauchements n'apparaissent que lorsque vous pouvez voir les deux.
3. Auditer
Parcourez references/audit-checklist.md. Pour chaque constatation, enregistrez la preuve (citez la ligne), la gravité (entrave au déclenchement, confusion ou cosmétique) et la correction la plus petite. Signalez d'abord la plus grave.
4. Définir les limites
Lorsque deux skills revendiquent la même requête, attribuez-la à un seul propriétaire. Utilisez la séparation que le propre design de l'utilisateur utilise déjà (par exemple, verdict contre artefact : une skill juge, l'autre écrit). Demandez à l'utilisateur uniquement lorsque son design ne tranche pas, et demandez une seule fois.
5. Modifier
Apportez la plus petite modification qui corrige chaque constatation. Lorsque l'utilisateur déposera le résultat directement dans un dépôt, renvoyez des fichiers de remplacement complets et copiez exactement le texte non modifié. Lorsqu'une correction nécessite un nouvel élément partagé (un format de passage de relais, par exemple), ajoutez un nouveau fichier de référence au lieu de modifier un fichier que vous n'avez pas vu. Listez les fichiers de référence qui nécessitent probablement une mise à jour correspondante.
6. Valider
Exécutez le script de vérification sur chaque dossier de skill :
python scripts/check_skill.py <chemin-vers-le-dossier-de-la-skill>
Il vérifie que le nom correspond au dossier, que la description respecte la limite de 1024 caractères et contient un déclencheur et un libellé de limites, que le H1 correspond au nom, que les fichiers référencés existent et que le corps reste d'une longueur raisonnable. Corrigez chaque ÉCHEC. Évaluez chaque AVERTISSEMENT. Si vous n'avez que du texte collé, enregistrez le SKILL.md dans un dossier nommé d'après la skill et exécutez-le là ; les avertissements de référence manquante sont attendus dans ce cas.
7. Rédiger des cas de test
Suivez references/test-cases.md. Chaque limite que vous avez modifiée donne un cas de chaque côté. Exécutez-les manuellement par rapport aux descriptions. Certains agents embarquent une boucle de déclenchement automatisée dans leurs outils de création ; si vous n'en avez pas exécuté une, n'insinuez pas que vous l'avez fait. Dites ce que vous avez fait.
8. Rapporter
Restez bref :
- Ce qui a changé, par skill, et pourquoi (une ligne chacune).
- Corrections à tout ce que vous avez dit plus tôt.
- Ce que vous n'avez pas pu voir ou n'avez pas exécuté.
- Une prochaine étape.
Commencez par les modifications, pas par le processus.