Un Skill n'est pas une librairie

Controversial opinion : je ne pense pas que partager des skills agentiques dans une logique de mutualisation soit une bonne idée.

Je précise tout de suite, parce que la nuance va se perdre en trois secondes sinon : je ne dis pas qu'il ne faut pas partager ses skills.
Je dis que partager n'est pas mutualiser, et qu'on est en train de confondre les deux.

Et le titre de ce billet n'est pas juste une formule.
Aujourd'hui, on distribue et on consomme des skills exactement comme on le ferait avec des librairies : des marketplaces et des registries qui les référencent (skills.sh, ccm-skills, APM etc..), des CLIs pour les installer et les mettre à jour, des métadonnées, des stats de téléchargement, et même des audits Snyk pour évaluer leur sécurité.

Toute la tuyauterie autour dit la même chose : traitez ces objets comme des dépendances.

Le problème, c'est que la tuyauterie induit le mode d'usage.
Quand quelque chose s'installe comme une librairie, on l'utilise comme une librairie - on attend une roadmap, des release notes, une rétrocompatibilité, un mainteneur…
Or un skill ne peut à peu près rien tenir de tout ça, pour des raisons qui n'ont rien à voir avec la maturité de l'écosystème et tout à voir avec la nature de l'objet.

C'est cette confusion-là que je veux défaire.

Un réflexe vieux comme l'informatique

Factoriser, ce n'est pas une mode récente.
C'est probablement l'un des gestes les plus fondamentaux dans ce métier, présent depuis les toutes premières sous-routines.
Extraire, nommer, réutiliser : c'est la base.

D'ailleurs, on factorise rarement dès la première duplication. La règle empirique la plus répandue, c'est plutôt d'attendre la troisième occurrence avant d'extraire quoi que ce soit, précisément parce qu'avec deux exemplaires on n'a pas encore assez de recul pour savoir ce qui est réellement commun.

Mais une fois ce seuil franchi, le pipeline mental s'enclenche tout seul :

duplication → factorisation → abstraction → composant partagé → maintenance commune

Ce pipeline a fait ses preuves sur du code. Il est aujourd'hui appliqué tel quel aux skills.
... et je pense qu'il s'y applique mal.

Écrire un skill coûte peu. Se l'approprier coûte cher.

La barrière à l'entrée pour écrire un skill est ridiculement basse : tu brainstormes avec Claude pendant dix minutes pour sortir le premier jet. Puis tu itères pendant une vingtaine de minutes pour combler les trous dans la raquette. Le coût reste marginal, et le ROI est presque immédiat dès lors que tu es amené à l'utiliser 4 ou 5 fois.

Le calcul change complètement quand il ne s’agit plus d’écrire un skill, mais d’en récupérer un.
Là, deux usages qu’on confond en permanence coexistent :

Utiliser le skill de quelqu'un d'autre : coût quasi nul, et c'est toute la promesse - tu l'installes, ça marche, tu n'es pas rentré dedans profondément et ce n'est pas grave.
Se l'approprier : pouvoir décider si tu acceptes sa v2, arbitrer un désaccord, l'étendre sans le casser.

La mutualisation exige le deuxième, pas le premier. Tant que tu consommes, tu peux rester ignorant.
Dès que tu co-maintiens, il faut reconstituer les choix implicites, les exceptions, les garde-fous, les compromis, et surtout le contexte de conception.
Ce contexte n'est presque jamais écrit : il est dans la tête des auteurs, perdu dans la discussion que ces derniers ont eu avec leur LLM favori.
Pire : tu n'as aucun moyen de distinguer un skill affiné pendant des semaines, voire des mois, d'un skill sorti d'un prompt d'une phrase via Sonnet.

Bref, le calcul est vite fait : forker est souvent plus rapide que converger. Tu fais l'inverse de ce que tu ferais avec du code, et c'est normal, parce que l'économie n'est pas la même.

Le contexte n'est pas un détail, c'est la substance

Un skill taillé pour un projet, une équipe, une manière de bosser, devra presque toujours être modifié ailleurs. Ce n'est pas un défaut de conception : c'est exactement ce qui le rend bon là où il a été écrit.

