De Slash Commands à Skills : quand migrer et comment

Les trois articles précédents ont couvert l'usage complet des slash commands : du fichier Markdown à l'injection par !commande, puis à l'orchestration via subagents et MCP. Rien de tout cela n'est obsolète — mais, en coulisses, l'équipe officielle a opéré une fusion : les custom commands sont désormais intégrés aux Skills.

Votre .claude/commands/review.md continue de tourner, /review reste disponible, vous n'avez rien à changer. Mais si vous voulez que la commande gagne en capacités (plusieurs fichiers, exécution en fork, activation automatique par path), le nouveau chemin est .claude/skills/review/SKILL.md. Cet article clarifie deux choses : comment migrer, et si le jeu en vaut la chandelle.

Migration minimale : changer un chemin, rien d'autre

La promesse de compatibilité officielle est nette : .claude/commands/deploy.md et .claude/skills/deploy/SKILL.md s'enregistrent tous deux comme /deploy, avec un comportement identique. En cas de collision de nom, les skills l'emportent.

Les étapes minimales :

cd .claude/commands
mkdir -p ../skills/review
mv review.md ../skills/review/SKILL.md

Pas une ligne à modifier dans le fichier. Le frontmatter YAML, !`commande`, @file, $ARGUMENTS — tout reste compatible.

Mais à se limiter à cette étape, le lecteur se dit : pourquoi migrer alors ? La réponse tient dans le fait qu'un dossier skill peut contenir plusieurs fichiers, alors qu'une command est limitée à un seul.

Pourquoi migrer : les quatre atouts supplémentaires de SKILL.md

1. Fichiers annexes : sortir les longues docs

SKILL.md est le point d'entrée, et le même dossier peut héberger n'importe quels fichiers joints. Imaginez une arborescence comme celle-ci :

.claude/skills/review/
├── SKILL.md            # point d'entrée, instructions concises + références
├── checklist.md        # checklist de code review, longue
├── examples/
│   └── good-diff.md    # exemple positif
└── scripts/
    └── lint.sh         # script que SKILL.md peut invoquer

Dans SKILL.md, on pointe dessus via un path relatif :

Revoir le diff courant en respectant les critères de [checklist.md](checklist.md).
Consulter [examples/good-diff.md](examples/good-diff.md) pour le format attendu.

Ces fichiers annexes n'entrent pas automatiquement dans le context — Claude les lit à la demande. La recommandation officielle : garder SKILL.md sous 500 lignes et déporter le reste dans des fichiers annexes.

2. `disable-model-invocation` : quels skills ne s'activent qu'à la main

Par défaut, Claude peut décider de déclencher un skill s'il juge le moment opportun. C'est dangereux pour les commandes à effet de bord comme /deploy, /commit, /send-email — vous ne voulez pas qu'il « déploie parce que le code lui plaît ».

---
name: deploy
description: Déploie vers la production
disable-model-invocation: true
allowed-tools: Bash(kamal deploy:*), Bash(git push:*)
---

Cette ligne ajoutée, /deploy ne se déclenche qu'à la saisie manuelle : Claude ne le lancera plus de lui-même au cours d'une conversation.

À l'inverse, user-invocable: false signifie « seul Claude peut l'appeler, mais il ne figure pas dans le menu / » — parfait pour un skill de connaissance de fond (par exemple legacy-system-context, que Claude charge automatiquement dans les bons contextes, et qu'il n'y aurait aucun intérêt à déclencher manuellement).

3. `context: fork` : faire tourner le skill dans un subagent

C'est l'évolution la plus marquante. L'article précédent montrait qu'une command pouvait, via allowed-tools: Task, demander au modèle de lancer un subagent — mais il fallait décrire à la main dans le prompt « démarre un subagent Explore pour... ».

Avec SKILL, une ligne de frontmatter suffit :

---
name: deep-research
description: Investiguer en profondeur un symbole
context: fork
agent: Explore
---

Étudier tous les usages de $ARGUMENTS :
- tous les points d'appel
- les scénarios métier
- les implémentations alternatives

Retourner un résumé de ≤300 mots.

Quand vous déclenchez /deep-research SomeClass, l'intégralité de SKILL.md devient le prompt d'un subagent indépendant, exécuté avec l'agent type Explore, qui ne renvoie que sa conclusion. Le context de la conversation principale reste parfaitement propre.

Cela revient à transformer « lancer un subagent » : d'un bout de texte dans le prompt, on passe à un attribut déclaratif du skill.

4. `paths` : activation automatique selon le type de fichier

---
name: rails-conventions
description: Conventions de code pour ce projet Rails
paths: ["app/**/*.rb", "config/**/*.rb"]
---

Respecter les conventions Rails de ce projet :
- privilégier un service object plutôt qu'un fat controller
- les scopes ActiveRecord doivent être nommés
...

