Aller au contenu principal

Compétences d’agent

Une compétence est une procédure opérationnelle conditionnée qu’un agent peut découvrir et charger pour une tâche correspondante. La spécification partagée définit un cœur portable autour d’un répertoire et de SKILL.md ; les hôtes peuvent différer pour la découverte, les métadonnées, l’activation, les outils et l’exécution de code.

Une compétence est une convention et un ensemble de contenus, pas une sandbox isolée ni la preuve qu’une procédure fonctionne.

Anatomie d’un paquet

Un répertoire my-skill/ typique contient :

  • SKILL.md pour le déclencheur, les limites, le flux et les vérifications ;
  • scripts/ pour la mécanique déterministe lorsqu’elle est justifiée ;
  • references/ pour le contenu détaillé chargé à la demande ;
  • assets/ pour les modèles ou exemples non secrets ;
  • d’éventuelles métadonnées propres à l’hôte.

La divulgation progressive réduit le contexte par défaut : les métadonnées permettent la découverte, SKILL.md décrit le parcours et les fichiers auxiliaires ne sont chargés qu’au besoin. Les hôtes n’implémentent pas nécessairement chaque étape de façon identique.

Ce qui a sa place dans une compétence

  • une méthode répétée d’une session ou d’un dépôt à l’autre ;
  • des règles de domaine qui modifient matériellement l’exécution sûre ;
  • une séquence bornée avec entrées, sorties, conditions d’arrêt et vérifications ;
  • des scripts déterministes qu’il est plus sûr de réutiliser que de régénérer.

Conservez les règles d’autorité stables dans les instructions du dépôt/de l’utilisateur. Conservez les faits ordinaires dans la documentation. Employez MCP ou une autre intégration lorsque ce qui manque est une connectivité active plutôt qu’une procédure.

Squelette illustré

---
name: verify-release
description: Check a release candidate after code is already staged; do not deploy.
---

# Verify release

1. Read the repository release policy completely.
2. Confirm the working tree and target version.
3. Run the smallest checks, then the full offline baseline.
4. Record commands, exit states, and skipped live checks.
5. Stop on credentials, destructive migration, or deployment request.

La description contient à la fois le déclencheur et l’exclusion. Le corps contient des preuves et des conditions d’arrêt, pas de prose incitative.

Tester une compétence

Testez plus que la validité du dossier :

TestQuestion
déclencheur positifUne demande correspondante charge-t-elle la compétence ?
déclencheur négatifUne tâche voisine l’évite-t-elle ?
cas limiteS’arrête-t-elle avant un travail non autorisé ?
exécution de la tâcheL’agent peut-il produire l’artefact et les vérifications attendus ?
référence obsolèteUne commande ou API déplacée échoue-t-elle visiblement ?
portabilitéQue change un autre hôte, modèle ou ensemble d’outils ?

Conservez les exemples d’activation échouée. Sinon, les descriptions s’élargissent avec le temps parce que seules les démonstrations réussies sont observées.

Risques et compromis

  • les instructions peuvent entrer en conflit avec une politique prioritaire ou les règles du dépôt ;
  • scripts et paquets peuvent s’exécuter avec la pleine autorité de l’utilisateur ;
  • les compétences longues peuvent consommer le contexte et encourager le rituel plutôt que le jugement ;
  • les descriptions superficielles causent des faux positifs ; les descriptions étroites font manquer des activations ;
  • les fonctionnalités propres à un hôte peuvent rendre non portable une compétence prétendument portable ;
  • les compétences copiées vieillissent, divergent et créent un risque de chaîne d’approvisionnement.

Inspectez les compétences tierces comme du code, figez leur provenance quand c’est utile, gardez les secrets hors du paquet et testez dans un espace de travail isolé. Une compétence doit réduire le raisonnement répétitif tout en préservant les décisions visibles, et non devenir une seconde application cachée dans Markdown.

Explorer les liensOuvrir le réseau