1. Un autre skill porte la même décision
Le chevauchement est la raison la plus courante de retrait. Si deux paquets planifient le même changement, examinent le même diff ou conduisent le même parcours navigateur, l’équipe doit réconcilier deux résultats et deux périmètres de permissions.
Gardez le candidat le plus ciblé et le mieux étayé. Notez la capacité perdue au retrait ; si personne ne peut la nommer, le deuxième skill ne justifiait pas sa place.
2. La source ne peut plus être reconstituée
Retirez ou mettez en quarantaine un skill si son dépôt disparaît, si le chemin d’installation ne correspond plus à la source examinée, si les scripts référencés changent sans revue ou si la révision précise n’est plus reproductible.
Le déplacement de HEAD du dépôt est seulement un signal de revue. La question décisive est de savoir si les fichiers du skill indexé ou les ressources liées ont matériellement changé.
3. Il demande des accès inutilisés par la tâche
Une tâche de rapport ne devrait pas demander publication, déploiement, messagerie, suppression ou accès étendu aux identifiants. Si la première exécution représentative n’utilise pas une permission, retirez-la ou remplacez le skill par une option plus ciblée.
La portée projet fait aussi partie des limites d’accès. Retirez une installation personnelle si un seul dépôt a besoin de la procédure.
4. Personne n’examine ou n’utilise le résultat
Un skill produisant rapports, constats, captures, plans ou résumés sans relecteur nommé ajoute de l’activité plutôt que des preuves. Si son résultat est régulièrement ignoré, raccourcissez la procédure ou retirez-le.
L’automatisation se justifie lorsqu’un livrable change une décision, détecte un risque connu ou conserve des preuves reproductibles. Le volume seul ne crée pas de valeur.
5. Il échoue deux fois sur la même tâche contrôlée
Des échecs répétés sur une petite tâche représentative sont plus probants qu’une étiquette générale de compatibilité. Retirez ou isolez le skill s’il exige des permissions plus larges sans explication, écrit hors périmètre, appelle un service non listé ou produit un livrable ne passant pas l’acceptation.
Conservez l’échec, la révision source, l’environnement et le résultat du retour arrière. Le retrait ne signifie pas que le skill échoue partout, mais que sa présence dans l’ensemble actuel ne se justifie plus.
- L’échec exact est reproductible.
- La révision source et l’environnement de l’agent sont consignés.
- Aucune correction plus simple de permission ou configuration n’explique le résultat.
- Le retour arrière restaure l’état précédent.
- Le remplacement possède un test d’acceptation distinct, pas la même promesse commerciale.
Dix minutes de nettoyage mensuel
Listez chaque skill installé, sa portée, sa source, sa dernière utilisation, ses permissions, le responsable du résultat et son dernier test contrôlé réussi. Retirez les chevauchements évidents, isolez les sources incertaines et ne retestez que les procédures encore utiles.
Un ensemble plus petit facilite la découverte et clarifie les permissions. Le but n’est pas de garder cinq skills à vie, mais le minimum couvrant encore le travail observable et vérifiable.