Arrête de prompter comme un héros : passe aux « skills »

Le vrai différenciateur entre un dev qui rame avec l'IA et un dev qui la fait produire du code propre, en 2026, tient en une phrase : arrête de miser sur le prompt parfait, écris des « skills ». Un skill, c'est un fichier d'instructions réutilisable et spécifique à ton projet — CLAUDE.md, AGENTS.md, une règle Cursor — qui encode les conventions de ton repo, les patterns d'outils et les attentes opérationnelles. Là où le « heroic prompting » (le prompt one-shot génial que tu réécris à chaque session) te fait repayer le même contexte encore et encore, le skill le fige une fois pour toutes et l'agent le recharge automatiquement. Simon Willison et une bonne partie du discours HN 2026 pointent ce basculement comme la compétence qui sépare les seniors qui maîtrisent l'IA des autres. Concrètement : tu passes de « je réexplique mon architecture à chaque conversation » à « mon agent connaît déjà mes conventions, mes commandes de test et mes pièges ». Le reste de cet article te montre quoi mettre dans un fichier de skills, un avant/après réel, et les erreurs à éviter.

C'est quoi un « skill », concrètement ?

Un skill n'est pas un prompt. Un prompt vit et meurt dans une conversation. Un skill est un artefact versionné, committé dans le repo, que l'agent lit automatiquement au début de chaque session ou quand il touche à une zone du code.

Les formats que tu croises aujourd'hui :

• CLAUDE.md à la racine (et par sous-dossier) pour Claude Code.
• AGENTS.md, le format en train de se standardiser entre plusieurs outils.
• Les rules de Cursor (.cursor/rules), scoppées par glob de fichiers.

Le point commun, souligné par Simon Willison et repris dans les fils HN de 2026 : ces fichiers encodent le savoir tacite de ton projet. Pas des astuces générales de prompting — les conventions de ton repo à toi. Comment tu nommes tes migrations, quelle commande lance les tests, pourquoi tel module ne doit jamais importer tel autre. Ce que tu répètes à chaque nouveau collègue humain, tu le figes une fois pour l'agent.

Pourquoi le heroic prompting ne passe pas à l'échelle

Le heroic prompting, c'est le réflexe du dev malin : ouvrir un chat, écrire un prompt de trente lignes qui explique le contexte, l'archi, les contraintes, et obtenir un résultat bluffant. Ça marche. Une fois.

Le problème est mécanique, pas moral :

• Tu repayes le contexte à chaque session. Le même paragraphe sur ton archi, réécrit lundi, puis mercredi, puis par ton collègue qui ne l'a jamais vu.
• Ce n'est pas reproductible. Le prompt génial vit dans ta tête ou dans un onglet. Il n'est ni partagé, ni versionné, ni relu en review.
• Ça ne compose pas. Deux prompts héroïques ne s'additionnent pas ; deux skills, si — l'agent lit le fichier racine plus celui du sous-dossier concerné.
• Ça dérive. Le repo évolue, ton prompt mental non. Un skill committé se met à jour en PR, comme le reste.

Le heroic prompting optimise un coup. Les skills optimisent le taux — chaque session repart d'un socle correct sans que tu ne réexpliques rien.

Critère	Heroic prompting	Skills
Durée de vie	Une conversation	Versionné dans le repo
Partage	Individuel, tacite	Toute l'équipe + l'agent
Reproductibilité	Faible (dépend de ta mémoire)	Élevée (fichier lu à chaque run)
Passage à l'échelle	Linéaire (tu réécris)	Amorti (écrit une fois)
Revue / historique	Aucun	En PR, comme du code

Quoi mettre dans un bon fichier de skills

Un bon skill est court, spécifique et actionnable. Vise le savoir que l'agent ne peut pas déduire seul du code. Les rubriques qui rapportent le plus :

