Utiliser skill-creator : utiliser un skill pour créer son propre skill

📚 Navigation dans la série : L'article précédent 27 Exemples d'utilisation des skills expliquait comment bien utiliser les skills créés par d'autres — les installer, les déclencher automatiquement et s'en servir efficacement. Cet article fait l'inverse : il vous apprend à créer les vôtres. Et cela, sans tout écrire à la main, mais en s'appuyant sur le skill officiel conçu spécifiquement pour créer d'autres skills — skill-creator.

On dit souvent que SKILL.md n'est qu'un simple fichier markdown, qu'il suffit de l'écrire à la main. Est-ce vraiment nécessaire de faire appel à un outil ?

Pour être honnête, ce n'est vrai qu'à moitié. Le fichier lui-même est certes simple, mais « créer un skill capable de se déclencher avec précision » n'a rien de facile — et 90 % de ceux qui échouent en l'écrivant à la main se heurtent au même problème : une description mal rédigée, ce qui fait que le skill n'est jamais appelé.

C'est exactement ainsi que j'ai raté le premier skill que j'ai écrit à la main. Je voulais créer un skill pour « générer un commit message conforme aux normes de l'équipe ». Le dossier était créé, le corps du texte rédigé avec clarté, et j'avais rempli la description à la va-vite avec « Commit message helper ». Le résultat ? Chaque fois que je demandais à Claude de faire un commit, il ignorait complètement mon skill et écrivait une version selon ses habitudes générales. J'étais persuadé que le problème venait de l'installation, j'ai passé un temps fou sur /doctor, les redémarrages et les réinstallations, sans aucun résultat. J'ai compris plus tard que le problème n'était pas l'installation, mais l'absence dans la description des mots que l'utilisateur formulerait réellement. Ce genre de piège est totalement invisible lorsque vous écrivez à la main, et il faut un outil pour vous forcer à faire les choses correctement.

C'est là qu'intervient skill-creator.

À la fin de cet article, vous obtiendrez :

• Pourquoi écrire SKILL.md entièrement à la main semble simple mais s'avère en réalité être le moyen le plus facile de faire des erreurs, et ce que skill-creator vous aide à faire correctement
• Le flux complet de création d'un skill avec skill-creator : initialiser le squelette → guider l'écriture du name, de la description et du corps → organiser les dossiers scripts et references → packager le tout
• La section la plus importante de cet article : comment rédiger la description pour qu'elle se déclenche à coup sûr (avec des mots-clés de scénarios de déclenchement, et en se montrant un peu « proactif »)
• Dans quel dossier placer vos skills personnels et vos skills de projet, et qui peut y accéder
• Un exercice pratique guidé : initialiser un skill minimal avec skill-creator et vérifier par vous-même qu'il se déclenche correctement

---

01 Contre-intuition : écrire SKILL.md à la main n'est pas difficile, le plus dur est « de le faire répondre »

Reprenons les bases de l'article précédent. Dans l'article 27, vous avez appris qu'un skill est simplement un répertoire contenant principalement un fichier SKILL.md, avec une section YAML au début pour le name et la description, suivie d'instructions lues par Claude. La documentation officielle indique :

Chaque skill nécessite un fichier SKILL.md comprenant deux parties : le frontmatter YAML (entre les balises ---) qui indique à Claude quand utiliser le skill, et le contenu markdown contenant les instructions que Claude doit suivre lors de l'appel du skill.

Cela semble extrêmement simple, non ? On crée un dossier, on écrit un fichier, et c'est réglé. C'est pourquoi la première réaction de tout débutant est de se dire : il suffit de l'écrire à la main, pas besoin d'outil.

C'est ici que réside le point contre-intuitif : écrire le fichier à la main n'est effectivement pas difficile, le plus dur est de faire en sorte que le skill « réponde » — vous pensez qu'il s'activera automatiquement le moment venu, mais il reste en réalité à dormir dans son coin.

