Dans chaque équipe qui a adopté des agents de codage IA, il y a un développeur dont les prompts fonctionnent tout simplement. Ses demandes de revue reviennent structurées comme l’équipe les aime. Ses instructions d’écriture de tests produisent des tests conformes au style maison dès le premier essai. Demandez-lui comment il fait : la réponse est généralement un fichier de travail, un dépôt de dotfiles, ou un paragraphe qu’il colle dans une nouvelle session chaque matin. Le savoir-faire est bien réel. Le problème, c’est l’endroit où il réside.
Un savoir-faire de prompt qui ne vit que dans la tête d’une personne ne passe pas à l’échelle, ne survit pas aux vacances et n’apparaît dans les exécutions d’agent de personne d’autre. Quand ce développeur est absent, la qualité chute. Quand l’équipe passe d’un agent à cinq, les cinq ne sont plus d’accord sur la façon de travailler.
Les Skills sont la réponse de Sharkly à ce manque. Un Skill regroupe des instructions réutilisables et des fichiers de support pour le travail des Agents, avec un propriétaire, une portée et des permissions explicites. Si vous voulez d’abord le concept général, ce qu’est un Skill d’agent de codage couvre la définition et l’écosystème au sens large. Cet article porte sur le workflow à l’intérieur de Sharkly lui-même.
TL;DR
Un Skill dans Sharkly regroupe des instructions réutilisables et des fichiers de support pour le travail des Agents : règles de revue, listes de contrôle de livraison, standards rédactionnels, processus d’équipe. Vous pouvez le créer de zéro, installer un Skill publié depuis une source publique prise en charge, importer un Skill découvert par un Runtime local, ou téléverser un fichier SKILL.md, .skill ou une archive zip. Chaque Skill possède exactement une portée — Organisation, Espace ou Agent —, choisie à la création et fixée à vie. Les Agents lient les Skills éligibles via leurs paramètres de Skills, les modifications s’appliquent aux exécutions suivantes, et les droits de modification restent au créateur, aux Propriétaires d’Organisation et aux Admins. Résultat : le savoir-faire de prompt cesse de vivre dans les dotfiles d’un seul développeur pour devenir une infrastructure d’équipe partagée et contrôlée par des permissions.
Ce qui change quand le savoir-faire de prompt trouve sa place
La différence entre un bon prompt et un Skill ne tient pas au texte. Elle tient à tout ce qui l’entoure.
Un prompt dans un fichier de travail n’a ni propriétaire, ni audience, ni cycle de vie. Personne ne sait qu’il existe, personne ne peut dire si la copie trouvée dans Slack est à jour, et personne n’est responsable de sa mise à jour lorsque le processus change. Un Skill possède les trois. Il appartient à une organisation. Sa portée indique précisément quels Agents peuvent l’utiliser. Ses permissions de modification indiquent précisément qui peut le modifier. Quand le processus change, vous mettez à jour le Skill une seule fois, et les exécutions suivantes de chaque Agent lié récupèrent la modification.
C’est la thèse du levier en miniature. Le levier d’équipe ne vient pas de l’ouverture de plus de chats IA ; il vient du partage des rôles, des règles, du contexte et des workflows. Et comme les Agents renvoient leurs résultats dans la Tâche, la sortie d’une exécution guidée par un Skill atterrit dans l’enregistrement partagé, là où l’équipe peut l’examiner.
Une limite à poser avant d’entrer dans le workflow. Un Skill n’est pas une exigence de Tâche. Gardez les exigences ponctuelles dans la description ou les commentaires de la Tâche. Si seule cette Tâche en a besoin, c’est du contexte. Si les exécutions du mois prochain en ont besoin aussi, c’est de l’infrastructure.
Créer un Skill de zéro
Un Skill commence par trois éléments : un nom, une description et des instructions. Cette séparation est plus importante qu’elle n’en a l’air.
La description indique quand l’Agent doit utiliser le Skill. C’est la condition de déclenchement, la phrase qui signale à un Agent en train de parcourir ses capacités que celle-ci s’applique au travail qu’il a sous les yeux. Les instructions définissent le processus répétable et le résultat attendu : les étapes, les vérifications, le format que doit prendre le résultat. Un bon test consiste à vérifier si vous pouvez dire en une phrase quand un Agent doit recourir à ce Skill. Si vous n’y arrivez pas, vous avez probablement affaire à deux Skills, ou à aucun.
Sous le capot, les instructions principales résident dans un fichier SKILL.md : les champs YAML name et description en tête, suivis des instructions. Des fichiers de support peuvent l’accompagner pour fournir des modèles, des exemples ou des données de référence. Un Skill de liste de contrôle de livraison peut embarquer le modèle de liste de contrôle ; un Skill de rédaction de migration peut inclure deux exemples annotés. Gardez-les ciblés. Des collections de fichiers volumineuses ou sans rapport ajoutent du contexte sans améliorer les décisions de l’Agent.
Importer le savoir-faire que vous avez déjà
La plupart des équipes ne partent pas de zéro. Le savoir-faire de prompt existe déjà ; il est simplement dispersé. Sharkly vous propose trois voies d’import.
Installer depuis une source publique prise en charge. Sharkly peut récupérer un Skill publié et créer une copie gérée dans la portée de votre choix. La copie gérée a son importance : vous ne créez pas un lien vers le fichier de quelqu’un d’autre, vous prenez un instantané que votre organisation contrôle. Examinez la source et le contenu importé avant de le lier à un Agent. Traitez les instructions externes comme du code tiers, et non comme une politique d’organisation digne de confiance.
Importer depuis un Runtime local. C’est la voie conçue précisément pour le problème des dotfiles. Un Runtime local en ligne peut signaler les Skills découverts dans ses répertoires de Skills locaux, ce qui signifie que le savoir-faire qu’un développeur accumule discrètement devient visible pour l’organisation. L’import copie le Skill dans l’organisation ; la copie locale d’origine reste distincte, de sorte que rien ne casse dans la configuration de ce développeur. Une réserve permet de rester honnête : les Skills locaux directement accessibles au Runtime d’un Agent n’ont pas besoin d’être liés dans le produit. Importez-en un lorsqu’il doit devenir un Skill géré et réutilisable avec une portée explicite, pas simplement parce qu’il existe.
Téléverser un paquet. Si le Skill se trouve dans un dépôt ou vient d’un collègue, téléversez un SKILL.md, un fichier .skill ou une archive zip. Sharkly valide ce qui entre : les chemins de fichiers doivent être relatifs et ne peuvent pas sortir du Skill, et le téléversement comme l’import rejettent les chemins cachés ou sensibles, le contenu binaire non pris en charge, les entrées d’archive non sûres, les chemins en double et les paquets dépassant les limites du service. Un Skill, ce sont des instructions qu’un Agent va suivre ; il mérite le même examen qu’une dépendance.
Portée : décider qui peut utiliser un Skill
Chaque Skill appartient à une organisation et possède exactement une portée, choisie à la création. La portée détermine quels Agents peuvent le lier, et elle ne peut plus être modifiée par la suite.
| Portée | Qui peut l’utiliser | À choisir quand | Règle de liaison |
|---|---|---|---|
| Organisation | Les Agents éligibles dans toute l’organisation | La procédure est réellement valable pour toute l’entreprise, comme une norme de revue ou une liste de contrôle de sécurité | Peut être lié par tout Agent de la même organisation |
| Espace | Les Agents associés à cet Espace | Une équipe ou un domaine produit est responsable du processus | Un Agent ne peut le lier que s’il appartient à cet Espace |
| Agent | Un seul Agent | La capacité définit le rôle d’un seul spécialiste | Lié à son Agent cible lors de la création ou de l’import |
La règle empirique issue de la documentation est la bonne : choisissez la portée la plus étroite qui corresponde à l’audience visée. La portée est aussi un rayon d’impact. Un Skill de portée Espace qui devient obsolète sème la confusion chez les Agents d’une équipe ; un Skill de portée Organisation les trompe tous. Un prompt dans des dotfiles a une audience d’une personne, définitivement. L’audience d’un Skill est une décision délibérée, consignée dans le système.
Lier les Skills aux Agents
Un Skill ne fait rien tant qu’un Agent ne le porte pas. Dans Sharkly, un Agent est une configuration de travail enregistrée, et lier un Skill revient à lui ajouter une capacité.
La mécanique est simple. Utilisez les paramètres de Skills de l’Agent pour ajouter ou retirer des Skills éligibles, ou sélectionnez des Skills pendant la création de l’Agent. L’éligibilité suit les règles de portée. Les modifications s’appliquent aux exécutions suivantes de l’Agent : une liaison ajoutée aujourd’hui façonne donc le travail de demain sans perturber ce qui est déjà en cours.
Le jugement à exercer porte sur le nombre de Skills qu’un Agent doit porter. La documentation est sans détour : évitez de lier de nombreux Skills qui se chevauchent, car des instructions contradictoires ou redondantes rendent l’exécution moins prévisible. Deux Skills bien affûtés valent mieux que six qui se contredisent. Si la liste de Skills d’un Agent ressemble à un tiroir fourre-tout, ses exécutions aussi.
Il existe également une répartition des tâches entre les instructions propres à l’Agent et ses Skills. Les instructions de l’Agent portent un comportement stable pour ce rôle précis : son champ d’action, quand demander une intervention humaine, le format de restitution. Une procédure réutilisable que plusieurs Agents peuvent partager a sa place dans un Skill. Quand vous vous surprenez à coller le même paragraphe dans les instructions d’un troisième Agent, c’est que ce paragraphe demande à devenir un Skill.
C’est la liaison qui fait que le reste de la plateforme se cumule. Le même Agent qui porte votre Skill de revue est celui que vos Automations déclenchent selon un calendrier ou un changement de statut : une norme capturée une fois apparaît ainsi dans des exécutions récurrentes que personne ne lance manuellement. Les Skills sont aussi scriptables : la CLI expose sharkly skill list et sharkly skill view avec une sortie JSON.
Gouvernance : qui modifie, qui supprime, qui examine
Une capacité partagée exige un contrôle partagé, et c’est là que les Skills s’écartent le plus radicalement des fichiers de prompts.
Un Skill peut être modifié ou supprimé par son créateur, un Propriétaire d’Organisation ou un Admin. Un Skill de portée Espace exige en outre un accès en écriture à son Espace. Créer ou importer un Skill de portée Agent, et modifier les liaisons de Skills d’un Agent, nécessite la permission de gérer l’Agent cible. Personne ne réécrit discrètement la norme de revue un vendredi après-midi.
La maintenance obéit au même principe du lieu unique. Quand un processus change, mettez à jour les instructions et les fichiers de support du Skill, et les exécutions suivantes récupèrent la nouvelle version. La suppression est l’opération qu’il faut aborder avec prudence : elle retire le Skill de tous les Agents qui l’utilisent, alors vérifiez d’abord les liaisons en cours.
Les règles de sécurité sont courtes et non négociables. Ne stockez jamais de mots de passe, de jetons d’accès, de clés privées ou d’autres secrets dans les instructions ou les fichiers de support d’un Skill. Examinez chaque Skill externe ou importé localement avant de l’utiliser. Appliquez le principe du moindre privilège aux commandes et aux exemples. Et revérifiez les liaisons après avoir modifié les associations d’Espace d’un Agent ou le contenu d’un Skill, car l’éligibilité peut changer sous une liaison.
Tout au long de ce processus, le contrat humain-agent tient. Les Agents chargent les Skills, suivent le processus et renvoient les résultats dans la Tâche. Les humains décident quels Skills portent l’autorité de l’équipe. Un Skill relève le niveau plancher de la cohérence. Il ne supprime pas le relecteur.
Quand ne pas créer de Skill
Les Skills sont de l’infrastructure, et l’infrastructure a un coût d’entretien. Le duo de décisions honnête : gardez les exigences ponctuelles dans la description ou les commentaires de la Tâche ; créez un Skill quand la même capacité doit être disponible pour les exécutions futures.
Quelques autres cas où la bonne réponse est : pas de Skill. Si une procédure réside dans le répertoire de Skills d’un Runtime local et que seules les exécutions de cet Ordinateur en ont besoin, laissez-la en local. Si deux Skills candidats se chevauchaient fortement sur le même Agent, fusionnez-les ou affûtez-les avant d’en lier un seul. Et si vous ne parvenez pas à écrire la phrase de description, c’est que le processus n’est pas encore assez stable pour être capturé.
Commencez par une seule procédure
Choisissez une procédure que votre équipe répète et pour laquelle elle dépend discrètement d’une seule personne. Rédigez-la sous forme d’un seul Skill étroit : un nom, une description qui indique quand il s’applique, des instructions qui définissent le processus et le résultat attendu. Donnez-lui la portée de votre Espace. Liez-le à un Agent, confiez à cet Agent une vraie Tâche, et lisez ce qui revient.
Voilà toute la boucle. Le savoir-faire qui vivait dans la tête d’un seul développeur a désormais un nom, une portée, un propriétaire et un seul endroit où le mettre à jour. Si vous découvrez la plateforme, la présentation de Sharkly explique comment les Skills cohabitent avec les Tâches, les Agents et les Ordinateurs, et bien démarrer avec Sharkly déroule la première connexion de bout en bout. La documentation des Skills détaille intégralement chacune des règles ci-dessus.
FAQ
Quelle est la différence entre un Skill et les instructions d’un Agent ?
Les instructions d’un Agent définissent un comportement stable pour un rôle précis : son champ d’action, quand demander une intervention, comment rendre compte. Un Skill est une procédure réutilisable que plusieurs Agents peuvent partager, accompagnée de ses propres fichiers de support et permissions. Si un paragraphe est copié d’un Agent à l’autre, il a sa place dans un Skill.
Peut-on modifier la portée d’un Skill après l’avoir créé ?
Non. La portée d’un Skill est fixée à la création. Si l’audience doit changer, créez un nouveau Skill à la bonne portée et reliez les Agents qui en ont besoin. C’est pourquoi la documentation recommande de choisir dès le départ la portée la plus étroite correspondant à l’audience visée.
Les Skills importés restent-ils synchronisés avec leur source ?
Non. L’installation depuis une source publique prise en charge crée une copie gérée dans la portée de votre choix, et l’import depuis un Runtime local copie le Skill dans l’organisation tandis que la copie locale d’origine reste distincte. À partir de là, votre organisation contrôle sa propre copie.
Lier un nouveau Skill affecte-t-il les Tâches en cours d’un Agent ?
Non. Les modifications apportées aux liaisons de Skills d’un Agent s’appliquent aux exécutions suivantes. Le travail déjà en cours se termine avec la configuration avec laquelle il a commencé, et l’exécution suivante récupère l’ensemble de Skills mis à jour.
Les Skills issus de sources publiques sont-ils sûrs à installer ?
Ils peuvent l’être, à condition de les examiner. Traitez chaque Skill externe ou importé localement comme du code ou de la configuration tiers : lisez les instructions et les fichiers de support avant de le lier, appliquez le moindre privilège aux commandes, et ne laissez jamais de secrets entrer dans un Skill. La validation des téléversements de Sharkly rejette les chemins et les entrées d’archive non sûrs, mais le jugement quant à savoir si des instructions méritent la confiance de votre équipe reste du ressort des humains.
