L’objection, dite avant que tu ne la penses
«Les Skills sont officielles, et ce sont déjà mes fichiers»
Vrai sur toute la ligne, et nous n’allons pas tourner autour. Une Skill est un dossier avec un SKILL.md dedans : deux lignes d’en-tête — un nom et une description — puis du texte. C’est du markdown, c’est à toi, c’est dans git, et si demain tu changes d’avis tu l’emportes. Personne ne t’a enfermé nulle part.
Le mécanisme est bien pensé lui aussi. Tant que la Skill ne sert pas, il ne reste d’elle en mémoire que la description — une centaine de mots ; le corps se charge quand l’IA décide qu’elle est pertinente, et les fichiers d’appui seulement si elle les ouvre vraiment. Cela s’appelle la divulgation progressive, et c’est la bonne façon de donner à une IA cent compétences sans les payer toutes à chaque phrase.
Donc non : cette page n’existe pas pour te dire que les Skills sont mal faites. Elle existe parce que ce mécanisme, qui pour une capacité est une vertu, pour une identité est le défaut.
Le point, c’est quand elle entre dans le contexte
Une Skill entre quand il le faut. C’est toute son élégance : elle ne prend pas de place tant qu’il n’y a pas de raison, et la raison, l’IA la reconnaît en lisant la description. Parfait pour «mettre en page une présentation selon nos règles», qui sert le mardi et pas le jeudi.
Une identité ne fonctionne pas ainsi. Qui tu es n’est pas une compétence qui s’active quand le sujet l’exige : c’est ce qui est déjà là avant que tu n’ouvres la bouche, et qui décide comment tu lis la question. Une chose qui n’apparaît que lorsqu’on l’invoque n’est pas un caractère, c’est un manuel.
C’est la même différence qu’entre savoir cuisiner et avoir faim. La première se sort à l’occasion ; la seconde te meut même quand tu ne penses pas à la nourriture.
Et puis il y a une chose qu’une Skill n’a pas
Dans un SKILL.md il n’existe aucun moyen d’écrire cette partie, tu ne peux pas la réécrire. Ce n’est pas un oubli : une Skill, c’est quelque chose que tu donnes à l’IA pour qu’elle l’utilise, et il n’y a rien à défendre.
Dans un Reminder en revanche, de l’autre côté, il y a quelqu’un qui lit, comprend et pourrait réécrire — et alors chaque bloc déclare à quel point il est à toi : des règles que toi seul peux changer jusqu’aux notes que l’IA met à jour sans demander. C’est la différence entre un manuel et une constitution, et c’est aussi pourquoi le Reminder a une structure au lieu d’être de la prose.
En deux colonnes
| | Une Skill | Un Reminder |
|---|
| À quoi elle répond | comment on fait une chose | qui est celui qui la fait |
| Quand elle entre en contexte | quand l’IA la juge pertinente | toujours, dès la première ligne |
| Ce qu’elle contient | une procédure, des exemples, des scripts | noyaux, modules, mémoires, permissions |
| Qui peut la réécrire | vous, hors de la conversation | selon la zone : c’est déclaré dans le fichier |
| Si vous l’enlevez | l’IA cesse de savoir faire cette chose | l’IA cesse d’être quelqu’un |
| Ce qu’elle retient | rien : demain est pareil qu’aujourd’hui | comment ça s’est passé : dans la mémoire associée du module |
Où ils cohabitent, c’est-à-dire presque toujours
Ce n’est pas l’un ou l’autre, et il ne faut pas en faire un choix exclusif. La division qui fonctionne est nette : les Skills pour les capacités, le Reminder pour l’identité. Même conversation, aucun conflit — parce qu’ils ne se disputent pas la même place.
Avec les agents de code la même division a déjà sa place : le fichier que l’agent lit au démarrage — CLAUDE.md, AGENTS.md — est là où va l’identité, et les Skills restent les procédures que cette identité sait exécuter.
Et la frontière est plus poreuse qu’elle n’en a l’air. Une Skill que tu as déjà se traduit en module, presque ligne à ligne : il n’y a rien à réinventer, parce que les deux formes répondent aux mêmes quatre questions.
- La description : ce qu’elle fait, et quand l’utiliser
→- ### FUNCTION · ### TRIGGER
- Les instructions, les étapes à suivre
→- ### ROUTINE
- Les choses à ne pas faire, les limites
→- ### LIMITI
- Les exemples d’entrée et de sortie
→- ### ESEMPIO
C’est vrai dans l’autre sens aussi, et c’est la partie qui surprend. D’obligatoire, dans un SKILL.md, il y a deux lignes d’en-tête — un nom et une description. En dessous tu es libre : la structure du corps n’est prescrite par personne. Que les Skills s’écrivent en prose libre est une habitude répandue, pas une règle — et les propres recommandations d’Anthropic conseillent des étapes numérotées, des modèles de sortie et des exemples, c’est-à-dire exactement la forme qu’un module a déjà. Sous l’en-tête, cela entre sans réécriture.
Une seule chose ne traverse pas, et il vaut mieux le dire. Dans un module, la ligne qui déclare cette partie, tu ne la réécris pas a sa place, et l’app la fait respecter ; dans un SKILL.md cette ligne n’a nulle part où se tenir, et aucune app n’est dans le circuit pour la défendre — les marqueurs de zone y restent comme du texte, et personne ne les applique. Traduire une capacité fonctionne très bien. Traduire l’identité, non : et c’est tout ce que cette page est en train de dire.
La troisième voie : ne pas la traduire, la greffer
Traduire une Skill en module est une voie. L’autre est de ne pas la traduire du tout. Le corps d’un SKILL.md est du markdown, et un module l’héberge tel quel, sous une ligne qui déclare à qui appartient ce morceau : dans le Standard elle s’appelle ### SUB-MODULE:, et dessous vient le texte entier de la Skill — sa fonction, ses étapes, ses exemples. On ne réécrit rien. On dit à qui c’est, et où c’est.
## MODULE 07: ...
### FUNCTION
### SUB-MODULE: SKILL_A
#### FUNCTION
#### ROUTINE
### SUB-MODULE: SKILL_B
#### FUNCTION
#### ROUTINE
[P4]
### ASSOCIATED MEMORY
[/P4]
Ce que le module ajoute autour, ce sont les deux choses qui n’ont nulle part où tenir dans un SKILL.md. La première est la zone de permission : le texte greffé se retrouve dans un bloc qui déclare qui peut le réécrire, et ce refus, c’est l’app qui le fait, pas le modèle. La seconde est ### ASSOCIATED MEMORY, la section où se dépose ce que vous apprenez en l’utilisant — que ces étapes, chez vous, vont dans un autre ordre ; qu’avec vos fichiers ce passage ne tient pas ; que vous voulez la sortie plus courte. La Skill sait comment on fait. Le module se souvient de comment ça s’est passé.
Et un module en contient plus d’une. Si trois Skills servent le même métier — lire un PDF, en tirer un tableau, en écrire le résumé — vous pouvez les greffer dans le même module, une par ### SUB-MODULE:. À partir de là elles ne s’allument plus une à une : elles entrent en contexte ensemble, quand le module entre, et elles se voient entre elles. C’est votre choix, et c’est le moment où vous cessez de faire de la divulgation progressive.
Le prix est annoncé : vous les payez toutes les trois chaque fois que ce module est actif, y compris le jour où une seule vous servait. Ce que vous achetez, c’est qu’elles cessent de se contredire — une mémoire associée au lieu de trois, une règle écrite une fois au lieu de la même phrase à trois endroits, et aucun travail fait à moitié parce que l’IA en avait chargé une et pas l’autre. Si le métier est un, le module est un. Si les métiers sont trois, gardez-les séparées et laissez-les s’allumer quand il faut : c’est exactement le cas où la Skill toute seule fait son travail mieux que cela.
Une chose se fait à la main aujourd’hui, et il vaut mieux le savoir avant : la greffe est un copier-coller, et à partir de là la copie est la vôtre. Si l’auteur de la Skill publie une nouvelle version, c’est vous qui décidez de la faire entrer — le texte est là, en clair, dans votre fichier, et il se met à jour comme se met à jour un fichier. C’est le même pacte que pour le reste : rien ne bouge sous vous sans que vous le voyiez.
En une ligne
Une Skill est une chose que ton IA sait faire. Un Reminder est qui elle est pendant qu’elle la fait. Garde les deux : ils ne se marchent pas dessus, parce qu’ils ne sont pas au même endroit.