Et je préfère très souvent un skill simple qui fit parfaitement avec mon cas d'usage (à la Unix) à un skill générique capable de gérer dix scénarios exceptionnels dont je n'ai pas besoin.
Cette généricité a un coût d’autant plus important avec les LLM : elle dilue les instructions, elle allonge le contexte, elle noie le cas nominal dans des branches mortes.

Le skill générique n'est pas la version supérieure du skill spécifique. C'est un autre objet, avec d'autres compromis, généralement moins bons pour mon besoin spécifique.

Une v2 de skill, c'est un pari mal outillé

Sur du code, une régression se détecte. Sur un skill, non.

En améliorant un comportement : qu'est-ce qui te dit que tu n'en as pas dégradé 3 autres, silencieusement ?

Il n'y a pas de suite de tests qui tombe au rouge. Il y a juste un agent qui, dans deux semaines, prendra une décision légèrement à côté sans que personne ne comprenne pourquoi.

Sur une librairie, tu as une release note. Tu la parcours en deux minutes et tu sais ce que tu gagnes à migrer, ce qui casse, ce qui est déprécié. C'est factuel et vérifiable.

Sur un skill, la release note serait purement subjective. Une ligne du type “meilleure gestion des cas ambigus” ne te dit rien : meilleure selon qui ? mesurée comment ? sur quel corpus ?
Tu n'as aucun moyen de décider si tu dois migrer, à part relire le diff en entier et te reforger ton propre avis. Ce qui te ramène au coût d'appropriation du point précédent.

Et le pire n'est même pas là. 
Le pire, c'est que ce qui est une feature pour moi est parfaitement susceptible d'être un bug pour toi. 
Sur une dépendance partagée, ça se règle avec une issue et un flag de configuration.
Sur un skill, ça se règle en ajoutant une exception, puis une deuxième, puis en transformant un texte clair en arbre de décision illisible.

Les outils commencent à exister, mais ils déplacent le problème

Il faut être honnête : évaluer un prompt n'est plus le désert méthodologique d'il y a un an.

Des outils comme skill-creator d’Anthropic, permettent aujourd'hui de lancer des évaluations pour un skill (jeux de cas, mesure de variance, benchmark de la description pour améliorer son déclenchement).
Faire tourner un skill N fois sur un corpus de cas et mesurer la variance, ça se fait techniquement.
Mais constituer ce corpus, le maintenir, le rejouer à chaque évolution : c'est un investissement qui n'a plus rien à voir avec l'idée de départ.

Un skill, c'est censé rester quelque chose de simple qu'on écrit en trente minutes ; si on doit s'outiller comme pour un produit pour valider ses évolutions, on passe sur un autre braquet.
Le coût d'écriture et de maintenance d'une bonne suite d'evals dépasse presque toujours le coût de réécriture du skill lui-même.
On outille la mutualisation en la rendant plus chère.

Le vrai levier : faire compound le skill sur son propre usage

La pratique qui a le plus payé pour moi n'est pas d'écrire des evals, c'est d'instrumenter la plupart de mes skills pour qu'ils s'auto-évaluent à chaque fin d'exécution : qu'est-ce qui a manqué ? qu'est-ce qui a été deviné ? quelle instruction aurait dû être plus explicite ?
Cette auto-évaluation doit se faire de manière “meta”, dans une discussion qui analyse la discussion (Conductor est très bien pour ça, car il permet très facilement de référencer une discussion)

À chaque cas d'usage réel, le skill produit ses propres axes d'amélioration, que je réintègre (si pertinent) à la version suivante. Le skill ne devient pas un artefact figé qu'on partage ; il devient un artefact vivant, calé sur mes usages qui me sont propres.
Ce qui, incidemment, le rend encore moins partageable - et c'est très bien comme ça !

Et par-dessus tout ça, les skills vieillissent

Les modèles progressent vite. Beaucoup de skills existent uniquement pour compenser une faiblesse d'un modèle à un instant T.
Six mois plus tard, cette faiblesse a disparu, et le skill est devenu au mieux inutile, au pire contre-productif : il contraint explicitement un modèle qui savait très bien faire implicitement.

