1. Traduire la procédure en capacités concrètes
Des étiquettes comme « fichiers » ou « réseau » sont trop larges pour décider. Demandez quels fichiers, commandes, domaines, comptes et opérations d’écriture sont nécessaires. Un skill documentaire lisant un dossier diffère d’un skill navigateur se connectant à un service externe, même si tous deux sont présentés comme des outils de productivité.
Examinez ensemble SKILL.md, scripts référencés, exemples de configuration et étapes d’installation. Un résumé rassurant peut omettre le comportement délégué à un script auxiliaire ou à un outil en ligne de commande.
2. Classer les accès selon leurs conséquences
La lecture locale seule peut exposer des secrets. L’écriture locale peut écraser des fichiers générés ou dupliquer des documents sensibles. L’exécution de commandes hérite des outils et de l’environnement de l’agent. Le réseau peut transmettre du contenu hors de la machine. Les actions de compte peuvent créer messages, enregistrements, déploiements ou achats. Les opérations destructrices exigent des cibles exactes et une méthode de récupération.
Ne réduisez pas ces conséquences à un badge de risque unique. Consignez le premier mode d’échec crédible et le contrôle qui l’empêche.
- Fichiers : dossiers exacts, lecture ou écriture, exclusion des secrets.
- Commandes : exécutables, arguments, répertoire de travail et points d’autorisation.
- Réseau : domaines de destination et données quittant la machine.
- Comptes : identité utilisée et effets externes autorisés.
- Opérations destructrices : cibles exactes, aperçu, sauvegarde et retour arrière.
3. Examiner les preuves sans les transformer en certification
Une révision source précise rend les instructions examinées reproductibles. Elle ne prouve pas que la procédure a été exécutée sans risque. Qualité documentaire, popularité, statut officiel et usage communautaire sont des signaux séparés ; aucun ne doit être présenté comme un audit d’exécution ou de sécurité.
Préférez les fiches indiquant ce qui a été examiné, à quelle date, ce qui reste non vérifié et les dépendances extérieures au périmètre source.
4. Installer avec un budget minimal de permissions
Utilisez d’abord une branche jetable ou un projet exemple. Retirez les identifiants sans rapport, restreignez le système de fichiers, préférez la lecture seule et autorisez une à une les actions réseau ou sur des comptes externes. Exécutez la plus petite tâche représentative avant d’élargir le périmètre.
Le budget décrit ce que le skill peut faire pendant cette tâche, pas toutes ses capacités possibles. Si la tâche exige seulement un rapport, ne donnez pas le droit de publier, déployer, envoyer des messages ou supprimer.
- Le projet de test ne contient ni secrets sans rapport ni données clients.
- Les identifiants sont limités au service et à l’action minimaux.
- Les écritures sont examinables avant d’atteindre la branche principale ou un système externe.
- Une personne nommée surveille les conditions d’arrêt lors de la première exécution.
5. Définir les conditions d’arrêt avant la première exécution
Arrêtez si la procédure demande un répertoire plus large, un exécutable inattendu, un domaine non listé, un identifiant plus privilégié ou une action externe irréversible. Arrêtez aussi si le résultat ne peut pas être relié à la révision source et à la commande exacte.
Une bonne condition d’arrêt est observable et immédiate. « Soyez prudent » n’est pas un contrôle ; « ne pas continuer si une commande écrit hors de ce répertoire de travail » en est un.