1. Nommer la tâche et le résultat observable
Écrivez la tâche en une phrase, puis le livrable ou comportement prouvant sa fin. « Améliorer le projet » est trop vaste ; « examiner cette pull request et identifier les impacts sensibles à la sécurité avec références de fichiers » est testable.
Sans résultat observable, n’installez encore rien. Clarifiez la décision ou découpez d’abord la tâche.
- Une tâche, un responsable, une surface limitée.
- Un résultat qu’une personne peut examiner.
- Une condition d’arrêt et un retour arrière.
2. Attribuer un rôle distinct
Choisissez le rôle manquant : découverte, planification, génération, contrôle du risque, revue ou preuves. Comparez les candidats du même rôle et refusez les chevauchements déguisés sous des marques différentes.
Une grande collection rend les déclencheurs ambigus et élargit les permissions. N’ajoutez le rôle suivant qu’après un résultat utile et vérifiable du rôle courant.
3. Examiner toute la source
Ouvrez SKILL.md et chaque script, modèle, exécutable ou service externe référencé. Notez dépôt et révision examinés. Un petit fichier principal peut déléguer des actions puissantes ailleurs.
Préférez la portée projet si la procédure appartient à un dépôt. Réservez la portée personnelle à un comportement volontairement partagé dont vous assumerez la maintenance entre projets.
4. Adapter les permissions au premier test
Listez lectures et écritures, commandes, contrôle navigateur, réseau, identifiants, publication et opérations destructrices. Retirez les accès inutiles à la première petite tâche.
Compatibilité et installation sont distinctes. L’agent peut découvrir un dossier alors que scripts, hooks, dépendances ou hypothèses de système d’exploitation échouent encore.
5. Exécuter un test contrôlé et conserver les preuves
Utilisez des entrées représentatives non sensibles, un environnement réversible, des contrôles explicites et un état initial connu. Notez ce que le skill a réellement lu, écrit, exécuté, contacté et produit.
Une réussite ne prouve que cette révision, cet agent, cet environnement et cette tâche. Retestez après changement significatif de source, modèle, dépendance, permission ou plateforme.
- Déclenchement attendu et absence de déclenchement sans rapport vérifiés.
- Accès observés dans les limites convenues.
- Résultat conforme au contrôle d’acceptation nommé.
- Retour arrière à l’état initial.
Prévoir le retrait dès l’installation
Définissez les conditions de retrait avant adoption : inutilisation pendant une période de revue, rôle en double, source incertaine, permissions élargies, maintenance arrêtée, qualité moindre ou remplacement par une fonction native.
Le meilleur ensemble n’est pas celui qui a le plus d’options, mais le minimum dont vous pouvez expliquer sources, déclencheurs, permissions, résultats et responsables.