Un Skill d'agent de codage est un ensemble réutilisable et partageable d'instructions et de fichiers de support qu'un agent charge pour accomplir une tâche répétitive de la même manière à chaque fois. Pensez à la checklist de revue de votre équipe, à vos standards de livraison ou à la manière précise dont vous voulez que les migrations soient rédigées. Un Skill transforme ce savoir opérationnel en quelque chose qu'un agent peut reprendre à la demande, plutôt qu'en une connaissance qu'une seule personne garde en tête et colle dans une nouvelle conversation chaque matin.
Cette définition compte parce que la plupart des équipes découvrent les Skills à leurs dépens. Un développeur trouve un bon prompt pour écrire des tests conformes au style maison. Ça fonctionne. Deux semaines plus tard, plus personne ne le retrouve, l'agent écrit les tests de trois façons différentes dans trois dépôts, et la file de revue se remplit de dérives. Le savoir existait. Il n'a simplement jamais quitté un terminal privé. Sharkly, une plateforme tout-en-un de commande et de gestion d'agents, existe précisément pour combler ce manque : elle offre aux Skills un espace où toute l'équipe peut les créer, les importer, les lier et les réutiliser. Cet article explique ce qu'est un Skill, pourquoi le partager vaut mieux que rouvrir des conversations, comment les Skills fonctionnent dans Sharkly, et où en trouver de bons sans hériter des erreurs de quelqu'un d'autre.
Si vous débutez dans ce domaine, il est utile de clarifier d'abord les concepts qui l'entourent. Les Skills s'appuient sur le codage agentique et deviennent bien plus utiles dès que vous faites tourner plusieurs agents en parallèle.
Ce qu'est réellement un Skill d'agent de codage
Un Skill regroupe des instructions réutilisables et des fichiers de support pour le travail des agents. Utilisez-en un pour les consignes qui doivent s'appliquer de manière répétée : règles de revue, checklists de livraison, standards de rédaction ou processus d'équipe. Les instructions principales se trouvent dans un fichier SKILL.md, qui commence par un nom court et une description en YAML, suivis des étapes que l'agent doit suivre et du résultat attendu. Les fichiers de support peuvent ajouter des modèles, des exemples ou des données de référence que l'agent récupère lorsque le Skill s'applique.
Deux distinctions permettent d'y voir clair. Un Skill n'est pas une Task, et ce n'est pas non plus une configuration de modèle. Une Task est l'enregistrement partagé d'un travail donné ; un Skill est une capacité qu'un Agent mobilise pour de nombreuses Tasks. Un Skill ne s'exécute pas non plus tout seul. Un Agent le charge lorsque la description indique que le travail le requiert, suit le processus et renvoie le résultat dans la Task. Ce dernier point est essentiel : le résultat atterrit à un endroit que l'équipe peut consulter, et non dans une fenêtre de conversation qui se ferme.
Une décision évite bien des confusions. Gardez les exigences ponctuelles dans la description ou les commentaires de la Task. Créez un Skill lorsque la même capacité doit être disponible pour les exécutions futures. Si vous n'en aurez besoin qu'une seule fois, un Skill représente une charge inutile. Si trois Agents en auront besoin le mois prochain, un Skill est une infrastructure.
Pourquoi le savoir-faire en matière de prompts finit toujours par s'évaporer
Le problème que ce terme désigne est réel et bien précis. Un bon savoir-faire en matière de prompts est facile à écrire et presque impossible à conserver. Il vit dans le fichier brouillon d'une personne, dans un message Slack de mars, dans la mémoire musculaire de celui ou celle qui a configuré le dernier projet. Quand cette personne s'absente, la qualité baisse. Quand un nouveau collègue arrive, il réinvente tout. Quand vous passez d'un agent à cinq, les cinq ne sont pas d'accord.
Ouvrir davantage de conversations avec l'IA ne résout pas le problème. Une meilleure conversation produit une meilleure réponse, une fois. Elle ne produira pas une meilleure réponse pour votre collègue demain. Ce qui vous manque, ce ne sont pas plus de conversations, mais la configuration qui se cache derrière les bonnes, consignée quelque part de réutilisable. C'est le même problème que l'orchestration d'agents résout pour l'exécution, appliqué un niveau au-dessus : aux instructions elles-mêmes.
La thèse du levier : partager la configuration, pas la conversation
Le levier d'une équipe ne vient pas de l'ouverture de plus de conversations avec l'IA. Il vient du partage des rôles, des règles, du contexte et des flux de travail. Un Skill est l'unité la plus claire de ce partage. Un développeur rédige le Skill de revue une fois ; tous les Agents de l'organisation peuvent le lier et appliquer le même standard. Une bonne configuration devient une capacité de développement que l'équipe réutilise, au lieu d'une astuce personnelle qui disparaît avec son auteur.
Le contrat qui sous-tend tout cela reste humain. Les Agents chargent les Skills, les suivent et renvoient le résultat dans la Task. Ce sont les personnes qui décident quels Skills font autorité pour l'équipe, qui examinent les Skills externes avant de les lier et qui acceptent ou rejettent ce qui revient. L'automatisation prend en charge la répétition ; le jugement reste à l'équipe. Un Skill ne retire pas le relecteur de la boucle. Il garantit que le relecteur examine un travail qui a déjà suivi le processus convenu, de sorte que la revue porte sur le fond plutôt que sur des écarts de style.
C'est pourquoi les Skills s'associent naturellement au fait de confier du vrai travail à un Agent. La Task dit quoi faire. Le Skill dit comment votre équipe le fait. Ensemble, ils transforment un agent compétent mais générique en un agent qui travaille comme votre base de code l'attend.
Comment les Skills fonctionnent dans Sharkly
Sharkly traite un Skill comme un objet de première classe et gouverné, plutôt que comme un simple fichier. Chaque Skill appartient à une organisation et possède un seul périmètre, lequel détermine qui peut l'utiliser.
Créer, importer ou téléverser
Vous pouvez ajouter un Skill de plusieurs façons, selon l'endroit où le savoir réside déjà.
- Créer de zéro. Commencez par un nom, une description et des instructions. La description doit indiquer quand l'Agent doit utiliser le Skill ; les instructions définissent le processus répétable et le résultat attendu.
- Installer depuis une source publique. Sharkly peut récupérer un Skill publié depuis une source publique prise en charge et en créer une copie gérée dans le périmètre de votre choix. Examinez la source et son contenu avant de le lier.
- Importer un Skill local. Un Runtime local en ligne peut signaler les Skills qu'il trouve dans ses répertoires locaux. L'importation copie celui que vous sélectionnez dans l'organisation sous forme de Skill géré et réutilisable, tandis que la copie locale d'origine reste distincte.
- Téléverser un paquet. Fournissez un
SKILL.md, un fichier.skillou un zip. Sharkly valide les chemins et rejette les fichiers cachés, les entrées d'archive non sécurisées, les doublons et tout élément qui tente de sortir du Skill.
Le périmètre détermine qui peut l'utiliser
Chaque Skill possède exactement un périmètre, choisi à la création :
- Les Skills d'organisation sont accessibles aux Agents éligibles dans toute l'organisation.
- Les Skills de Space sont accessibles uniquement aux Agents qui appartiennent à ce Space. Un Agent ne peut pas lier un Skill de Space s'il n'appartient pas à ce Space.
- Les Skills d'Agent appartiennent à un seul Agent et y sont liés directement.
Choisissez le périmètre le plus étroit qui corresponde au public visé. Un standard de revue partagé par toute l'entreprise relève du niveau Organisation ; un flux de travail utilisé par une seule équipe relève de son Space. Le périmètre ne peut pas être modifié après la création : si le public d'un Skill doit changer, créez-en un nouveau plutôt que d'élargir l'ancien.
Lier des Skills à des Agents
Un Agent est une configuration de travail enregistrée : ses instructions, son Runtime, ses dépôts, son environnement et les Skills qui lui sont liés façonnent tous sa manière de traiter le travail. Vous ajoutez ou retirez les Skills éligibles depuis les paramètres Skills de l'Agent, ou vous les sélectionnez au moment de créer l'Agent. La liaison suit les règles de périmètre ci-dessus, et les modifications s'appliquent aux exécutions suivantes. Une mise en garde de la documentation mérite d'être répétée : évitez de lier de nombreux Skills qui se chevauchent, car des instructions contradictoires ou redondantes rendent l'exécution moins prévisible. Deux Skills précis valent mieux que six qui se contredisent.
Les permissions restent explicites. Un Skill ne peut être modifié ou supprimé que par son créateur ou par un Propriétaire ou administrateur de l'organisation ; un Skill rattaché à un Space exige en plus un accès en écriture à ce Space, et modifier les liaisons d'un Agent requiert la permission de gérer cet Agent. Supprimer un Skill le retire de tous les Agents qui l'utilisaient : mieux vaut donc vérifier les liaisons en cours au préalable.
Où trouver de bons Skills d'agent de codage
Le vocabulaire se stabilise vite. Il existe désormais des places de marché publiques de Skills, des sources comme SkillHub, ClawHub et Skills.sh, à la manière des registres de paquets, et c'est un point de départ raisonnable lorsque vous cherchez une checklist de revue ou une procédure d'écriture de tests que vous préférez ne pas rédiger de zéro. Sharkly peut installer un Skill publié depuis une source publique prise en charge directement dans le périmètre de votre choix.
L'essentiel, c'est ce que vous faites avant d'en lier un. Traitez chaque Skill externe ou importé localement comme du code ou de la configuration tiers, et non comme une politique d'organisation de confiance. Cela signifie lire les instructions dans leur intégralité, vérifier les fichiers de support et confirmer que le Skill fait bien ce que sa description annonce avant qu'un Agent ne l'exécute. Quelques règles permettent de rester serein :
- Ne stockez jamais de mots de passe, jetons d'accès, clés privées ou autres secrets dans les instructions d'un Skill ou ses fichiers de support.
- Examinez chaque Skill externe ou importé avant de l'utiliser, comme vous le feriez pour une dépendance.
- Limitez les commandes et les exemples au strict minimum de privilèges et rendez-les spécifiques à la tâche visée.
- N'incluez pas de données sensibles de l'organisation, sauf si tous les utilisateurs autorisés par le périmètre du Skill peuvent y accéder.
Les bons Skills se ressemblent. Ils sont ciblés, indiquent clairement quand ils s'appliquent, leurs instructions sont assez précises pour produire un résultat constant, et ils ne contiennent que les fichiers de support réellement nécessaires. Les collections de fichiers volumineuses et sans cap ajoutent du contexte sans améliorer les décisions de l'Agent. Si vous ne pouvez pas dire en une phrase quand un Agent doit recourir à un Skill, c'est probablement qu'il s'agit de deux Skills, ou d'aucun.
Quand vous n'avez pas besoin d'un Skill
Les Skills ne sont pas une complexité gratuite, et le conseil honnête est de s'en passer lorsque le travail est réellement ponctuel. Si une exigence ne concerne qu'une seule Task, placez-la dans la description ou les commentaires de la Task et passez à la suite. Si un Skill réside déjà directement dans le Runtime local d'un Agent et que seul ce Runtime en a besoin, il n'a pas du tout besoin d'être lié dans le produit ; ne l'importez que s'il doit devenir une capacité gérée et réutilisable dotée d'un périmètre explicite. Recourez à un Skill quand la même procédure doit survivre à l'exécution qui en avait besoin, et pas avant.
Questions fréquentes
Un Skill d'agent de codage est-il identique à un prompt ? Non. Un prompt est une instruction adressée à un modèle à un instant donné. Un Skill est un paquet nommé et réutilisable (un SKILL.md accompagné de fichiers de support facultatifs) que tout Agent éligible peut charger au fil de nombreuses exécutions, avec un périmètre et des permissions associés. Un prompt disparaît à la fermeture de la conversation ; un Skill subsiste et renvoie ses résultats dans la Task.
Quelle est la différence entre un Skill et une Task ? Une Task est l'unité de travail partagée : l'objectif, l'avancement, la revue, le tout dans un seul enregistrement. Un Skill est une capacité qu'un Agent applique aux Tasks. Vous les utilisez souvent ensemble : la Task dit quoi faire et le Skill dit comment votre équipe le fait. Le meilleur moyen de saisir cette distinction est de vous familiariser avec l'attribution d'une première Task à un Agent.
Puis-je partager un même Skill avec toute une équipe ? Oui. Attribuez-lui un périmètre Organisation et tous les Agents éligibles de l'organisation pourront le lier. Pour une seule escouade, utilisez un périmètre Space. Pour un seul Agent, un périmètre Agent. Choisissez le périmètre le plus étroit adapté au public, car il est figé une fois le Skill créé.
Est-il sûr d'installer des Skills depuis des places de marché publiques ? Cela peut l'être, à condition de les examiner au préalable. Sharkly importe un Skill public sous forme de copie gérée dans le périmètre de votre choix, mais vous devez lire les instructions et les fichiers de support et les considérer comme de la configuration tierce avant de les lier à un Agent. Ne confiez jamais de secrets ou de données sensibles à un Skill externe.
Les Skills remplacent-ils la revue humaine ? Non. Les Agents chargent les Skills, les suivent et renvoient les résultats dans la Task. Ce sont toujours les personnes qui décident quels Skills font autorité, qui examinent les Skills externes et qui acceptent ou rejettent le résultat. Un Skill relève le niveau minimal de cohérence ; il ne supprime pas le relecteur.
Où cela vous mène
Un Skill, c'est la différence entre un seul développeur qui sait comment votre équipe écrit ses tests et tous les Agents qui le savent. La définition est modeste : des instructions réutilisables et des fichiers de support qu'un agent charge pour accomplir un travail de la même manière à chaque fois. Le bénéfice, lui, ne l'est pas. Consignée sous forme de Skill et adressée au bon public, une bonne configuration devient un élément que toute l'équipe réutilise, revue après revue, au lieu d'un savoir-faire en matière de prompts qui s'évapore dès que son auteur se déconnecte.
Si vous voulez essayer, le geste utile le plus simple est concret. Choisissez une procédure que votre équipe répète, rédigez-la sous forme d'un seul Skill ciblé, rattachez-le à votre Space et liez-le à un Agent. Regardez comment les prochaines exécutions arrivent dans la Task, puis élargissez à partir de là. Sharkly donne à ce Skill une organisation, un périmètre et un point de contrôle, pour qu'il reste utile à mesure que l'équipe grandit. La présentation de la plateforme explique comment Skills, Agents et Tasks s'articulent, et la documentation approfondit chacun d'eux.