L'exemple le plus parlant, ce sont les bonnes pratiques de développement d'un langage.
Il y a 1 an, on avait envie de les expliciter pour cadrer le modèle.
Mais les vendors entraînent leurs modèles sur les usages réels, en continu.
Mécaniquement, ces modèles convergent d'eux-mêmes vers les pratiques les plus couramment attendues.

Typiquement, ton skill de conventions TypeScript écrit en septembre 2025 a toutes les chances d'être un boulet en 2027 (spoiler alert, il l’est même sûrement en 2026 depuis Sonnet 4.5 et Opus).
Sans même parler du fait qu'il n'intégrera sûrement pas les nouveautés apparues entre-temps, en 2026 (tu as l'idée).

Ce vieillissement frappe aussi mon fork perso, évidemment. Il ne départage donc pas la duplication de la mutualisation.
Ce qu'il fait vraiment apparaître, c'est autre chose :

Un skill est plus souvent un consommable qu'un actif.
La bonne question n'est pas "comment je le maintiens à plusieurs", c'est "à quelle occasion je le jette" (sous-entendu : comment puis-je détecter qu'il devient du slop pour l'agent ?).

Selfware : le contrat que personne n'a signé

Finalement, un skill c'est à peu près la différence entre un projet OSS pensé dès le départ comme un produit générique, et du selfware : un truc construit d'abord pour soi, qu'on décide ensuite de rendre public.

Le selfware peut être extrêmement utile aux autres. Il n'a simplement aucune vocation à répondre aux besoins de tout le monde. Personne n'attend de lui une roadmap, une rétrocompatibilité, une gouvernance.

Et pourtant, dès qu'un skill devient un asset partagé, il y a un ownership associé, dédié à le faire vivre.
Le mettre à jour quand un modèle ou un besoin change. Arbitrer entre deux besoins contradictoires. Comment est géré cet ownership concrètement ? Sur quel budget ? Avec quel temps alloué ?

La plupart d'entre nous ont déjà vécu ça avec les librairies internes.
C'est toujours la même trajectoire : une personne motivée la crée, elle est adoptée, puis la personne part sur d’autres sujets, elle quitte le projet qui l’utilise, voire l'entreprise.
Sauf cas exceptionnels, il arrive fatalement un moment où il n'y a plus de bande passante pour la maintenir.
Les tickets s'accumulent. Le budget de maintenance n'a jamais existé sur aucune ligne. Et la lib devient stale : encore installée partout, mais plus personne n'ose ni ne veut y toucher.

Un skill mutualisé suit exactement le même chemin, en plus rapide, parce que la barrière à la contribution est très faible ET son environnement (les modèles) bouge beaucoup plus vite que celui d'une librairie.
Sauf qu'un skill obsolète ne casse pas bruyamment le build.
Il dégrade doucement la qualité de ce que produit l'agent, et personne ne fait le lien.

La majorité des skills relèvent du selfware. Les traiter comme des librairies OSS, c'est leur imposer un contrat qu'ils n'ont jamais signé.
La bonne question n'est pas de savoir qui maintient ce skill, mais qui se l'est approprié et pourra mesurer son efficience dans le temps.

Quand le skill devient long, ce n'est peut-être plus un skill

Un skill qui décrit un processus en quinze étapes est un objet intéressant.
C'est même l'un des cas où lire celui d'un autre a le plus de valeur : tu comprends son workflow, pas juste son résultat.

Mais je ne suis pas convaincu que le format skill soit le bon réceptacle à ce besoin.
Plus un skill est long, plus il est exposé au context rot : le modèle dérive, perd son objectif initial, applique 15 % du temps l'étape 12 en ayant oublié la contrainte posée à l'étape 3.

À ce niveau de complexité, la vraie question n'est plus de savoir comment le mutualiser, mais plutôt s'il ne devrait pas devenir un workflow davantage déterministe.
Je te partage ci-dessous les quelques signaux assez nets qui me font dire que tu es en train d’écrire du code dans le pire des langages de programmation possible (l’anglais/le français) :

• Tu numérotes les étapes. Une numérotation, c'est un aveu : tu veux un ordre garanti. Un prompt ne garantit pas un ordre, un script si.
• Tu écris "ne surtout pas oublier de...". Chaque rappel défensif est un test unitaire déguisé - le genre de chose qu'un hook forcerait à passer, plutôt que de compter sur le modèle pour s'en souvenir au bon moment.
  Les hooks sont d'ailleurs à peu près le seul moyen d'injecter du déterministe au milieu d'une discussion : quand tu en écris 3 dans le même skill, tu ne fais plus que ceinturer une prose qui ne tient pas debout toute seule.
• Ton skill contient des branches conditionnelles imbriquées : si... sauf si... mais dans ce cas....
• Tu relances deux fois pour avoir un résultat correct. 
  Le non-déterminisme n'est plus une souplesse, c'est un défaut.

La frontière que j'utilise pour ranger tout ça est simple :

Ce qui relève du jugement reste dans le prompt ; ce qui relève de l'enchaînement sort dans le harnais (ou un workflow scripté).

Le prompt, c'est ce qui gagne à rester en texte : parce que c'est plus rapide à écrire que du code, plus facile à ajuster, et surtout parce que ça laisse une vraie flexibilité au modèle.
On y met naturellement tout ce qui relève du jugement - décider si une remarque est ambiguë, choisir un ton, arbitrer un compromis entre deux contraintes qui se contredisent - précisément parce qu'un modèle est là pour ça : appliquer une intuition floue à un cas nouveau, sans qu'on ait besoin d'anticiper tous les cas.
C'est aussi une question de barrière à l'entrée : décrire textuellement ce qu'on veut coûte dix fois moins cher que de le coder, tant qu'on accepte le prix de cette souplesse.

Le harnais, c'est ce qui doit sortir du texte dès que la souplesse devient un défaut : appeler tel outil avant tel autre, vérifier qu'une étape a bien produit son artefact (un rapport de tests passants) avant de passer à la suivante, boucler jusqu'à ce qu'un critère soit atteint, s'arrêter proprement quand une étape échoue.
Ça se code dans un workflow, un script, un hook - quelque chose qui garantit ce que le prompt ne peut que suggérer.
Le curseur entre les deux n'est pas moral, il est économique : tant que le texte suffit et que tu peux vivre avec le non-déterminisme, tu restes dans un prompt ; le jour où tu ne peux plus, tu paies le coût du code, et tu récupères ce qu'il apporte.

Ce n'était pas le skill qui était mutualisable, c'était le workflow qui dormait dedans.

La foire aux skills sur étagère

Autre effet de bord, très concret dans les grandes organisations : passé un certain volume, plus personne ne s'y retrouve.

Des dizaines de skills disponibles, avec des noms qui se ressemblent, des périmètres qui se recouvrent à moitié, trois versions du même besoin écrites par trois équipes.

Je n'ai pas de cas vécu à cette échelle.

Mais quand j'écoute les équipes de Doctolib parler de leur adoption des agents IA, ils évoquent une gouvernance qui porte sur 3000 agents (et donc implicitement, de skills/prompts associés) 🤯.
On parle d'un objet dont l'argument de vente est qu'on l'écrit en trente minutes - et à ce volume, produire n'est plus la question, tout le travail est passé côté gouvernance.

Trouver le bon skill devient un travail en soi. Et savoir s'il est encore à jour, un pari.

On finit par industrialiser la mutualisation d'un objet qui coûtait moins cher à réécrire qu'à référencer.

Quand la théorie rencontre ma pratique

Tout ce qui précède est plus intéressant si je le confronte à ce que je fais vraiment.
Deux exemples, qui vont dans deux directions opposées - c’est de cette contradiction qu’a émergé ma grille de lecture.

Premier cas : la revue de code. 

Sur ce sujet, j'ai lu moi-même un nombre important (une dizaine) de skills existants.
Je n'en ai adopté aucun, et je n'ai forké aucun d'entre eux.
J'ai fini par écrire le mien, en gardant les trois idées que je trouvais bonnes, glanées ici et là :

• un council de subagents spécialisés qui reviewent en parallèle avec des angles différents, plutôt qu'une passe unique qui essaie de tout voir ;
• un ancrage dans les rules du projet, pour que la revue parle des conventions réelles (et que la source de vérité soit dans la rule, plutôt que dans le skill) ;
• une classification par criticité, parce que le vrai coût d'une revue automatique n'est pas de la produire mais de la relire - et relire vingt remarques cosmétiques pour en trouver une pertinente, c'est clairement une perte de temps !

Le coût réel était dans la lecture, pas dans l'écriture.
Et ce que j'en ai retiré, ce n'est pas du texte, c'est trois idées.

Aucun des skills que j'ai lus n'est installé chez moi, et pourtant, tous m’ont servi (à leur niveau). 
C'est exactement le modèle "partage → appropriation → réécriture" : pas de fork, pas de dépendance, mais une vraie reconnaissance intellectuelle envers leurs auteurs.

Deuxième cas : le design d'interface. 

J'utilise impeccable sans y toucher, et je le recommande : il produit des UIs qui sortent de l'ordinaire, et que je trouve plus jolies que ce que Claude me génère par défaut.
C'est probablement le skill que j'ai le moins envie de réécrire - sauf qu'il ne rentre dans aucune des cases que je viens de défendre.
Il embarque le “goût” (au sens artistique du terme) de ses auteurs, pas une norme extérieure ; je ne le maintiens pas ; je ne participe pas à ses évolutions.
Selon ma propre logique, je devrais le dupliquer et le spécialiser.

Je ne le fais pas. Et c’est pour une raison très naturelle.

Une question de sphère

Ce qui fait qu'un skill se duplique ou se réutilise tel quel, ce n'est pas sa qualité intrinsèque : c'est la distance entre la sphère où il est né et la sphère où il est consommé.

• Sphère personnelle : contexte réduit à une seule tête : la mienne.
  Ce sont les skills les plus opinionated que j'ai, ceux qui encodent mes préférences, ma façon de commit, de review, d’écrire du texte ou d’interagir avec mon LLM.
  Aucune vocation à être partagés, parce que le contexte n'est littéralement transmissible à personne. En revanche, j'ai besoin qu'ils me suivent : d'une machine à l'autre, quand j'en change ; d'un environnement local à un environnement remote (une exécution d'agent via Hermes, Openclaw, un container éphémère, un devcontainer).
  Donc besoin de versioning et de portabilité, sans besoin de publication. Un dépôt privé, un dotfiles-like synchronisé, une CLI qui les pousse dans ~/.claude/skills à la connexion - le vecteur importe peu tant que la distribution reste à sens unique et à destinataire unique.
