Pourquoi les agents de code IA ont-ils besoin de Skills ?

Le « maintenant » du titre n'est pas un argument marketing. Entre 2025 et 2026, Cursor, Claude Code, Codex, Gemini CLI et d'autres produits ont progressivement adopté la même convention de répertoire Skills. La communauté voit émerger des packages installables : certains gèrent les réponses ADHD-friendly, d'autres couvrent 39 types de schémas éditoriaux. Point commun — la connaissance procédurale quitte l'historique de chat pour entrer dans le dépôt.

Pourquoi « avoir besoin » de Skills maintenant ?

Les premiers Coding Agents fonctionnaient simplement : prompt système plus longue instruction collée par l'utilisateur. Cela suffit pour une personne et des tâches courtes. Dès qu'une équipe grandit, trois problèmes deviennent durs :

• Budget de contexte. Les étapes de déploiement, le système de design, les contrôles de sécurité, les conventions de commit ne peuvent pas être injectés en totalité à chaque tour.
• Précision du déclenchement. Les règles de diagramme ne sont nécessaires que lors du dessin d'une architecture ; corriger un typo ne devrait pas charger 40 types de diagrammes.
• Portabilité. Le même manuel doit fonctionner dans Cursor Desktop, le terminal Claude Code, Codex et même des agents maison — sans être lié au format Rules propriétaire d'un seul éditeur.

Les Skills répondent aux trois points simultanément : une description courte sert de clé de routage ; le texte complet et references/ se déploient à la demande ; la structure du dossier suit un standard ouvert — le dossier lui-même est le livrable.

Qu'est-ce qu'un Skill : dossier + SKILL.md

Selon agentskills.io et la documentation Cursor, un Skill est au minimum :

my-skill/
  SKILL.md          # Obligatoire : frontmatter YAML + étapes Markdown
  references/       # Optionnel : longs documents, lus à l'exécution
  scripts/          # Optionnel : scripts exécutables, la sortie entre dans le contexte
  assets/           # Optionnel : gabarits, exemples de schémas

Le frontmatter en tête de SKILL.md est un contrat de routage, pas une décoration :

---
name: my-skill
description: Ce que fait ce Skill. Dans quelles tâches l'utiliser.
disable-model-invocation: false
---

# Étapes
...

Les chemins de découverte varient selon le produit, mais la convention converge : niveau projet souvent .cursor/skills/ ou .agents/skills/ ; niveau utilisateur global souvent ~/.cursor/skills/. Les répertoires imbriqués (p. ex. apps/web/.cursor/skills/) peuvent automatiquement restreindre la portée du Skill à un sous-arbre.

Trois niveaux de chargement : Découverte → Activation → À la demande

C'est la différence fondamentale avec « tout écrire dans les Rules ».

1. Découverte (Discovery) : Au démarrage de la session, l'agent ne voit que le name + description de chaque Skill.
2. Activation : Quand la description de la tâche correspond, ou que l'utilisateur tape /skill-name / @skill-name, le texte complet de SKILL.md est chargé.
3. À la demande (On demand) : En cours d'exécution, references/ est lu et scripts/ est lancé ; la sortie des scripts entre dans le contexte, le code source n'est généralement pas injecté entièrement.

Une description mal écrite équivaut à un routage cassé. Une bonne description répond simultanément à deux questions : que fait ce Skill, et à quel signal faut-il l'utiliser.

Exemple 1 : i-have-adhd – la forme de sortie est aussi une compétence

ayghri/i-have-adhd est un Skill délibérément étroit : il n'apprend pas à l'agent comment écrire du code, il règle uniquement « comment il parle ». Sa description précise : prochaine action d'abord, numérotation multi-étapes, rappel d'état à chaque tour, suppression des digressions, estimation de temps concrète, tâches accomplies visibles. Par défaut disable-model-invocation: true – activé par /i-have-adhd jusqu'à l'arrêt explicite.

Parmi ses dix règles, celles particulièrement utiles pour les Coding Agents :

• Écrire la prochaine action d'abord, pas de phrase d'introduction.
• Les tâches multi-étapes doivent être numérotées ; maximum d'environ 5 entrées par liste.
• Rappeler l'état actuel à chaque tour pour réduire le « où en étais-je ? ».
• Formuler les erreurs de façon factuelle, sans accumulation d'excuses.

