Utilise les références @file, allowed-tools, sous-agents et outils MCP pour transformer les slash commands de raccourcis en bibliothèque de workflows d'équipe.
Les deux premiers articles traitaient de ce qu'est un slash command (un fichier Markdown) et de l'usage du préfixe ! pour injecter la sortie du shell dans le contexte. Celui-ci va plus loin : comment faire en sorte qu'une seule commande orchestre les capacités les plus puissantes de Claude Code — références de fichiers, sous-agents, outils MCP — tout en gardant les permissions sous contrôle.
À ce niveau, un command n'est plus un simple « raccourci de prompt » : c'est un petit workflow réutilisable.
@file : l'injection statique mieux pensée que !cat!cat file.md permet de pousser le contenu d'un fichier dans le contexte, mais ça passe par le shell, avec plusieurs inconvénients : un sous-processus lancé à chaque déclenchement ; des caractères spéciaux ou espaces dans le chemin à échapper ; et surtout Claude Code ne voit pas « un fichier », juste un bloc de texte.
La référence @ est native :
---
description: Relire les changements selon les conventions du projet
---
Référence-toi aux conventions suivantes :
@.claude/context/coding-standards.md
@.claude/context/security-checklist.md
Relis maintenant les modifications du git diff et signale tout ce qui enfreint ces règles.
!`git diff HEAD`
@chemin dit à Claude Code : « attache ce fichier à la conversation ». La différence :
| Cas | Avec !cat |
Avec @ |
|---|---|---|
Chemin issu d'un argument ($ARGUMENTS) |
✅ Obligé d'utiliser !cat |
❌ @ ne gère pas l'expansion de variables |
| Conventions, templates fixes du projet | ⚠️ Possible mais lourd | ✅ Natif, économise un appel shell |
| Contenu dynamique (diff, logs, résultats de tests) | ✅ ! obligatoire |
❌ Impossible |
La règle : @ pour les fichiers statiques, ! pour les sorties dynamiques, !cat $ARGUMENTS pour un chemin paramétré.
allowed-tools : poser des limites de permissions à un commandPar défaut, pendant l'exécution d'un command, le modèle a accès à tous les outils de la session. Ce n'est pas toujours souhaitable — par exemple, /review est une relecture en lecture seule, et on ne veut pas qu'il touche « accidentellement » à une ligne de code.
En ajoutant allowed-tools dans le frontmatter, on restreint les outils disponibles le temps de la commande :
---
description: Relecture de code en lecture seule
allowed-tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*)
---
Relis les différences entre la branche courante et master, sans rien modifier.
!`git diff master...HEAD`
Quelques points clés :
Bash(git diff:*) est une autorisation fine — seuls les appels bash commençant par git diff sont permis ; git push est bloquéRead / Grep / Glob ouvre explicitement les outils de lecture seuleEdit / Write n'apparaissent pas : même si le modèle voulait modifier du code, il n'en aurait pas les moyensInversement, un command à pouvoirs élevés comme /deploy peut être autorisé explicitement :
---
description: Déployer la branche courante
allowed-tools: Bash(kamal deploy:*), Bash(git push:*), Read
---
Figer ce que « cette commande a le droit de faire » est bien plus fiable que de devoir valider chaque prompt bash à la main à l'exécution.
Certaines tâches font exploser le contexte de la conversation principale — parcourir des dizaines de fichiers pour trouver tous les appels à une fonction, faire des stats sur la base de code, analyser un gros bloc de logs. Si on fait ça directement, des milliers de lignes de sortie restent dans le contexte, et la suite de la discussion devient lente et moins pertinente.
La bonne approche : confier ça à un subagent. Le sous-agent tourne dans son propre contexte et ne ramène que la conclusion. Dans le command, il suffit de l'indiquer explicitement :
---
description: Enquête approfondie sur tous les usages d'un symbole
allowed-tools: Task
---
Utilise le sous-agent Explore pour enquêter en profondeur sur tous les usages du symbole suivant : $ARGUMENTS
Demande au sous-agent de couvrir :
- Tous les points d'appel (y compris les fichiers de test)
- Les cas métier concernés
- L'existence éventuelle d'implémentations équivalentes
Au retour du sous-agent, donne-moi seulement un résumé de ≤300 mots, sans coller de fragments de code bruts.
En déclenchant /trace SomeClass#some_method, Claude Code lance un sous-agent Explore qui balaie la base de code en parallèle ; la conversation principale ne reçoit que la conclusion synthétisée. Pas de sortie grep, pas de fragments de fichiers, contexte propre.
On peut aller plus loin :
---
description: Enquête parallèle sur trois solutions candidates
allowed-tools: Task
---
Lance 3 sous-agents simultanément, pour enquêter chacun sur une des pistes suivantes :
1. Utiliser l'existant ActiveJob + Sidekiq
2. Utiliser Solid Queue
3. Construire une petite queue maison
Chaque agent répond sur : charge de travail, risques, intrusivité dans le code existant. Une fois les trois conclusions revenues, je ferai la comparaison.
Trois sous-agents en parallèle, une seule attente côté conversation principale. C'est l'un des plus grands leviers qu'offre un command : transformer une recherche coûteuse en tokens en un workflow déclenchable en une touche.
Si des serveurs MCP sont branchés à la session (Linear, GitHub, Sentry, un proxy de base de données maison…), un command peut demander directement au modèle de les utiliser :
---
description: Générer une todo d'implémentation à partir d'une issue Linear
allowed-tools: mcp__linear__*, Read, Grep
---
Lis la description complète et les commentaires de l'issue Linear $ARGUMENTS.
Croise-les avec l'état actuel du code (retrouve les fichiers pertinents toi-même avec Grep/Read), puis sors une todo d'implémentation :
- Quels fichiers doivent être modifiés
- Chaque étape est-elle un commit séparé ou pas
- Y a-t-il des ambiguïtés à clarifier avec le PM avant de commencer
Ne commence pas à coder, produis seulement le plan.
mcp__linear__* autorise tous les outils Linear MCP : le modèle peut aller chercher les détails de l'issue, les commentaires, le statut. La commande entière devient le point de départ d'un workflow « du ticket au plan d'implémentation ».
Point important : dans allowed-tools, il faut écrire les noms d'outils MCP avec leur préfixe complet (mcp__<server>__<tool>), sinon l'autorisation ne prend pas.
Une idée fausse très répandue : écrire /test dans le fichier de /review en pensant déclencher le command test. Ça ne marche pas. Un slash command n'est développé qu'une seule fois, au niveau de l'entrée utilisateur. À l'intérieur d'un command, /xxx n'est que du texte ordinaire : le modèle le lit, mais Claude Code ne l'exécute pas.
Pour composer plusieurs commands, voici les bonnes approches :
Approche A : extraire la logique partagée dans un fichier de contexte, référencé via @ ou !cat
@.claude/context/review-checklist.md
@.claude/context/security-checklist.md
Approche B : écrire explicitement dans le command « fais comme /review » + répéter les instructions clés
Peu élégant mais efficace. Tant que le prompt est clair, le modèle suivra la même démarche.
Approche C : laisser un command lancer un sous-agent via Task, et réutiliser les mêmes fichiers de contexte dans le prompt du sous-agent
C'est la voie que prennent tous les vrais workflows orchestrés. Le command parent dispatche et agrège, le sous-agent exécute les étapes concrètes.
Anti-pattern à éviter : écrire un command de plusieurs centaines de lignes qui essaie de tout faire en une instruction. La granularité part en vrille, la maintenance devient un cauchemar, et le budget token d'une seule exécution se fait engloutir.
À ce stade, on a à peu près tous les outils pour injecter « des capacités extérieures » dans un command. Comment choisir :
| Besoin | Mécanisme préféré |
|---|---|
| Conventions, templates, docs de contexte fixes | Référence @file |
| État en direct (diff, logs, tests, requêtes SQL) | Injection !shell |
| Contenu de fichier paramétré | !cat $ARGUMENTS |
| Recherche coûteuse en contexte, fouille multi-fichiers | subagent via Task |
| Systèmes externes (tickets, supervision, prod) | Outils MCP + allowed-tools |
| Workflow multi-étapes séquentiel/parallèle | command parent orchestrant des sous-agents |
Les limites de permissions passent par une déclaration explicite via allowed-tools, en particulier pour les commands partagés en équipe — figer ce que le command a le droit de faire est plus sûr que de compter sur une validation humaine à chaque exécution.
En assemblant tout ça, voici un command « enquêter sur la piste d'implémentation d'un ticket Linear » :
---
description: Produire un plan d'implémentation à partir d'un ticket Linear
allowed-tools: mcp__linear__*, Task, Read, Grep, Glob, Bash(git log:*)
---
## Contexte
@.claude/context/architecture.md
@.claude/context/coding-standards.md
## État actuel de la base de code
!`git log --oneline -10`
## Tâche
Récupère la description, les commentaires et les tickets liés du ticket Linear $ARGUMENTS.
Lance ensuite deux sous-agents en parallèle :
1. Le premier : trouve dans la base de code toutes les implémentations existantes liées, les modules réutilisables
2. Le second : évalue les risques — quels chemins de code à fort trafic cette modification touche, et y a-t-il des trous dans la couverture de tests
Quand les deux sont revenus, produis :
- Les étapes d'implémentation (dans l'ordre des dépendances)
- La liste des risques
- La granularité de commits suggérée
Ne commence pas à coder.
En déclenchant /plan ENG-4213, une seule instruction fait tourner la chaîne complète : récupérer le ticket → enquête parallèle dans le code → évaluation des risques → synthèse du plan. L'utilisateur n'a plus qu'à lire la conclusion et décider de se lancer.
C'est l'arc complet des trois premiers articles de la série slash commands : définir des prompts réutilisables (intro) → injecter dynamiquement du contexte (context) → orchestrer outils et sous-agents (cet article). À ce stade, .claude/commands/ n'est plus un dossier de raccourcis : c'est la petite bibliothèque de workflows de l'équipe.