Arrêtez de construire des agents, commencez à construire des compétences : quatre règles des ingénieurs d'Anthropic

Les deux ingénieurs derrière le format Agent Skills chez Anthropic, Barry Zhang et Mahesh Murag, ont arrêté de construire un agent distinct pour chaque tâche. Leur raisonnement est simple : l'agent sous-jacent s'est révélé bien plus polyvalent que prévu, si bien qu'il suffit d'habiller le même corps avec des connaissances spécifiques à chaque métier. À mes yeux, c'est la correction de cap la plus pratique de l'année écoulée.

L'analogie du téléphone résume tout en une phrase : le modèle est le processeur, le runtime de l'agent est le système d'exploitation, et la compétence est l'application. Personne n'assemble un téléphone distinct par application ; on installe la bonne application sur le même appareil. Comme Claude Code sait déjà lire des fichiers, écrire du code et appeler des outils, le même corps sert tout, des présentations aux études d'entreprise, et seule la compétence attachée change.

La première règle est ma préférée : cesser de faire résoudre au modèle des problèmes techniques déjà résolus. L'équipe a vu Claude réécrire presque le même script Python à zéro à chaque mise en forme de diapositives, ce qui brûlait des jetons et produisait un résultat différent à chaque exécution. La solution a été de stocker le script fonctionnel dans le dossier de la compétence afin que les exécutions suivantes utilisent directement le fichier éprouvé. Le principe DRY du logiciel, transplanté ici. Mon atelier suit le même schéma : je ne laisse jamais un script qui a produit un résultat qui me plaît pourrir dans un chat. La recette de la vidéo correspond : enregistrer le script dans le dossier scripts de la compétence, mettre à jour SKILL.md pour que les exécutions futures utilisent ce fichier, puis lancer la même tâche deux fois et comparer les parties importantes. La prose environnante peut encore varier, mais l'élément critique n'est plus une supposition fraîche, c'est du code testé.

La deuxième règle résout la découverte : une fois que des dizaines de compétences s'accumulent, comment le modèle choisit-il la bonne ? La réponse est un chargement par étapes appelé divulgation progressive : Claude ne voit d'abord que le nom et la description de chaque compétence, les métadonnées YAML. Quand la formulation d'une demande correspond à une description, le SKILL.md complet de cette compétence est lu, tandis que les gros fichiers compagnons attendent dans le dossier jusqu'à ce qu'ils soient vraiment nécessaires. Les instructions non pertinentes ne gonflent jamais le contexte de travail.

Mais ce mécanisme vit ou meurt selon la clarté des descriptions. Deux descriptions vagues comme aide au contenu et production d'actifs marketing obligent le modèle à jouer à pile ou face. Une description forte énonce la tâche ainsi que les formulations réelles des utilisateurs qui doivent la déclencher. Le triple test de la vidéo est pratique : une demande de déclenchement évidente, la même demande formulée différemment, et une demande sans rapport qui ne doit jamais déclencher. Une compétence introuvable n'existe pour ainsi dire pas.

La troisième règle rend les corrections permanentes : chaque cycle corriger-puis-fermer-le-chat jette une leçon aux orties. Dire seulement corrige-le répare le résultat mais laisse le processus cassé. À la place, on demande au modèle de remonter à la source : où a-t-il cherché, pourquoi a-t-il raté, faut-il mettre à jour le routage ou la compétence. Un processus erroné signifie mettre à jour les instructions, une voix ou des exemples manquants signifient ajouter un fichier de référence, une erreur répétée signifie ajouter une règle de blocage explicite. Puis la même tâche est relancée pour vérifier la correction.

Une limite honnête est tracée ici : aucune compétence ne peut faire qu'un modèle plus faible performe comme un modèle plus puissant, car chaque modèle interprète les instructions différemment. Ce qui se transmet, c'est le processus. Comme Agent Skills est un format ouvert, le même dossier peut être essayé sur des runtimes compatibles, et partout où il échoue, on traque les hypothèses cachées. L'annonce du standard ouvert de décembre 2025 a formalisé cette portabilité.

La quatrième règle, présentée comme la plus importante : une compétence ne doit jamais remettre sa première tentative à l'utilisateur. Terminer soixante-dix pour cent d'une tâche et déposer sur un humain un fichier mal formaté et sans sources est l'échec le plus courant. Le remède consiste à intégrer dans la compétence les vérifications que l'on connaît déjà : rendre les diapositives visuellement et corriger les débordements, confronter les affirmations de recherche aux sources primaires et écarter ce qui ne peut être prouvé, relire les brouillons avec les yeux d'un débutant et d'un sceptique. Mon schéma préféré tient en une phrase : définir d'abord les critères d'acceptation, construire la version un, l'inspecter avec la méthode adaptée, corriger chaque problème trouvé, lancer une deuxième passe, et retenir le résultat tant que les critères ne sont pas satisfaits. Ce qui ne peut être vérifié doit être déclaré ouvertement. Là où une métrique de succès objective existe, les agents continuent de travailler jusqu'à l'atteindre. Ainsi, le premier regard de l'utilisateur n'est jamais le premier regard du modèle, c'est son quatrième ou cinquième.

Pour résumer, l'image est nette : sauvegarder le code éprouvé, rendre chaque compétence découvrable grâce à une description pointue, transformer les corrections en instructions durables, vérifier avec des preuves avant livraison. Ensemble, les quatre règles transforment un agent polyvalent en un assistant qui sait comment je travaille. C'est aussi la phrase de clôture de la vidéo : ne construisez pas l'agent, mais la manière dont l'agent travaille pour vous.

Un peu de contexte s'impose aussi : Agent Skills a été annoncé en octobre 2025 pour Claude Code, expliqué à travers un exemple concret comme l'édition de PDF, et partagé dans un dépôt public. Le concept s'est propagé à d'autres plateformes, dont Codex. La vidéo ne décrit donc pas l'idée d'un seul canal, mais un schéma devenu une pratique industrielle en quelques mois, dont les quatre règles constituent la forme distillée.