Cela prouve une chose : les Skills ne servent pas seulement les « manuels d'experts du domaine », mais aussi les « contrats d'interaction ». Dès que la forme de sortie peut être versionnée, une équipe peut partager un mode de conversation à faible friction — sans que chacun réécrive son propre prompt système.

Exemple 2 : diagram-design – les manuels de domaine ne rentrent pas dans les Rules

cathrynlavery/diagram-design va à l'opposé : près de 40 types de schémas éditoriaux (architecture, séquence, machine à états, ER, Sankey, Wardley…), sortie en HTML/SVG autonome, refus explicite du « Mermaid bâclé ». Il exige aussi de vérifier les tokens de marque avant le premier schéma, puis de charger depuis references/ la syntaxe de mise en page et les modèles sémantiques selon le type.

Si on écrit ce manuel entièrement dans les Always-on Rules :

• Les sessions qui corrigent un simple typo dans un README portent toutes les règles de diagramme ;
• Les coûts en tokens augmentent, le contexte pertinent du dépôt est évincé ;
• À chaque nouveau type de diagramme, le fichier Rules devient un monolithe impossible à maintenir.

En tant que Skill : au démarrage, seule la longue description est enregistrée (liste des types et conditions de déclenchement) ; l'activation n'intervient que si l'utilisateur dit « dessine un diagramme de déploiement » ; les références de mise en page spécifiques au type sont lues à la demande. C'est la preuve technique de « les agents commencent à avoir besoin de Skills » — non pas parce qu'ils ne savent pas dessiner des diagrammes, mais parce que la connaissance pour faire de bons diagrammes dépasse depuis longtemps le volume raisonnable d'un prompt permanent.

Skills vs. Rules vs. MCP

Les trois sont souvent combinés : une Rule interdit « ne jamais committer de clé » ; un Skill impose « vérifier ces 8 points avant une mise en production » ; MCP fournit l'outil « créer une GitHub Release ». Le Skill ne remplace pas le Schema — il indique seulement à l'agent quand et dans quel ordre le remplir.

De deux Skills à l'écosystème agentskills.io

i-have-adhd et diagram-design représentent deux pôles : contrat d'interaction vs profondeur de domaine. Entre les deux, une chaîne de distribution complète est déjà en place :

• Standard ouvert. agentskills.io définit le frontmatter, le corps et les chemins de découverte ; plusieurs produits agents implémentent la même convention de dossier.
• Éditeur et CLI. Cursor scanne le répertoire skills au démarrage ; Claude Code, Codex, Gemini CLI, OpenCode et d'autres proposent des plugins ou des conventions de répertoire.
• Installeurs. La communauté voit apparaître des outils comme npx skills add …, des marketplaces de plugins et des outils de type skilldrop qui transforment les dépôts Git en packages installables.
• Combinaison. Les Skills de discipline (commit, review, reprise après échec) et les Skills du cycle de vie engineering (spec, test, release) commencent à se référencer mutuellement via Pair with.

La maturité de l'écosystème ne se mesure pas au « nombre de Skills », mais au fait que : le même dossier peut être découvert, routé et chargé progressivement par différentes runtimes, sans avoir à réécrire un prompt pour chaque produit.

La couche contrat : description, frontmatter et JSON

Pour les lecteurs de ce site, les Skills et la Structured Output sont la même intuition d'ingénierie : définir l'interface proprement d'abord, laisser le modèle remplir ensuite.

1. Frontmatter est le contrat de découverte lisible par machine (YAML — des champs structurés en essence).
2. description est la version en langage naturel d'un Schema de routage : un raté équivaut à choisir le mauvais outil.
3. Si un Skill pilote MCP / Function Calling, les entrées et sorties doivent toujours être en JSON Schema ; le corps du Skill n'écrit que les étapes et critères d'acceptation — les types de champs n'appartiennent pas au texte courant.

Un exemple de « métadonnées de Skill » validables (schématique, pas un Schema officiellement imposé) :