Quand vous éditez app/models/user.rb, ce skill est automatiquement injecté dans le context ; quand vous éditez package.json, il ne l'est pas. Plus ciblé qu'un CLAUDE.md global — l'équivalent d'un « CLAUDE.md stratifié par path ».

Cas pratique : transformer `/plan` en skill

Le /plan final du dernier article était à l'origine une command mono-fichier :

.claude/commands/plan.md

Version skill :

.claude/skills/plan/
├── SKILL.md
├── research-prompt.md     # instructions du subagent 1
└── risk-prompt.md         # instructions du subagent 2

SKILL.md :

---
name: plan
description: Produire un plan d'implémentation à partir d'un ticket Linear
disable-model-invocation: true
allowed-tools: mcp__linear__*, Task, Read, Grep, Bash(git log:*)
---

## Contexte

@.claude/context/architecture.md

## État

!`git log --oneline -10`

## Tâche

Récupérer la description et les commentaires du ticket Linear $ARGUMENTS.

Lancer deux subagents en parallèle via Task :
1. Étude de code : prompt dans [research-prompt.md](research-prompt.md)
2. Évaluation des risques : prompt dans [risk-prompt.md](risk-prompt.md)

Consolider les deux résultats en : étapes d'implémentation + liste des risques + recommandations de granularité des commits.

Les prompts des deux subagents vivent dans des fichiers séparés ; on peut les modifier sans toucher à SKILL.md. Le skill lui-même reste net, sous 30 lignes, pendant que les annexes peuvent faire plusieurs centaines de lignes chacune si besoin.

Si vous ne voulez même pas orchestrer les subagents vous-même, vous pouvez aller plus loin et envoyer le skill entier en fork, pour que l'agent Explore exécute le tout d'un bloc :

---
name: plan
context: fork
agent: Explore
allowed-tools: mcp__linear__*
---

/plan ENG-4213 → l'agent Explore, dans un context isolé, reprend tout le contenu de SKILL.md comme sa tâche → ne renvoie que le plan final. La conversation principale reste immaculée.

Quand ne pas migrer

Toutes les commands ne méritent pas le passage. Rester dans .claude/commands/ est plus adapté quand :

Un seul Markdown suffit : pas de checklist, d'exemples ni de scripts à externaliser.
Pas besoin d'exécution en fork : la tâche est intimement liée à la conversation principale et doit voir tout l'historique.
Pas besoin d'activation automatique par path : l'utilisateur la déclenche manuellement.
Pas besoin de contrôle d'accès : aucun risque si Claude l'appelle de lui-même.

Les /commit, /pr-desc et autres simples commandes — un frontmatter et quelques lignes de prompt — sont plus lisibles dans .claude/commands/. Officiellement, les deux formes coexistent et aucune n'est dépréciée.

L'état de la coexistence

Aujourd'hui, l'organisation la plus propre d'un .claude/ ressemble à :

.claude/
├── commands/           # léger : mono-fichier + prompt simple
│   ├── commit.md
│   └── pr-desc.md
├── skills/             # lourd : multi-fichiers / fork / contrôle d'accès
│   ├── plan/
│   │   ├── SKILL.md
│   │   ├── research-prompt.md
│   │   └── risk-prompt.md
│   ├── deploy/
│   │   └── SKILL.md    # disable-model-invocation
│   └── rails-conventions/
│       └── SKILL.md    # activation auto via paths glob
└── context/
    └── coding-standards.md

Pas besoin de tout migrer d'un coup. Le signal pour migrer, c'est « cette command commence à enfler » : plus de 200 lignes, besoin de découper la doc, envie de la faire tourner dans un subagent. À ce moment-là, on change le path — une affaire de quelques minutes.

En résumé

Capacité souhaitée	`commands/`	`skills/`
Raccourci prompt mono-fichier	✅	✅
!`commande` / `@file` / `$ARGUMENTS`	✅	✅
Contrôle d'accès via `allowed-tools`	✅	✅
Fichiers annexes (références, scripts)	❌	✅
`disable-model-invocation` anti-déclenchement involontaire	❌	✅
Exécution isolée via `context: fork` + `agent:`	❌	✅
Activation automatique par `paths:` glob	❌	✅

Sur les trois premières lignes, commands et skills sont strictement équivalents ; les quatre suivantes sont propres aux skills. On prend ce dont on a besoin, on laisse le reste.

La trajectoire officielle penche vers les skills, mais la promesse de compatibilité de commands/ est claire — il ne s'agit pas d'un « migrez maintenant ou disparaissez », mais d'une extension « voilà des capacités en plus, sans obligation ». Comprenez les différences, migrez à la demande, n'obéissez pas à un besoin cosmétique d'uniformité.