Analogie : L'« assistant de création d'outil » pour remplir un formulaire. Vous avez déjà vu ce genre d'assistant en installant un nouveau logiciel — il ne vous laisse pas remplir un fichier de configuration vide au hasard, mais vous demande page après page : « comment s'appelle cet outil ? », « dans quelles conditions doit-il être utilisé ? », « à quoi ressemble l'entrée et quel format voulez-vous en sortie ? ». Vous répondez à quelques questions, et il configure correctement en arrière-plan la structure des dossiers, le squelette et l'emplacement de chaque champ. skill-creator est cet assistant pour l'univers des skills : vous répondez à ses questions, et il s'occupe de faire correctement ce que vous n'auriez même pas pensé à gérer en écrivant à la main.

Quels sont les pièges les plus fréquents de l'écriture manuelle qu'il vous évite ? Voici un tableau comparatif — c'est le point essentiel à retenir de cette section :

Étape propice aux erreurs	❌ Résultat courant à la main	✅ Ce que skill-creator fait correctement pour vous
description	Écrit comme « Commit helper », sans mots-clés de déclenchement, ne s'active jamais	Vous guide pour écrire clairement « ce qu'il fait + quand l'utiliser », avec les mots-clés que l'utilisateur emploiera
Structure des dossiers	Mélange les scripts et les documents de référence dans SKILL.md, le rendant long et désordonné	Organise le tout dans scripts/ et references/ pour garder le corps du texte concis
Validation du déclenchement	Aucune idée de si le skill se déclenche ou non, on s'en remet au hasard	Fournit des cas de test pour vérifier s'il répond correctement
Amélioration	Si le déclenchement échoue, on reste bloqué sans savoir quoi modifier	Propose une phase dédiée à l'optimisation de la description, basée sur le taux de réussite du déclenchement

Vous voyez le point commun ? Les erreurs de l'écriture manuelle concernent toutes des aspects invisibles dont vous ne vous souciez pas. La valeur de skill-creator n'est pas de taper plus vite à votre place (il ne fait pas gagner beaucoup de temps de frappe), mais de vous obliger à faire correctement chacune de ces étapes invisibles.

💡 En résumé : écrire SKILL.md à la main n'est pas difficile, le plus difficile est qu'il se déclenche vraiment au bon moment ; skill-creator agit comme un assistant de formulaire pour concevoir des outils, prenant en charge pour vous la description, les dossiers, la validation et l'amélioration, autant de points souvent négligés lors de l'écriture manuelle.

---

02 Qu'est-ce que skill-creator et comment l'appeler ?

Pour faire simple : skill-creator est lui-même un skill, dont la spécialité est de « créer d'autres skills ». Cela ressemble à un jeu de mots, mais c'est logique — puisque les skills étendent les capacités de Claude, la tâche répétitive de « créer un skill » mérite elle-même d'être transformée en skill.

Il n'est pas inclus par défaut dans Claude Code (contrairement aux skills intégrés comme /code-review ou /debug). Il doit être installé séparément — en plaçant son dossier dans ~/.claude/skills/ (global pour l'utilisateur) ou dans le dossier .claude/skills/ du projet (valable uniquement pour ce projet). Ce mécanisme a été expliqué dans l'article 27. Dans le catalogue officiel des plug-ins (claude-plugins-official), le package contenant les outils de création de plug-ins s'appelle plugin-dev. skill-creator est un skill distribué indépendamment. Pour l'installer, il suffit de cloner ou de copier son dossier dans votre répertoire de skills :

# 把 skill-creator 目录放到个人 skills 目录
cp -r skill-creator ~/.claude/skills/

Résultat attendu : Une fois placé, skill-creator apparaît dans la liste /skills, avec la description « Create new skills, modify and improve existing skills... ».

Une fois installé, vous pouvez l'appeler de deux manières, exactement comme vu dans l'article 27 pour l'utilisation d'un skill :

Méthode 1 : Appeler directement son nom (commande explicite).

/skill-creator

Méthode 2 : Décrire ce que vous voulez faire en langage naturel (laisser le déclenchement automatique agir). C'est la méthode la plus courante, car la description de skill-creator est très complète. Si vous dites « je veux faire un skill pour faire XX », il réagira :