{
  "name": "diagram-design",
  "description": "Create branded architecture and flowchart diagrams as standalone HTML/SVG.",
  "disable_model_invocation": false,
  "triggers": ["architecture diagram", "sequence diagram", "draw.io redraw"],
  "loads": ["SKILL.md", "references/style-guide.md"]
}

Cet objet peut être converti en Schema avec les outils de ce site — puis décider quels champs vont dans le frontmatter, lesquels dans le corps. Le « catalogue de Skills » côté agent finira par ressembler à un catalogue d'outils : description courte permanente, long manuel à la demande.

Comment écrire, installer et déclencher

1. Créer .cursor/skills/votre-skill/SKILL.md (partage d'équipe) ou ~/.cursor/skills/… (global personnel).
2. Remplir soigneusement name + description ; la description doit décrire à la fois la capacité et la condition de déclenchement.
3. Garder le corps court : étapes, anti-patterns, conditions d'arrêt. Mettre les longs tableaux dans references/ avec des liens relatifs.
4. Pour les flux destructeurs ou sensibles à la facturation, mettre disable-model-invocation: true pour forcer la commande slash.
5. Committer dans Git. Redémarrer / recharger l'agent pour que la couche de découverte rescanne.
6. Déclencher : la correspondance de description route automatiquement, ou taper /votre-skill / @votre-skill dans le chat.

Si vous avez déjà des Rules ou des commandes slash, vous pouvez d'abord les migrer en Skills, puis supprimer les prompts permanents redondants — vérifiez en lançant une tâche sans rapport : l'ancien manuel ne devrait plus apparaître dans le contexte.

Recetter dans la Boîte à outils JSON

1. Coller les métadonnées du Skill ou un exemple d'entrée d'outil dans le formatage JSON — vérifier d'abord que ça parse.
2. Avec JSON → Schema ou Structured Output, générer un contrat de validation.
3. Si le Skill appelle MCP / Function Calling, utiliser respectivement MCP Tool et Function Calling — ne pas définir les mêmes champs deux fois.
4. Passer un second vrai résultat dans la validation Schema ; en cas d'écart, utiliser la comparaison JSON.

Tout est traité dans le navigateur, rien n'est envoyé au serveur.

FAQ

Quelle différence entre un Agent Skill et une Cursor Rule ?

Les Rules sont plus permanentes ; les Skills n'exposent par défaut que l'index et ne chargent qu'après correspondance. Les Skills sont aussi plus facilement réutilisables d'un produit à l'autre avec le même dossier.

Que fait concrètement le Skill i-have-adhd ?

Il contraint la forme de sortie : prochaine action d'abord, étapes numérotées, rappel d'état, suppression des digressions, estimation de temps, listes courtes. Habituellement activé explicitement par /i-have-adhd.

Pourquoi diagram-design prouve-t-il qu'on a besoin de Skills ?

Près de 40 types de schémas plus des références de marque et sémantiques — le volume dépasse largement toute Rule permanente raisonnable. Le chargement progressif ne le déploie que lors des tâches de dessin.

Skills et MCP / Function Calling, c'est la même chose ?

Non. Un Skill est un manuel ; MCP / Function sont des outils. Les outils ont toujours besoin d'un JSON Schema ; un Skill précise quand et dans quel ordre les appeler.

Comment ajouter un Skill à un projet ?

Placer un SKILL.md dans le répertoire skills, remplir name / description et les étapes, committer dans le dépôt et recharger l'agent. Les flux sensibles peuvent être limités au déclenchement slash.

En résumé

Les agents de code IA ont besoin de Skills parce que les limites de leurs capacités se sont étendues de la « génération ponctuelle » aux « processus métier reproductibles ». Les Rules permanentes ne portent pas le volume des manuels de domaine ; les prompts de chat purs ne peuvent pas être versionnés ni partagés. i-have-adhd montre que les contrats d'interaction peuvent être packagés en Skill ; diagram-design montre que la connaissance de domaine profonde doit être chargée progressivement ; agentskills.io transforme le dossier en composant standard multi-produit. La prochaine étape pour les développeurs n'est pas d'empiler plus de prompts, mais de mettre les processus dans SKILL.md et les outils dans un Schema — index court, contrat solide, contenu à la demande.

Outils liés