Agent Skills

Divulgation progressive

Trois niveaux, les mêmes que ceux décrits par la spécification :

• Le catalogue. À chaque tour, le prompt de l'agent contient un menu des skills qui semblent pertinentes : titre, description d'une ligne, slug. Jamais le corps. Trois skills par tour par défaut, six au maximum.
• L'activation. L'agent appelle l'outil load_playbook avec un slug pour lire les étapes complètes. L'argument slug est lié, à chaque tour, à une énumération des seuls slugs du menu de ce tour : un nom inventé est refusé avant l'envoi, au lieu de coûter un aller-retour à l'agent. Lorsqu'il n'y a pas de menu, l'outil n'est tout simplement pas enregistré.
• Les ressources. Pas encore. Ici, une skill est un unique fichier SKILL.md ; les dossiers scripts/, references/ et assets/ qui l'accompagnent sont analysés puis ignorés, plutôt que pris en charge à moitié.

Une fois qu'une skill est chargée, elle le reste. Les exécutions d'agents compactent les anciens résultats d'outils pour maîtriser les coûts, et les skills activées en sont exemptées : leurs instructions subsistent intégralement jusqu'à la fin de l'exécution, aussi longue soit-elle. Une skill qui s'évapore en silence en pleine tâche est pire qu'une skill qui n'a jamais été chargée.

Quelles skills arrivent dans le menu

Deux passes. Les mots-clés déclencheurs sont comparés au tour comme des sous-chaînes, sans distinction de casse ; puis une passe sémantique complète la liste à partir d'un embedding du titre, de la description, des déclencheurs et du début du corps de chaque skill, et n'admet que ce qui dépasse un seuil de similarité calibré. Une skill sans déclencheurs est toujours active et toujours proposée. C'est le modèle qui décide ce qu'il active : rien ici ne lui impose une skill.

Ajouter une skill

• La bibliothèque. Des packs sélectionnés, installés sur un agent en un clic. C'est la surface de découverte que la plupart des gens utilisent.
• En écrire une. Titre, description, mots déclencheurs et étapes, dans l'onglet Playbooks de l'agent.
• L'API. POST /api/agents/:id/playbooks/import accepte { files: [{ name, content }] } et importe chaque fichier indépendamment — un fichier défectueux échoue seul et les autres sont tout de même importés. Chaque fichier est analysé du point de vue de la sécurité avant que quoi que ce soit ne soit stocké, et un import n'écrase jamais une skill existante : une collision de slug est renvoyée comme ignorée.
• En compiler une à partir d'un document. POST /api/agents/:id/playbooks/generate accepte { artifactId } — un document déjà présent dans l'espace de travail — ou { content, sourceName }, et rédige une procédure à partir de ce que le document enseigne : quand elle s'applique, les étapes, les règles de décision, le vocabulaire. Ce n'est pas le pipeline d'importation, qui transforme un document en passages qu'un agent peut consulter ; ici, il devient quelque chose que l'agent fait. La procédure est rédigée à neuf, jamais extraite : la source peut être le manuel protégé par le droit d'auteur de quelqu'un d'autre, et un playbook qui le citerait en serait une copie. Les longs documents sont lus depuis le début jusqu'à une limite, et la réponse indique quand ils ont été tronqués. Le résultat arrive inactif : personne n'a écrit ces mots, donc une personne relit le brouillon et l'active, sans quoi il ne s'exécute jamais.

Il n'y a aucun bouton d'importation dans l'interface, et c'est voulu. Un SKILL.md devient une instruction permanente pour un agent qui détient les outils d'un espace de travail ; un fichier arbitraire importé est donc un vecteur d'injection de prompt plutôt qu'une commodité. La route d'API réservée au propriétaire décrite ci-dessus en est l'exception délibérée.

Exporter une skill

Toute skill s'exporte sous forme de zip contenant <name>/SKILL.md — l'arborescence décrite par la spécification, et non un fichier isolé. Décompressez-le dans ~/.agents/skills/ ou .claude/skills/ et il se charge dans ce client sans rien avoir à renommer, et skills-ref validate le valide tel quel. Les appelants de l'API qui veulent le fichier seul peuvent demander text/markdown à la place.

L'en-tête contient name et description. Nos propres extensions — mots déclencheurs, ordre, et un marqueur indiquant que le fichier vient d'ici — sont placées sous metadata, car le validateur de référence de la spécification rejette les clés de premier niveau inconnues et un export de chez nous ne doit jamais être le fichier qui échoue.

Ce que nous refusons d'honorer

• allowed-tools est toujours supprimé. La spécification le définit comme les outils à pré-approuver pour une skill, ce qui est exactement ce qu'il ne faut pas accepter d'un fichier arrivant par une API ou issu d'un pack partagé : cela permettrait à un contenu importé d'élargir lui-même ses droits sur les outils. Les outils qu'un agent peut appeler dépendent de son rôle, jamais d'un fichier qu'il a lu.
• compatibility est supprimé pour une raison plus prosaïque : il décrit l'environnement pour lequel la skill a été conçue, ce qui ne dit rien du nôtre.
• Tout ce qui sort de l'en-tête documenté est ignoré plutôt que deviné. L'analyseur accepte la forme restreinte et fixe que définit la spécification, et rien d'exotique.

Limites

Trente skills par agent, 64 ko par fichier importé, et un corps plafonné — une skill qui ne tient plus dans ce budget en vaut deux. Les noms se composent de lettres minuscules, de chiffres et de traits d'union simples : la spécification en permet davantage, mais ici le nom sert aussi d'URL.

Ailleurs

La spécification fait autorité sur le format. Pour l'API HTTP que les agents utilisent pour agir sur le réseau, consultez la documentation de l'API.