04 - Slash commands : les commandes /#

Transformer un prompt que tu retapes chaque semaine en une commande que tu invoques en trois lettres.

Temps de lecture : 13 min | Niveau : Intermediaire

Ce que tu sauras faire apres#

• Connaitre les commandes integrees qui servent vraiment tous les jours.
• Creer ta propre commande avec un fichier SKILL.md.
• Passer des arguments a ta commande et injecter la sortie d'une commande shell.
• Restreindre les outils qu'une commande peut utiliser.
• Ecrire une commande /review-sql prete a l'emploi pour tes modeles dbt.

1. Deux familles de commandes#

Quand tu tapes /, tu vois deux choses melangees :

• Les commandes integrees : elles executent une logique fixe, codee dans Claude Code. Exemples : /help, /compact, /login.
• Les skills : ce sont des prompts. Elles donnent a Claude des instructions detaillees et le laissent orchestrer le travail avec ses outils. Une skill n'est chargee en contexte que quand elle est invoquee.

Tes commandes personnalisees sont des skills. C'est ce qui rend l'extension si simple : tu ecris du Markdown, pas du code.

2. Les commandes integrees a connaitre#

Il en existe des dizaines. Voici celles qui changent ton quotidien.

Gerer le contexte#

Comprendre et configurer#

Travailler#

Divers utiles#

Les commandes ne sont reconnues qu'au debut d'un message. Tape / puis des lettres pour filtrer, et Tab pour completer.

Deux nuances honnetes.

1. Plusieurs de ces commandes ne sont pas codees en dur : ce sont des skills livrees avec Claude Code (/code-review, /security-review, /verify, /simplify, /doctor, /batch, /fewer-permission-prompts). Elles fonctionnent exactement comme celles que tu vas ecrire en section 3.
2. La disponibilite depend de ta plateforme, de ton plan et de ton environnement. La liste qui fait foi chez toi, c'est celle de /help.

3. Creer ta propre commande#

Ou mettre le fichier#

L'ancien format .claude/commands/<nom>.md fonctionne toujours, avec le meme frontmatter (sauf les champs name et paths). Le format skill est prefere parce qu'il autorise des fichiers annexes dans le dossier de la skill.

La structure minimale#

---
name: ma-commande
description: Ce que fait cette commande
---

Tes instructions pour Claude, en Markdown.

Tu l'invoques avec /ma-commande. Si tu omets name, c'est le nom du dossier qui sert.

Les champs de frontmatter les plus utiles#

Sur Windows, si tu utilises des commandes PowerShell dans ta skill, pense a shell: powershell.

Les arguments#

Tu appelles /ma-commande argument1 argument2. Dans le fichier :

Exemple avec des arguments nommes :

---
name: migre-modele
arguments: [modele, source, cible]
argument-hint: "[nom-modele] [ancienne-source] [nouvelle-source]"
---

Migre le modele $modele de la source $source vers $cible.
Reference : ${CLAUDE_PROJECT_DIR}/docs/conventions-dbt.md

Appel : /migre-modele fct_ventes raw_legacy raw_v2

Pour ecrire un vrai symbole dollar suivi d'un chiffre, echappe-le : \$1.00 donne $1.00.

Injecter la sortie d'une commande shell avec !#

C'est la fonctionnalite la plus puissante. La commande tourne avant que Claude ne voie le contenu de la skill, et sa sortie remplace le placeholder.

Forme en ligne :

## Etat actuel
!`git diff HEAD`

## Version de dbt
!`dbt --version`

Forme multi-lignes :

## Environnement
```!
git status --short
uv pip list | head -20
```

Regles a connaitre :

• Le ! doit etre en debut de ligne ou precede d'un espace.
• La sortie est inseree comme du texte brut. La substitution se fait une seule fois, la sortie n'est pas re-analysee.
• La commande est verifiee contre tes regles de permission. Une commande refusee interrompt l'invocation avec Shell command permission check failed.
• Le delai par defaut est de 2 minutes par commande.
• Un code de sortie non nul fait echouer l'invocation. Exception : le code 1 des commandes de recherche ou de comparaison (grep, find, diff, git diff) est traite comme un resultat normal. Pour les autres, ajoute || true a la fin.
• Desactivable globalement avec le reglage "disableSkillShellExecution": true.

Pre-approuver des outils avec allowed-tools#

Pour eviter une demande d'autorisation a chaque appel de ta commande :

---
name: commit
description: Prepare et cree un commit
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

L'autorisation se termine au message suivant. Tes regles deny restent prioritaires.

4. Exemple complet : /review-sql#

Une commande de revue pour tes modeles dbt. Cree .claude/skills/review-sql/SKILL.md dans ton depot et commite-le : toute l'equipe en profite.

---
name: review-sql
description: Revue d'un modele dbt : lisibilite, performance BigQuery, tests, conventions
argument-hint: "[nom-du-modele]"
disable-model-invocation: true
allowed-tools: Bash(dbt compile *) Bash(dbt ls *) Read Grep Glob
---

## Fichier a relire

Le modele demande est : $ARGUMENTS

Trouve son fichier `.sql` sous `dbt/models/` et son entree dans le `.yml` du meme dossier.

## SQL compile

!`cd dbt && dbt compile --select $ARGUMENTS --target dev 2>&1 | tail -40`

## Conventions du projet

@dbt/CONVENTIONS.md

## Ta mission

Relis le modele et produis un rapport en 4 sections, dans cet ordre.

### 1. Correction
- Jointures : y a-t-il un risque de duplication de lignes ? Verifie la cardinalite
  attendue de chaque jointure.