我想做一个 skill，每次帮我把 git 改动总结成一条规范的 commit message

Quelle que soit la méthode, il ne va pas simplement vous générer un fichier dans son coin, mais commencera par vous poser des questions à la manière d'un assistant. Dans la documentation officielle de skill-creator, la première étape s'appelle « Capture Intent (Capturer l'intention) », et il vous demandera les éléments suivants :

1. Que doit permettre ce skill à Claude de faire ?
2. Quand doit-il se déclencher ? (quelles formulations l'utilisateur emploiera-t-il / dans quel scénario)
3. Quel est le format de sortie attendu ?
4. Faut-il créer des cas de test pour vérifier son bon fonctionnement ?

Notez bien la deuxième question — « quand doit-il se déclencher » vous sera spécifiquement demandé. C'est sa plus grande différence avec l'écriture manuelle : à la main, personne ne vous oblige à répondre à cette question et vous passez rapidement sur la description ; skill-creator en fait sa priorité absolue, car il sait que si cette question est mal traitée, le skill créé sera inutile.

Analogie : Un organisateur de mariage qui vous pose des questions détaillées avant de prendre votre commande. Un organisateur sérieux ne vous proposera pas de projet d'emblée. Il demandera d'abord « quel est le budget ? », « combien d'invités ? », « préférez-vous un style traditionnel ou en plein air ? », « y a-t-il des restrictions alimentaires ? ». Ce n'est qu'une fois ces éléments clarifiés que le projet proposé correspondra à vos besoins, plutôt que d'être un simple modèle générique. La phase « Capture Intent » de skill-creator est cette étape de recueil des besoins — comprendre ce que vous voulez avant de commencer à assembler le skill.

💡 En résumé : skill-creator est un « skill pour concevoir des skills », installable depuis le catalogue officiel des plug-ins (nécessite une connexion internet) ; vous pouvez l'appeler via /skill-creator ou en formulant votre besoin en langage naturel. Sa première action est de vous poser des questions, notamment sur les conditions de déclenchement du skill.

---

03 Le flux de travail complet qu'il gère pour vous

skill-creator ne se contente pas de générer un fichier pour ensuite vous abandonner. Il vous accompagne tout au long de la chaîne de création d'un skill. En décomposant ses étapes, vous comprendrez ce qu'il prend en charge à chaque phase.

La documentation officielle de skill-creator résume ce processus sous forme de cycle, que nous pouvons traduire ainsi :

1. Clarifier l'objectif : Discuter d'abord pour comprendre ce que le skill doit faire et comment il va s'y prendre (la phase « Capture Intent » de la section précédente).
2. Rédiger le premier jet : En se basant sur vos réponses, remplir les champs name, description et le corps pour générer le fichier SKILL.md.
3. Créer des cas de test : Écrire 2 ou 3 prompts correspondant à ce qu'un utilisateur dirait réellement, et vous demander si ces tests sont pertinents ou s'il faut en ajouter d'autres.
4. Exécuter et évaluer : Lancer réellement ces prompts pour vous montrer les résultats — en vérifiant à la fois la pertinence de la sortie et le bon déclenchement du skill.
5. Ajuster selon les retours : Modifier le skill en fonction de vos remarques et des résultats des tests, puis relancer une phase de test, jusqu'à satisfaction.
6. (Optionnel) Optimiser la description : Une phase dédiée à l'optimisation de la description pour maximiser la précision du déclenchement.
7. Packager : Enfin, compresser le dossier complet du skill sous forme de fichier .skill pour faciliter sa distribution ou son installation.

Voyez-vous l'intérêt de cette chaîne ? Lors de l'écriture manuelle, vous ne réalisez que l'étape 2 (écrire le fichier) et ignorez les étapes 3 à 7 — c'est pourquoi le déclenchement de votre skill dépend du hasard et que vous ne savez pas comment le corriger s'il échoue. La valeur de skill-creator réside dans le fait qu'il rend obligatoires les étapes suivantes, en particulier la boucle « tester le déclenchement » et « ajuster selon les retours ».

Voici également la structure de dossiers qu'il configure correctement pour vous. La documentation officielle donne cet exemple de structure :

my-skill/
├── SKILL.md           # 主要说明（必需）
├── reference.md       # 详细参考文档，按需加载
├── examples.md        # 示例输出，按需加载
└── scripts/
    └── helper.py      # Claude 可以执行的脚本

Règle clé : le fichier SKILL.md doit rester court, les éléments lourds doivent être externalisés. La documentation officielle est très claire à ce sujet :

Maintenez le fichier SKILL.md sous la barre des 500 lignes. Déplacez les documentations de référence détaillées dans des fichiers distincts.

Pourquoi cette séparation ? Parce que dès qu'un skill se déclenche, le contenu de SKILL.md est entièrement injecté dans le contexte et y reste pour toute la durée de la session — chaque ligne représente un coût récurrent en tokens. En revanche, les scripts du dossier scripts/ sont exécutés sans être chargés en mémoire, et les documents de references/ ne sont lus que si nécessaire. L'erreur classique de l'écriture manuelle est d'intégrer directement une documentation d'API de trois cents lignes dans SKILL.md, ce qui encombre le contexte et s'avère peu ordonné. skill-creator vous guide pour organiser correctement vos fichiers : le corps du texte ne contient que l'objectif et les emplacements des ressources, les documentations lourdes vont dans references/ et les scripts de traitement dans scripts/.

Analogie : La page de sommaire et les annexes d'un livre. Vous ne mettriez pas tout le contenu du livre dans le sommaire. Le sommaire indique simplement « tel chapitre traite de tel sujet à telle page », et le détail figure dans le corps du texte ou les annexes. Le fichier SKILL.md est cette page de sommaire — il indique à Claude de quelles ressources il dispose et quand aller consulter tel fichier, tandis que les ressources elles-mêmes se trouvent dans references/ et scripts/.

💡 En résumé : skill-creator vous accompagne tout au long du flux « clarifier l'objectif → rédiger le premier jet → tester le déclenchement → ajuster selon les retours → optimiser la description → packager » ; l'écriture manuelle s'arrête souvent à la deuxième étape, tandis que cet outil complète le reste et vous guide pour structurer vos fichiers afin de garder SKILL.md léger en externalisant les documentations dans references/ et scripts/.

---

04 La section clé : comment rédiger la description pour qu'elle réponde

S'il n'y a qu'une seule chose à retenir de cet article, c'est celle-ci : la description est l'« interrupteur général » qui détermine si un skill se déclenche.

Pourquoi ? Parce que lors d'une session, Claude ne voit pas le contenu complet de votre skill d'emblée — il voit d'abord une liste associant « nom du skill + description », et utilise cette description pour juger s'il doit appeler le skill. La pertinence de la description détermine si le skill sera sollicité. La première étape recommandée par la documentation officielle pour résoudre un skill qui ne se déclenche pas concerne ce point :

Vérifiez que la description contient les mots-clés que l'utilisateur formulerait naturellement.

C'était précisément l'origine du problème de mon skill de commit évoqué en introduction. J'avais écrit « Commit message helper » — une formulation qui ne contenait aucun mot que j'utiliserais en pratique. Mes requêtes réelles étaient plutôt « aide-moi à soumettre », « écris un commit » ou « génère le message de commit ». La description ne contenant aucun de ces termes, Claude ne faisait jamais le lien. Après avoir utilisé skill-creator pour reformuler la description comme ci-dessous, le skill s'est déclenché immédiatement dès que j'ai demandé « aide-moi à soumettre ».

Comparez ces deux approches, la différence est évidente :

| ❌ Description manuelle classique et inefficace | ✅ Description optimisée avec skill-creator | |---|---|---| | Commit message helper | Résumer les modifications prêtes (staged) en un commit message conforme aux règles de l'équipe. À utiliser lorsque l'utilisateur dit « aide-moi à soumettre », « écris un commit », « génère le message de commit » ou demande de valider des modifications avant de soumettre. | | Indique uniquement « ce que c'est » | Indique à la fois « ce que ça fait » et « quand l'utiliser, avec les formulations de l'utilisateur » | | Manque de mots-clés de déclenchement, ne s'active jamais | Contient les formulations réelles, se déclenche au moment opportun |

Voici une formule simple à retenir : une bonne description = ce que fait le skill + quand l'utiliser (avec les formulations réelles de l'utilisateur). La partie « ce que fait le skill » indique à Claude l'utilité de l'outil, tandis que « quand l'utiliser » sert de déclencheur concret — et cette partie doit être rédigée avec le vocabulaire simple de l'utilisateur, et non avec des termes techniques abstraits.

Il y a aussi un aspect contre-intuitif enseigné par skill-creator : la description doit être « proactive », voire légèrement directive. En effet, Claude a actuellement tendance à sous-déclencher les skills (le phénomène d'« undertrigger ») — il évite parfois de faire appel à un skill qui pourrait pourtant l'aider. Les instructions internes de skill-creator insistent sur ce point pour corriger ce comportement :

Actuellement, Claude a tendance à sous-déclencher les skills — en évitant de les utiliser alors qu'ils seraient utiles. Pour corriger cela, formulez la description du skill de manière plus « proactive ».

Que signifie être « proactif » ? Prenons un exemple inspiré des recommandations : au lieu d'écrire simplement « générer un tableau de bord pour afficher les données internes », préférez « ... dès que l'utilisateur mentionne un tableau de bord, de la visualisation de données, des indicateurs internes, ou souhaite afficher des données de l'entreprise, même s'il n'emploie pas explicitement le mot « tableau de bord », ce skill doit être utilisé ». Indiquer explicitement les cas où le skill doit intervenir, même s'il n'y est pas invité formellement, améliore considérablement le taux de déclenchement.

Analogie : Rédiger le texte de l'enseigne d'un magasin. Si l'enseigne indique simplement « Chez Jean », les passants ne sauront pas ce que vous vendez et n'entreront pas ; si vous écrivez « Ramen de chez Jean · Nouilles gratuites · Options épicées et non épicées », vous incluez les mots que les clients recherchent et attirez plus de monde. La description est l'enseigne de votre skill — elle doit contenir les mots que vos clients prononcent et les inviter activement à entrer.

💡 En résumé : la description is l'interrupteur du déclenchement, selon la formule « ce que fait le skill + quand l'utiliser (avec les mots-clés réels de l'utilisateur) », rédigée de manière proactive pour couvrir les cas où le besoin n'est pas formulé explicitement — c'est cette phrase qui garantit que le skill répondra ; si elle est mal écrite, la qualité du corps du texte n'y changera rien.

---

05 Emplacement des fichiers : skill personnel vs skill de projet

Une fois le skill créé, où le stocker ? Le dossier choisi détermine qui pourra l'utiliser. C'est une question que vous posera skill-creator, et vous devez comprendre les implications.

Voici la table des emplacements officiels, avec les deux options les plus courantes pour débuter :

Type	Chemin	Accès
Personnel	~/.claude/skills/<nom-du-skill>/SKILL.md	Tous les projets sur votre machine
Projet	.claude/skills/<nom-du-skill>/SKILL.md	Uniquement le projet en cours

Comment choisir ? Le critère est simple : ce skill relève-t-il de vos « habitudes personnelles » ou des « règles du projet » ?

• Usage personnel universel — comme « rédiger mes commits selon mon style préféré » ou « traduire le texte sélectionné en français » — placez-le dans le dossier personnel (~/.claude/skills/), il sera disponible pour tous vos projets.
• Spécifique à un projet donné — comme « générer des interfaces selon les spécifications d'API de ce dépôt » ou « exécuter le flux de déploiement propre à ce projet » — placez-le dans le dossier de projet (.claude/skills/), et ajoutez-le à Git pour que chaque membre de l'équipe le récupère automatiquement en clonant le dépôt.

Analogie : Votre boîte à outils personnelle vs l'atelier du chantier. Votre couteau suisse vous accompagne partout dans votre poche (skill personnel) ; en revanche, une machine de chantier spécifique reste dans l'atelier de ce chantier particulier, elle ne vous suit pas et ne servirait à rien ailleurs (skill de projet). La question est de savoir si l'outil est lié à la personne ou au lieu de travail.

Une règle simple à retenir : les outils génériques vont dans ~/.claude/skills/, les outils dédiés à un projet vont dans le dossier .claude/skills/ correspondant et sont suivis par Git. Vos compétences de traduction ou de mise en forme de commits restent dans votre dossier personnel et vous suivent partout ; les processus spécifiques à un projet d'équipe sont partagés dans le dépôt — ainsi, une nouvelle personne qui clone le projet récupère directement les outils associés, sans avoir à lui expliquer quels skills installer.

Un autre avantage souligné par la documentation officielle : les skills de projet sont recherchés de manière récursive en remontant vers les dossiers parents. Si vous lancez Claude depuis un sous-dossier, le skill défini à la racine du projet sera quand même détecté. Les différents sous-projets d'un monorepo peuvent ainsi avoir leurs propres skills sans conflit.

💡 En résumé : un skill personnel va dans ~/.claude/skills/ et vous accompagne sur tous vos projets ; un skill de projet va dans .claude/skills/, est suivi par Git, s'applique uniquement à ce projet et est partagé avec l'équipe. La distinction est simple : l'outil suit-il l'utilisateur ou le projet ?

---

06 Pratique : créer un skill minimal avec skill-creator et tester son déclenchement

Rien ne vaut la pratique. Nous allons utiliser skill-creator pour concevoir un skill minimal, et surtout vérifier par nous-mêmes qu'il se déclenche correctement — l'étape cruciale souvent omise et ratée lors de la création manuelle. Cet exercice ne nécessite aucun environnement complexe.

L'objectif de notre skill est simple : demander à Claude de résumer sous forme de points clés les modifications non validées dans le dépôt git actuel.

Étape 1 : Vérifiez que skill-creator est disponible

Après avoir lancé Claude Code, saisissez :

/skills

Résultat attendu : skill-creator doit apparaître dans la liste. S'il n'y est pas, reprenez les étapes de la section 02 pour copier le dossier de skill-creator dans votre répertoire de skills (avec une connexion internet active).

Étape 2 : Formulez votre demande en langage naturel

Saisissez votre besoin dans la zone de texte (en précisant également les conditions de déclenchement pour éviter qu'il ne vous les demande) :

用 skill-creator 帮我做一个 skill。
功能：把当前 git 仓库里未提交的改动总结成 2-3 条要点。
触发场景：当我问「我改了啥」「总结一下我的改动」「我这次动了哪些东西」的时候。
名字就叫 summarize-changes。

Résultat attendu : skill-creator s'active et commence à valider votre intention — il peut vous demander le format de sortie ou si vous souhaitez créer des cas de test. Répondez simplement à ses questions, en veillant particulièrement à ce que la description générée contienne bien les mots-clés de déclenchement demandés (« 我改了啥 », « 总结改动 », etc.), qui constituent le point clé vu à la section 04.

Étape 3 : Indiquez-lui d'enregistrer le fichier dans le répertoire personnel

Confirmez que le skill doit être écrit dans ~/.claude/skills/summarize-changes/ (dossier personnel, disponible pour tous les projets). Le fichier SKILL.md généré devrait ressembler à ceci — vérifiez en priorité la section frontmatter :

---
name: summarize-changes
description: 把当前 git 仓库里未提交的改动总结成几条要点。当用户问「我改了啥」「总结一下我的改动」「我这次动了哪些东西」，或想快速了解工作树现状时使用。
---

## 当前改动

!`git diff HEAD`

## 你的任务

把上面的改动用 2-3 条要点总结清楚。如果 diff 为空，就说一句「当前没有未提交的改动」。

La syntaxe !`git diff HEAD` correspond à l'« injection dynamique de contexte » officielle : Claude Code commence par exécuter cette commande, remplace cette ligne par le diff réel, puis présente le contenu du skill à Claude. Il reçoit ainsi les modifications réelles de votre espace de travail, et non des suppositions. Cette syntaxe évoquée dans l'article 27 trouve ici sa mise en application.

Étape 4 : Créez des modifications dans un dépôt pour donner de la matière au skill

Sélectionnez un projet git quelconque (ou créez-en un vide avec git init), et modifiez un fichier. Par exemple :

cd ~/some-git-project
echo "// test change" >> README.md

Résultat attendu : La commande git status doit indiquer que le fichier README.md a été modifié et n'est pas encore validé.

Étape 5 (la plus importante) : Vérifiez que le déclenchement fonctionne

Nous allons effectuer deux types de vérifications, conformément aux deux approches décrites dans la documentation officielle :

Test A — Déclenchement automatique : Posez la question en langage naturel dans Claude Code (attention, ne mentionnez pas le nom du skill, utilisez simplement une formulation courante pour voir si Claude y pense de lui-même) :

我改了啥？

Résultat attendu : Si la description est correcte, Claude doit appeler automatiquement summarize-changes et afficher les points clés des modifications (par exemple : « Ajout d'une ligne de commentaire à la fin de README.md »). Si Claude y parvient de lui-même, le déclenchement est réussi et la description est validée.

Test B — Appel direct : Si le déclenchement automatique ne fonctionne pas, forcez l'appel en utilisant le nom du skill :

/summarize-changes

Résultat attendu : Le skill s'exécute immédiatement et affiche les points clés des modifications.

Comment interpréter le résultat :

Résultat constaté	Signification	Action
Les tests A et B affichent les points clés	Déclenchement parfait	Travail terminé
A ne se déclenche pas, mais B fonctionne	La description manque de mots-clés, mais le corps du skill est correct	Demandez à skill-creator d'optimiser la description en ajoutant des formulations de déclenchement
Ni A ni B ne fonctionnent	Problème de création de fichier ou d'instructions dans le corps	Vérifiez le chemin d'accès et le contenu du fichier SKILL.md

Observez bien le cas intermédiaire — si A ne se déclenche pas alors que B fonctionne, cela confirme le point central abordé dans cet article : le skill lui-même fonctionne, le problème réside uniquement dans la capacité à le déclencher, ce qui est presque toujours lié à la description. C'est le piège classique dans lequel tombent les créateurs manuels sans s'en rendre compte. Lancer l'étape d'« optimisation de description » avec skill-creator permet alors de corriger le problème.

En réalisant ces fins étapes, vous avez validé le flux de création complet : « générer le squelette → rédiger une description efficace → stocker dans le bon répertoire → créer des modifications → tester le déclenchement automatique / l'appel direct ». La création de tout autre skill suivra ce même modèle en adaptant le contenu.

💡 En résumé : concentrez-vous sur deux points pratiques — vérifiez que la description générée contient des formulations réelles, et testez si Claude appelle le skill de lui-même en langage naturel ; si le déclenchement automatique échoue alors que l'appel avec /nom fonctionne, ajustez la description avec skill-creator pour y ajouter des mots-clés.

---

07 Le petit plus : exporter sous forme de .skill pour le distribuer

Une fois le skill créé et son déclenchement validé, si vous souhaitez le partager avec vos collègues ou votre équipe, skill-creator peut vous aider à l'exporter sous forme de fichier .skill — le destinataire récupère un fichier unique prêt à installer, vous évitant de lui expliquer la structure des dossiers à recréer.

Il utilise pour cela un script d'export en arrière-plan. Vous n'avez pas besoin de retenir la commande, demandez simplement à skill-creator de s'en charger :

帮我把这个 skill 打包成 .skill 文件

Résultat attendu : Il lance le script d'export, compresse le dossier summarize-changes/ (avec son fichier SKILL.md et les répertoires scripts/ ou references/ associés) dans un fichier summarize-changes.skill, et vous indique son emplacement.

L'intérêt de cette étape réside dans la distribution : l'article 27 expliquait comment « installer les skills des autres », et ce fichier compressé que vous générez ici est précisément le format que les autres utiliseront pour installer votre skill — la boucle est bouclée. C'est la méthode privilégiée pour partager des outils au sein d'une équipe : le concepteur génère le fichier, le partage avec le groupe, et chacun peut l'installer immédiatement pour disposer de l'outil, ce qui est bien plus fiable que de demander à chacun de recréer manuellement les répertoires.

💡 En résumé : demandez à skill-creator de compiler votre travail sous forme de fichier .skill pour disposer d'un fichier unique prêt à être partagé ; ce format correspond exactement à celui requis pour installer le skill chez d'autres, faisant le lien avec le contenu de l'article 27.

---

08 Résumé

Cet article a détaillé pourquoi il est préférable de ne pas écrire ses skills entièrement à la main et comment concevoir un skill opérationnel — le point clé étant que la difficulté réside dans le déclenchement, un aspect pour lequel skill-creator s'avère indispensable.

Synthétisons les points clés :

Objectif	Méthode	Point clé
Installer l'outil de création	Cloner ou copier le dossier dans votre répertoire de skills	cp -r skill-creator ~/.claude/skills/ (skill indépendant, non intégré par défaut)
Lancer la création	Saisir /skill-creator ou décrire le besoin en langage naturel	L'assistant vous interroge sur l'objectif et les conditions de déclenchement
Assurer le déclenchement	Soigner la rédaction de la description	Indiquer ce que fait le skill + quand l'utiliser (avec les formulations de l'utilisateur), de manière proactive
Choisir le répertoire	Personnel vs Projet	Les outils génériques vont dans ~/.claude/, les outils de projet dans .claude/ et sont suivis par Git
Valider le fonctionnement	Tester le déclenchement automatique et l'appel direct	Un échec au déclenchement automatique révèle un problème de description
Partager le skill	Exporter sous forme de fichier .skill	Génère un fichier unique prêt à installer chez d'autres, complétant le flux de l'article 27

Vous devriez maintenant être capable de : comprendre pourquoi l'écriture manuelle d'un fichier SKILL.md pose souvent des problèmes de déclenchement, utiliser skill-creator pour dérouler le flux complet « initialiser le squelette → rédiger une description efficace → tester le déclenchement → packager », concevoir une description réactive, organiser vos dossiers de skills, et valider le bon fonctionnement du déclenchement. Cette capacité à concevoir des outils opérationnels et réactifs marque votre transition entre l'utilisation des ressources des autres et la création de votre propre chaîne d'outils.

Le skill de commit évoqué en introduction, qui ne fonctionnait pas initialement, a été recréé avec skill-creator : il a suffi d'ajuster sa description pour qu'il devienne parfaitement opérationnel. C'est toute la valeur de cet outil — il vous évite de passer à côté de ces détails invisibles.

💡 En résumé : la difficulté de la création de skills réside dans leur déclenchement. skill-creator structure les étapes indispensables de rédaction de description, de test et d'ajustement souvent ignorées à la main — la clé de la réussite consiste à définir clairement les conditions de déclenchement, plutôt qu'à détailler uniquement les fonctionnalités.

---

Le prochain article 29 Agent teams : travailler en équipe d'agents (expérimental, sujet à modifications) vous présentera le travail collaboratif. Jusqu'à présent, votre utilisation de Claude Code s'est faite de manière isolée — une session, un assistant, en face à face. Cependant, certaines tâches sont trop lourdes pour un seul agent — est-il possible de constituer un groupe de travail où plusieurs agents collaborent, l'un gérant l'architecture, l'autre écrivant le code et un troisième exécutant les tests ? C'est ce que nous aborderons dans le prochain article. Si vous disposiez de trois agents Claude simultanément, quelles seraient les trois premières tâches que vous leur confieriez ?

---

Lectures recommandées

• Version web et cloud : exécuter Claude Code dans un navigateur et sur mobile
• Intégration avec VS Code
• Commandes slash (Slash Commands) : appeler les raccourcis de Claude d'un simple /