Accueil / Étendre : compétences, MCP, sous-agents, hooks, plugins

Créer une skill qui devient aussi une commande

Une commande personnalisée et une skill sont désormais le même mécanisme : un fichier .claude/commands/nom.md et un dossier .claude/skills/nom/SKILL.md produisent tous deux la commande /nom avec le même comportement, et pour une skill personnelle ou de projet, c'est le nom du dossier, pas le champ name du frontmatter, qui devient le nom de la commande.

Une commande personnalisée et une skill sont devenues le même mécanisme. Un fichier .claude/commands/deploy.md et un dossier .claude/skills/deploy/SKILL.md produisent tous les deux la commande /deploy, avec le même comportement à l'exécution : les anciens fichiers de commandes continuent de fonctionner sans rien changer, et la forme en dossier est désormais recommandée pour ce qui dépasse une simple instruction, parce qu'elle peut embarquer des fichiers de support à côté du texte.

Où vit une skill, et jusqu'où elle porte

Une skill personnelle vit dans ~/.claude/skills/nom-de-la-skill/SKILL.md et reste disponible dans tous les projets ouverts depuis ce compte. Une skill de projet vit dans .claude/skills/nom-de-la-skill/SKILL.md et ne s'applique qu'à ce dépôt précis, c'est elle qu'on verse au contrôle de version pour la partager avec une équipe. Deux autres emplacements existent, l'un pour une skill fournie par l'entreprise, l'autre pour une skill livrée dans un plugin, chacun avec sa propre priorité en cas de nom partagé entre plusieurs sources. Le choix de l'emplacement se fait donc avant l'écriture, en se demandant qui doit voir cette commande : soi seul sur tous ses projets, ou toute une équipe sur ce dépôt précis.

Le frontmatter et la substitution d'arguments

Dans le frontmatter, seul le champ description est vraiment recommandé, tous les autres restent facultatifs, y compris name. Pour une skill personnelle ou de projet, ce champ ne sert que d'étiquette d'affichage, sans déterminer le nom de la commande, qui vient du nom du dossier ; dans une skill de plugin en revanche, name fixe le dernier segment de la commande, le préfixe du plugin restant devant. Dans le corps du fichier, $ARGUMENTS reçoit tout ce que l'utilisateur a tapé après la commande, comme une seule chaîne ; l'indexation est à base zéro, $0 reçoit le premier mot, $1 le deuxième, et ainsi de suite, $ARGUMENTS[N] étant la forme longue équivalente à $N ; et un argument déclaré par son nom dans le frontmatter se lit directement par $nom-declare dans le texte.

# Exemple illustratif, sur un dossier de démonstration
mkdir -p demo-commande/resumer-pr
cat > demo-commande/resumer-pr/SKILL.md <<'EOF'
---
description: Resume une pull request a partir de son numero, pour preparer une revue rapide.
arguments:
  - name: numero_pr
---
Resume la pull request numero $numero_pr en trois points : ce qui change,
ce que ca casse potentiellement, ce qui reste a tester.
EOF

Cette fusion simplifie un choix qui, quelques mois plus tôt, obligeait à trancher entre deux fichiers voisins dès le départ. Elle ne dispense pas de choisir le bon emplacement, personnel ou projet, ni d'écrire une description assez précise pour que la skill se déclenche au bon moment sans intervention : c'est justement ce mécanisme de déclenchement, déjà posé dans apprendre un workflow à Claude, qui décide si le travail d'écriture sert à quelque chose. Une commande qui existe mais que personne ne pense à taper, faute d'une description qui aurait pu la déclencher automatiquement, rend exactement le même service que si elle n'avait jamais été écrite.