• Sphère projet / équipe : contexte fort, partagé, versionné avec le code.
  Le skill est un artefact d'équipe, sa mutualisation est légitime parce que la maintenance est de facto collective. Les conventions, les outils, les contraintes métier sont réellement communs.
  À cette échelle, un skill devient un support de consensus : un endroit où l'équipe formalise les choix qu'elle a arbitrés ensemble, plutôt qu'un artefact à consommer aveuglément.
  Le contexte de conception se transmet à l'oral, les désaccords se règlent en face à face, et une régression silencieuse se détecte plus vite à cinq qu'à un.
• Sphère outil : un skill livré avec le produit qu'il pilote (Docker, un ORM, un CLI interne).
  Le contexte est celui de l'outil, pas du consommateur. La mutualisation est portée par l'éditeur, pas par la communauté : c'est lui qui connaît son outil, qui suit ses évolutions, qui a une raison structurelle de maintenir.
  Le contrat de maintenance existe vraiment, parce qu'il coïncide avec la vie du produit.
• Sphère marketplace / globale : aucun contexte partagé.
  Ici la duplication devient le mode par défaut, et le partage n'a de valeur que comme véhicule d'idées.

Cette grille, ça n'est pas juste une nouvelle typologie : ça résout la contradiction du deuxième cas évoqué précédemment.
Et ces quatre sphères ne sont pas des cases hermétiques : un skill peut migrer de l'une à l'autre (typiquement : une astuce personnelle qui, une fois éprouvée, se généralise à l'équipe).
Cela pose toutefois des questions d’overlap lorsqu’un skill personnel est susceptible de se déclencher sur les mêmes événements que les skills projet.

impeccable ne contredit pas la thèse : il opère dans une sphère où je n'ai pas d'avis, donc où je n'ai rien à spécialiser.
Le jour où je me serai fait un avis, je dupliquerai le skill.
En attendant, importer le goût de quelqu'un d'autre - particulièrement quand l'auteur est reconnu pour ses opinions solides - est le meilleur deal possible.

Sur la revue de code à l'inverse, j'ai des opinions solides : dupliquer et diverger a de la valeur, parce que la divergence va quelque part.
Sur le design d'interface, je n'en ai pas, et "diverger" signifierait juste dégrader vers ma propre médiocrité esthétique.

D'où la règle que je m'applique, et que je te propose : tu peux prendre un skill tel quel quand tu n'as pas de préférence - à condition d'assumer que tu ne le maintiendras jamais, et de le jeter le jour où tu développes un avis sur la question.

Donc : duplique, sans culpabiliser

Prendre un skill.
Le copier.
Supprimer ce qui ne te concerne pas.
Ajouter tes propres contraintes. 
Le faire diverger. 
Et ne pas chercher ensuite à refaire converger les versions.

Le modèle mental que je défends n'est pas celui du composant partagé. C'est plutôt :

partage → appropriation → duplication → spécialisation → divergence

Et cette divergence n'est pas l'échec du partage. C'est son résultat souhaitable.

Le partage, pour quoi faire alors ?

Si mutualiser est illusoire dans la sphère globale et que dupliquer devient la règle, à quoi sert-il encore de publier ?

À onboarder les gens qui découvrent les agents IA.

Avoir des skills sur étagère est probablement le meilleur moyen de comprendre rapidement ce qui est possible. Ils rendent concrets des usages qu'on n'aurait pas imaginés et ils montrent comment d'autres structurent leurs interactions avec un modèle.

Quand tu ne connais pas encore le champ des possibles, un catalogue vaut mille explications.

Et surtout, à donner des idées

Le vrai objet du partage n'est pas le fichier, c'est l'idée qu'il transporte.

Découvrir qu'on peut déléguer telle tâche, cadrer tel raisonnement, automatiser tel enchaînement auquel on n'avait pas pensé.
Cette idée-là, tu la gardes même après avoir jeté le skill qui te l'a fait découvrir.

Quand je publie un skill, mon objectif n'est pas que ma façon de faire soit adoptée.
Ce n'est pas un standard que je propose, ni un composant que j'espère voir installé partout.
Ce que j'ouvre, c'est une fenêtre sur la manière dont j'ai appréhendé un problème : ce que j'ai considéré comme important, ce que j'ai décidé d'ignorer, les compromis que j'ai acceptés.

Si tu lis ça et que tu en tires une meilleure version pour toi, y compris en jetant 80 % de ce que j'avais écrit, alors le partage a parfaitement fonctionné.

Ce que ça change pour moi

Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime !

Cet adage est bien connu.
Un skill partagé, ce n’est pas un poisson qu’on te sert : c’est quelqu’un qui pêche devant toi.
À toi de prendre la canne ensuite et d’écrire le tien.

Je m’inscris quand même en faux sur un point: donner du poisson peut avoir une utilité réelle.
Ça permet par exemple de découvrir très vite qu'on n'aime pas le poisson, sans avoir passé des après-midi à apprendre à pêcher.
C'est exactement la valeur du skill sur étagère pour quelqu'un qui débute.

Mais sur la durée, je préfère largement demander aux gens d’apprendre à pêcher (particulièrement quand l’investissement de cet apprentissage est faible).

Concrètement, ça veut dire arrêter de raisonner en catalogue et commencer à raisonner en sphères.
Avant de publier un skill, se demander : dans quelle sphère est-ce qu'il vit ?
Avant d'en installer un, se demander : dans quelle sphère est-il né, et est-ce que je vais l'habiter ou juste passer ?

Le partage reste précieux, mais son unité de valeur n'est pas le fichier qu'on installe.
C'est l'idée qu'on emporte, le pattern qu'on reconnaît, la contrainte qu'on n'avait pas vue.
Le succès d'un skill ne se mesure pas au nombre d'installations.
Un skill bien partagé, ce n'est pas un skill installé partout : c'est un skill qui a fait réfléchir, puis qu'on a réécrit à sa main.

Un bon skill n'est peut-être pas celui qu'on réutilise tel quel, mais celui qu'on a envie de réécrire après se l'être approprié.
Et si on a envie de le jeter six mois plus tard, tant mieux. Ça veut dire que le contexte a bougé, et qu'on a nous-même bougé avec.