Construire son propre Skill : de l'idée à la commande slash réutilisable
Je me suis surpris, sur plusieurs sessions de suite, à retaper les mêmes consignes à Claude Code : le format de mes commits, le port de dev à choisir pour un nouveau projet, l'interdiction du gradient indigo/violet par défaut sur une UI. À un moment, répéter une instruction cesse d'être un détail et devient un signal : c'est le moment de la transformer en skill.
Le signal qui justifie un skill#
Toutes les habitudes ne méritent pas un skill. La question que je me pose avant d'en créer un : est-ce que je redonnerais la même instruction, dans les mêmes mots, sur un projet différent, dans un mois ? Si oui, c'est un skill. Si c'est spécifique à une tâche en cours, ça reste une instruction ponctuelle dans le prompt.
Un bon indicateur concret : si tu colles le même paragraphe d'instructions dans trois sessions différentes, c'est déjà trop tard, tu aurais dû en faire un skill à la deuxième.
De l'idée au SKILL.md#
Un skill, à la base, c'est un dossier avec un fichier SKILL.md qui décrit
quand se déclencher et quoi faire, accompagné au besoin de scripts ou de
fichiers de référence. Je passe par skill-creator, un skill dédié à la
création d'autres skills, plutôt que d'écrire le SKILL.md à la main dès le
départ : il pose les bonnes questions (quel déclencheur, quelle sortie
attendue, quels cas limites) et évite d'oublier une section.
---
name: regles-projets
description: Conventions standard pour les projets persos/freelance (commits, UI, stack, copyright...). A appliquer par defaut, sans attendre qu'on le redemande.
---
## Quand se declencher
Des qu'on code, commit ou designe pour un projet perso/freelance de
l'utilisateur, pas seulement quand il le rappelle explicitement.
## Regles
1. Commits au format Angular, jamais de trace d'IA dans le code
2. UI soignee des le premier jet, pas de gradient indigo/violet par defaut
3. Stack par defaut : Next.js, TypeScript, Tailwind, VercelC'est un extrait simplifié, mais il illustre l'essentiel : le champ
description n'est pas un résumé pour un humain, c'est ce que le modèle lit
pour décider s'il doit charger le skill. Une description vague comme « aide
pour les projets » ne se déclenche presque jamais toute seule.
La transformer en commande slash#
Un skill peut se déclencher tout seul si sa description matche le contexte,
ou être invoqué explicitement via /nom-du-skill. Les deux usages ne
s'excluent pas : je conçois systématiquement mes skills pour marcher dans
les deux cas, avec des arguments optionnels pour la commande slash quand ça
a du sens (/nouveau-projet mon-app --prive, par exemple).
| Mode de déclenchement | Qui décide | Cas d'usage typique |
|---|---|---|
| Automatique (description) | Le modèle, selon le contexte | Convention appliquée sans y penser (regles-projets) |
| Commande slash explicite | Moi, au moment voulu | Action ponctuelle avec des paramètres (nouveau-projet, save-config) |
Ce qui fait qu'un skill se déclenche, ou pas#
C'est le point qui m'a pris le plus d'itérations. Un skill reste probabiliste par nature : rien ne garantit qu'il sera chargé, même s'il existe et qu'il serait pertinent. La description doit contenir les mots que j'emploierais naturellement dans un prompt, pas une paraphrase technique. J'ai un skill de vérification de dépendances qui ne se déclenchait jamais tout seul tant que sa description parlait de « audit de sécurité » : personne ne dit ça en langage courant. Une fois reformulée en « vérifier si mes dépendances sont à jour, chercher des vulnérabilités », il s'est mis à se déclencher correctement.
Les pièges que j'ai rencontrés#
- Trop large : un skill qui essaie de couvrir tous les cas de figure devient une liste de règles vagues, difficile à suivre et à maintenir.
- Trop rigide : à l'inverse, un skill qui prescrit une séquence figée casse au premier cas non prévu par son auteur.
- Description technique plutôt que naturelle : le skill existe, mais ne se déclenche jamais parce que personne ne parle comme sa description.
Un skill mal déclenché donne une fausse impression de sécurité : on pense avoir encodé une règle, alors qu'elle ne s'applique en pratique que quand on y pense soi-même. Teste toujours le déclenchement automatique avant de faire confiance au skill.
Ce que ça change au quotidien#
J'ai aujourd'hui une dizaine de skills persos : un pour les conventions de mes projets, un pour scaffolder un nouveau projet en une commande, un pour synchroniser ma todo-list vers mon calendrier, un pour auditer les dépendances de tous mes repos d'un coup. Aucun n'a été écrit d'un seul jet : chacun a démarré comme une instruction répétée, puis a été affiné sur plusieurs sessions jusqu'à se déclencher de façon fiable.
La méthode tient en une phrase : commence par l'agacement d'avoir répété la même chose deux fois, écris la description comme tu formulerais le besoin à voix haute, et laisse le skill rater son déclenchement quelques fois avant de la corriger. C'est cette itération, pas la première version, qui rend un skill vraiment réutilisable.
