Aller au contenu principal

C'est quoi les Skills ?

Un Skill, c'est un fichier d'instructions donné à un agent IA comme Codex ou Claude Code pour une tâche ou un domaine précis. Pas pour lui apprendre Vue, Nuxt ou PHP depuis zéro. Plutôt pour lui dire : "dans ce projet, on travaille comme ça".

Le cas le plus parlant, c'est quand une feature simple fait perdre du temps. Ça arrive de prompter encore et encore pour une tâche qui aurait été codée plus vite à la main en lisant la doc. Moi oui.

Exemple vécu : demander à Codex de créer une modal dans une application Nuxt. Sur le papier, c'est basique. Un bouton, un état ouvert/fermé, un composant modal, un peu d'accessibilité. En vrai, sans contexte projet, l'IA peut partir dans tous les sens.

Elle peut créer un nouveau composant alors qu'il existe déjà. Elle peut utiliser une librairie que le projet n'utilise pas. Elle peut gérer l'état dans le composant alors que l'application passe par un composable. Elle peut oublier le Teleport, casser le scroll, ignorer les conventions UI, ou produire une modal qui compile mais qui ne colle pas du tout à l'architecture.

Le problème n'est pas forcément que Codex est nul. Le problème, c'est qu'il ne connaît pas automatiquement les règles locales du projet. Elles peuvent être évidentes pour l'équipe, mais elles n'existent pas pour l'agent tant qu'elles ne sont pas écrites.

Un Skill sert à sortir ces règles de la tête de l'équipe et à les rendre réutilisables. Au lieu de répéter dans chaque prompt "utilise notre composant modal", "ne crée pas de nouvelle lib", "respecte les composants UI existants", on l'écrit une fois dans un SKILL.md.

Exemple minimal :

---
name: nuxt-modal
description: À utiliser quand une tâche demande de créer, ouvrir, fermer ou modifier une modal dans notre application Nuxt.
---

# Nuxt Modal

Dans ce projet, ne crée pas une nouvelle librairie de modal.

Avant de coder :
- cherche un composant modal existant dans `components/`
- cherche un composable existant dans `composables/`
- vérifie comment les autres modales sont ouvertes

Règles :
- utiliser le composant modal existant si disponible
- garder l'état dans le composable prévu si disponible
- ne pas ajouter de dépendance sans demande explicite
- préserver l'accessibilité : fermeture clavier, focus, aria-label si nécessaire
- suivre les classes CSS et composants UI déjà utilisés dans le projet

Si aucune modal existante n'est trouvée, proposer une implémentation simple avant de coder.

Avec ça, le prompt peut rester simple : "ajoute une modal de confirmation quand l'utilisateur supprime un projet". L'agent sait déjà quoi vérifier avant d'écrire du code.

Concrètement, un Skill est un dossier avec un point d'entrée obligatoire : SKILL.md. Comme index.html dans un site web : ce n'est pas toute l'application, mais c'est le fichier par lequel on entre. Pour un Skill, SKILL.md joue ce rôle. Le nom doit être exactement SKILL.md, en majuscules, pas skill.md ou Skill.md.

Une arborescence simple peut ressembler à ça :

skills/
  nuxt-modal/
    SKILL.md
    references/
      modal-patterns.md
  api-platform-resource/
    SKILL.md
    scripts/
      validate-resource.sh
  github-pr-review/
    SKILL.md
    assets/
      review-template.md

Le nom du dossier doit être court, explicite, en kebab-case, et orienté usage. nuxt-modal est meilleur que frontend, parce qu'il dit tout de suite quand l'utiliser. Même logique pour api-platform-resource : on comprend que ce Skill sert quand on travaille sur une ressource API Platform, pas sur tout le backend.

Les dossiers references/, scripts/ et assets/ sont optionnels. references/ sert à ranger de la documentation que l'agent peut lire si besoin. scripts/ sert à ranger du code exécutable pour les tâches répétables ou fragiles. assets/ sert à ranger des templates, images ou fichiers utilisés dans le résultat final.

Le SKILL.md commence par un petit frontmatter. C'est important parce que la description sert de panneau d'entrée pour l'agent :

---
name: nuxt-modal
description: À utiliser quand une tâche demande de créer, ouvrir, fermer ou modifier une modal dans notre application Nuxt.
---

Le name doit suivre la même logique que le dossier : court, clair, en kebab-case. La description est encore plus importante : elle doit dire ce que fait le Skill et quand l'utiliser. C'est cette description qui sert de premier filtre.

Quand une tâche est demandée à l'agent, il ne doit pas lire tous les Skills du monde en entier. Au départ, il connaît surtout la liste des Skills disponibles, avec leur nom et leur description. Ensuite, il compare la demande avec ces descriptions. Si la demande est par exemple "ajoute une modal de confirmation", il peut reconnaître que ça correspond au Skill nuxt-modal, charger le corps du SKILL.md, puis suivre ses règles.

Même principe pour un autre domaine : une demande autour d'une "campagne email" pourrait déclencher un Skill dédié à l'emailing si sa description annonce clairement ce cas d'usage. Le modèle ne devine pas par magie : il s'appuie sur les indices donnés par le nom, la description et les mots de la demande.

Ensuite, si le SKILL.md pointe vers des fichiers dans references/, scripts/ ou assets/, l'agent peut aller les chercher seulement quand c'est utile. C'est l'idée de chargement progressif : d'abord la description, ensuite les instructions, puis les ressources détaillées si la tâche le demande. Ça évite de remplir le contexte avec toute la documentation du projet à chaque question.

L'action humaine reste nécessaire au départ : créer le dossier, écrire le SKILL.md, choisir un nom clair et une description précise. Ensuite, dans l'usage quotidien, il n'est pas nécessaire de recopier tout le Skill dans le prompt. La feature peut être demandée normalement, et le Skill sert de contexte de travail réutilisable.

Un bon Skill n'est pas long. Il doit contenir ce que l'IA ne peut pas deviner : les conventions du projet, les fichiers à regarder, les interdits, les bons exemples et les pièges fréquents.

Il faut en créer un quand les mêmes consignes reviennent plusieurs fois. Si l'équipe explique souvent "voici comment on fait les modales", "voici comment on écrit les tests", "voici comment on appelle l'API", alors ce n'est plus un prompt. C'est une règle de travail.

Mais bon, l'IA évolue presque toutes les secondes. Ce qu'on vient de voir ici, c'est surtout l'usage qui m'a le plus parlé : capturer des conventions de projet pour éviter les erreurs répétées. Le guide officiel d'Anthropic, The Complete Guide to Building Skills for Claude, présente aussi d'autres grandes familles : création de documents ou d'assets, automatisation de workflows, et amélioration de workflows branchés sur MCP.

À voir aussi :