- `NULL` : les `LEFT JOIN` suivis d'un filtre `WHERE` sur la table de droite annulent la
  jointure externe. Signale chaque cas.
- Types : signale tout cast implicite, surtout sur les montants et les dates.
- Fuseaux : toute colonne de date doit etre en UTC.

### 2. Performance BigQuery
- Le modele scanne-t-il une table partitionnee sans filtre sur la colonne de partition ?
- Y a-t-il un `SELECT *` sur une table large ?
- Une CTE est-elle materialisee plusieurs fois alors qu'elle pourrait etre un modele
  intermediaire ?
- Ordre des jointures : la plus grosse table doit venir en premier.

### 3. Tests
- Liste les tests declares dans le `.yml`.
- Dis lesquels manquent : `unique` et `not_null` sur la cle primaire au minimum,
  `relationships` sur chaque cle etrangere, `accepted_values` sur les colonnes de statut.
- Ecris les blocs YAML manquants, prets a coller.

### 4. Conventions
- Verifie le respect de `dbt/CONVENTIONS.md` : nommage, `{{ ref() }}`, suffixes de colonnes.

## Format de sortie

Pour chaque point : le numero de ligne, le probleme en une phrase, puis le correctif en
bloc de code. Classe par gravite : BLOQUANT, IMPORTANT, MINEUR.
Si un point est correct, ne le mentionne pas. Ne fais pas de remarques de style.

Appel :

/review-sql fct_commandes

Une variante plus legere : /explique-table#

---
name: explique-table
description: Explique une table ou un modele en langage metier
argument-hint: "[nom-table-ou-modele]"
---

Table demandee : $ARGUMENTS

1. Trouve la definition : un modele dbt sous `dbt/models/`, une source dans un `.yml`,
   ou une table citee dans `src/`.
2. Explique en langage **metier**, pas technique :
   - a quelle question metier cette table repond
   - quelle est la granularite (une ligne = quoi exactement ?)
   - d'ou viennent les donnees, en remontant jusqu'aux sources brutes
   - quelles colonnes sont des cles, lesquelles sont des mesures
3. Liste les pieges : colonnes qui peuvent etre NULL, doublons possibles, colonnes
   obsoletes encore presentes.
4. Termine par trois exemples de requetes SQL typiques sur cette table.

Ecris pour quelqu'un qui connait le metier mais pas le code.

5. AVANT / APRES#

AVANT : a chaque revue, tu retapes un long prompt de memoire. Il est different a chaque fois, tu oublies la moitie des points, et ton collegue n'a pas le meme.

APRES : /review-sql fct_commandes. Toujours les memes 4 sections, le SQL compile est injecte automatiquement, et les conventions du projet sont rappelees. Le fichier est dans Git, donc toute l'equipe utilise la meme grille.

Pourquoi c'est mieux ? Tu as transforme une connaissance dans ta tete en un artefact versionne, relisable et ameliorable par l'equipe.

Template de skill pret a copier#

---
name: [NOM_DE_TA_COMMANDE]
description: [CE_QU_ELLE_FAIT_EN_UNE_PHRASE]
argument-hint: "[CE_QUE_L_UTILISATEUR_DOIT_TAPER]"
disable-model-invocation: true
allowed-tools: [OUTILS_A_PRE_APPROUVER, par exemple Bash(make test) Read Grep]
---

## Contexte automatique

!`[COMMANDE_SHELL_QUI_DONNE_LE_CONTEXTE]`

## Ta mission

Cible : $ARGUMENTS

1. [ETAPE_1]
2. [ETAPE_2]
3. [ETAPE_3]

## Format de sortie

[DECRIS_EXACTEMENT_LA_FORME_ATTENDUE]
[DIS_CE_QU_IL_NE_FAUT_PAS_FAIRE]

6. Deux details qui evitent des surprises#

Detection des changements a chaud. Claude Code surveille les dossiers de skills pendant la session : ~/.claude/skills/, .claude/skills/ du projet, et ceux des dossiers ajoutes avec --add-dir. Seuls les changements de texte dans SKILL.md sont detectes. Si tu crees un dossier de skills qui n'existait pas au demarrage, lance /reload-skills.

Conflits de noms. Quand plusieurs skills ont le meme nom, l'ordre est : entreprise > personnel > projet. Une skill locale remplace une skill fournie par defaut. Une skill de plugin est accessible sous /nom-plugin:nom-skill.

A retenir#

• Les commandes integrees executent une logique fixe ; tes commandes sont des skills, du simple Markdown.
• Une commande vit dans ~/.claude/skills/<nom>/SKILL.md (personnel) ou .claude/skills/<nom>/SKILL.md (projet, commite).
• $ARGUMENTS, $1, $nom passent des arguments ; ! en debut de ligne injecte la sortie d'une commande shell.
• allowed-tools pre-approuve des outils pour le tour ; disable-model-invocation: true reserve la commande a toi.
• Une commande commitee dans Git, c'est une grille de revue partagee par toute l'equipe.
• /reload-skills si tu viens de creer un dossier de skills en cours de session.

Sources#

• Claude Code - Extend Claude with skills
• Claude Code - Commands (liste complete)
• Claude Code - Best practices
• Claude Code - Configure permissions
• Claude Code - Run parallel sessions with worktrees

Liens verifies le 26 septembre 2026. Note : /docs/en/slash-commands renvoie desormais vers la page Skills ci-dessus, c'est pourquoi elle n'apparait qu'une fois.