• Commandes opérationnelles : comment build, tester, linter, lancer un seul test. La commande exacte, pas « lance les tests ».
• Conventions du repo : nommage, structure des dossiers, style d'imports, gestion des erreurs maison.
• Frontières d'architecture : « la couche domain n'importe jamais infra », les modules qui ne doivent pas se parler.
• Patterns d'outils : quel client HTTP, quel logger, quelle lib de dates — et lesquels sont bannis.
• Pièges connus : le service flaky, la migration qu'il faut lancer à la main, le champ qui ment sur son nom.
• Attentes opérationnelles : sur quelle branche committer, format des messages de commit, ce qu'on ne pousse jamais.

Deux règles de pro. Une : sois impératif et concret — « utilise pnpm test -- <fichier> pour un seul test » bat « fais attention aux tests ». Deux : ne mets que ce qui est stable et non déductible. Ne recopie pas ton package.json dans le skill ; l'agent sait le lire. Encode ce qui vit dans ta tête, pas ce qui vit déjà dans le repo.

Avant / après : un exemple réel

Avant — tu ouvres un chat et tu tapes, pour la énième fois :

« On est sur un monorepo pnpm, la couche domain ne doit jamais importer infra, on teste avec vitest — pour un seul fichier c'est pnpm test -- chemin. Les dates passent toujours par date-fns, jamais moment. Ne touche pas à legacy/, c'est gelé. »

Dix minutes plus tard, nouvelle session : tu réécris le même pavé. Ton collègue, lui, ne l'écrit pas — il ne le connaît pas — et l'agent lui sort du code qui importe infra depuis domain.

Après — tu écris ça une fois dans CLAUDE.md :

## Build & test
- Monorepo pnpm. Test d'un fichier : `pnpm test -- <chemin>`.
- Runner : vitest. Ne pas ajouter jest.

## Frontières
- `domain/` n'importe JAMAIS `infra/`.
- `legacy/` est gelé : lecture seule, aucune modif.

## Conventions
- Dates : `date-fns` uniquement. `moment` est banni.

À partir de là, chaque session — la tienne, celle de ton collègue, celle du bot de CI — démarre avec ces règles déjà en contexte. Tu n'as rien réécrit. Le prompt du jour redevient ce qu'il aurait toujours dû être : ce que tu veux faire maintenant, pas comment marche le projet.

Les erreurs qui tuent un fichier de skills

• Le roman. Un skill de 800 lignes que personne ne relit devient du bruit. Court et dense.
• Le générique. « Écris du code propre », « suis les bonnes pratiques » : zéro valeur, l'agent le sait déjà. Sois spécifique à ton repo.
• Le périmé. Un skill faux est pire que pas de skill : il fait activement dérailler l'agent. Traite-le comme du code, mets-le à jour en PR.
• Le doublon du code. Recopier des choses que l'agent peut lire (dépendances, types) gonfle le fichier sans rien apporter.
• Le fourre-tout. Tout dans un seul CLAUDE.md racine alors qu'une règle ne concerne qu'un sous-dossier. Scoppe : un fichier par zone quand c'est pertinent.

Par où commencer cette semaine

Tu n'as pas besoin d'un chantier. Ouvre un CLAUDE.md (ou AGENTS.md) à la racine et écris cinq lignes : la commande de test exacte, une frontière d'archi, un piège connu. La prochaine fois que tu te surprends à réexpliquer un truc à l'agent, ne le tape pas dans le chat — colle-le dans le fichier. Le skill grossit par sédimentation, à chaque friction évitée. C'est le geste, discret, qui sépare en 2026 le dev qui prompte comme un héros de celui qui vibecode comme un pro.

FAQ

Un skill, c'est juste un long system prompt ? Non. Un system prompt vit dans une session ; un skill est un fichier versionné, committé, relu en review et rechargé automatiquement à chaque run — par toi, ton équipe et la CI.

CLAUDE.md, AGENTS.md, règles Cursor : je choisis lequel ? Celui que ton outil lit. Beaucoup d'équipes maintiennent le même contenu dans plusieurs formats. AGENTS.md tend à se standardiser entre outils ; commence par celui de ton agent principal et duplique si besoin.

Est-ce que ça remplace complètement le prompting ? Non — ça le nettoie. Les skills portent le comment marche le projet ; ton prompt du jour porte le ce que je veux maintenant. Tu prompteras toujours, mais plus court et plus net.