Commandes personnalisées et skills - Exemples

Les commandes personnalisées, skills et hooks de Claude Code transforment votre terminal en environnement de développement intelligent. Voici 10 exemples concrets - du slash command basique au subagent orchestré - que vous pouvez copier et adapter à vos projets dès maintenant.

Les commandes personnalisées et skills de Claude Code constituent un système d'extensibilité qui permet d'automatiser des workflows récurrents directement depuis le terminal. Claude Code v2.1 propose trois mécanismes complémentaires : les commandes slash custom, les skills déclaratives et les hooks déterministes. plus de 68 % des utilisateurs avancés créent au moins une commande personnalisée dans leur première semaine d'utilisation.

Comment créer votre première commande slash custom ?

Une commande slash custom est un fichier Markdown stocké dans .claude/commands/ qui encapsule un prompt réutilisable. Vous la déclenchez avec / suivi du nom du fichier, sans extension.

Créez le répertoire de commandes si nécessaire, puis ajoutez votre premier fichier. Cette commande génère un composant React à partir d'une description :

mkdir -p .claude/commands

# .claude/commands/react-component.md
Génère un composant React TypeScript fonctionnel.
Contraintes :
- Utilise des hooks (useState, useEffect) si nécessaire
- Ajoute les types TypeScript pour toutes les props
- Inclus un export par défaut
- Suis les conventions du projet dans src/components/

Composant demandé : $ARGUMENTS

Exécutez ensuite dans Claude Code :

/react-component un bouton de confirmation avec état loading

Le résultat attendu : Claude génère un fichier ConfirmButton.tsx avec typage complet, gestion de l'état loading via useState, et export par défaut. Le temps de génération moyen est de 4 à 8 secondes.

Pour approfondir la syntaxe des commandes slash, consultez le guide des commandes slash essentielles en exemples qui couvre les variables disponibles.

À retenir : une commande slash custom est un fichier Markdown dans .claude/commands/ - un prompt réutilisable déclenché par /nom-du-fichier.

Comment automatiser la revue de code avec une commande slash ?

La revue de code manuelle consomme en moyenne 45 minutes par pull request selon une étude GitHub (2024). Une commande slash dédiée réduit ce temps à 2-3 minutes pour un premier passage automatisé.

Créez cette commande de revue de code :

# .claude/commands/review.md
Analyse le diff Git actuel et fournis une revue de code structurée.

Étapes :
1. Exécute `git diff --staged` pour voir les changements
2. Vérifie : bugs potentiels, failles de sécurité, problèmes de performance
3. Contrôle la cohérence avec les patterns existants du projet
4. Propose des améliorations concrètes avec extraits de code

Format de sortie :
- 🔴 Bloquant : [problème + correction]
- 🟡 Suggestion : [amélioration + code]
- 🟢 Approuvé : [ce qui est bien fait]

Fichiers à ignorer : $ARGUMENTS

Lancez la revue avant chaque commit :

git add -A && /review *.test.ts

Résultat attendu : un rapport structuré en trois niveaux de sévérité, avec des suggestions de code concrètes. En pratique, cette commande détecte 3 à 5 problèmes par revue que l'œil humain manque souvent.

Si vous rencontrez des erreurs lors de l'exécution, consultez le guide des erreurs courantes des commandes personnalisées pour les résoudre.

À retenir : une commande /review bien configurée remplace le premier passage de revue manuelle et produit un rapport en moins de 3 minutes.

Quels sont les exemples de commandes slash pour la documentation ?

Documenter du code reste la tâche la plus négligée : selon Stack Overflow (2024), 62 % des développeurs la reportent systématiquement. Une commande slash dédiée élimine cette friction.

# .claude/commands/doc-api.md
Génère la documentation d'API pour le fichier spécifié.

Instructions :
1. Lis le fichier $ARGUMENTS
2. Identifie chaque fonction/méthode exportée
3. Génère un JSDoc/TSDoc complet avec :
   - Description en une phrase
   - @param avec types et descriptions
   - @returns avec type et cas d'erreur
   - @example avec un cas d'usage réaliste
   - @throws si applicable
4. Écris la documentation directement dans le fichier source

Exécutez la commande sur un fichier cible :

/doc-api src/lib/auth.ts

Vous pouvez personnaliser cette commande pour d'autres formats. Remplacez JSDoc par des docstrings Python ou des commentaires GoDoc selon votre stack. Pour gérer le contexte de vos fichiers volumineux, le guide de gestion du contexte avec des exemples vous sera utile.

À retenir : la commande /doc-api standardise la documentation de vos fichiers en 30 secondes au lieu de 15 minutes manuelles.

Comment configurer des skills pour que Claude apprenne vos patterns ?

Un skill est un fichier de configuration YAML ou Markdown placé dans .claude/skills/ qui enseigne à Claude Code les conventions spécifiques de votre projet. Concrètement, un skill décrit un pattern que Claude doit reproduire automatiquement.

# .claude/skills/api-route.md
Quand je demande de créer une route API Next.js :
1. Crée le fichier dans app/api/[nom]/route.ts
2. Utilise toujours ce pattern :

typescript

import { NextRequest, NextResponse } from 'next/server'

export async function GET(request: NextRequest) { try { // Logique métier ici return NextResponse.json({ data }, { status: 200 }) } catch (error) { console.error('[API_NAME]', error) return NextResponse.json( { error: 'Internal server error' }, { status: 500 } ) } }

3. Ajoute toujours le logging avec le nom de la route en préfixe
4. Retourne des objets { data } ou { error }, jamais de valeurs nues
5. Utilise les types NextRequest/NextResponse, pas Request/Response

Après création de ce skill, chaque fois que vous demandez « crée une route API pour les utilisateurs », Claude Code applique automatiquement ce pattern. Le gain mesuré est de 85 % de cohérence en plus sur les routes API d'un projet.

Pour aller plus loin avec les skills, la référence complète des commandes personnalisées et skills détaille toutes les options de configuration.

À retenir : un skill est un fichier qui encode vos conventions - Claude le lit et applique vos patterns à chaque nouvelle génération.

Comment utiliser les subagents pour orchestrer des tâches complexes ?

Un subagent est une instance de Claude Code lancée par une autre instance, via l'outil Task. Cette architecture permet de paralléliser des opérations indépendantes et de protéger le contexte principal. En pratique, un subagent traite une sous-tâche isolée et renvoie un résultat synthétique.

Créez une commande qui orchestre trois subagents en parallèle :

# .claude/commands/full-feature.md
Pour implémenter la feature "$ARGUMENTS", lance 3 agents en parallèle :

Agent 1 - Recherche :
- Type : Explore
- Mission : Trouver les fichiers pertinents et les patterns existants

Agent 2 - Tests :
- Type : general-purpose
- Mission : Écrire les tests unitaires AVANT l'implémentation

Agent 3 - Implémentation :
- Type : general-purpose
- Mission : Implémenter la feature en suivant les patterns trouvés par Agent 1
- Dépend de : Agent 1

Coordination : attendre Agent 1 avant de lancer Agent 3.
Agent 2 peut démarrer immédiatement.

/full-feature endpoint CRUD pour la gestion des factures

La parallélisation réduit le temps total de 35 à 40 % sans augmenter la consommation de tokens. les subagents partagent le même modèle mais disposent chacun de leur propre fenêtre de contexte de 200 000 tokens.

Pour maîtriser les bases avant d'orchestrer des subagents, suivez le tutoriel d'installation et premier lancement de Claude Code.

À retenir : les subagents parallélisent le travail et réduisent le temps d'exécution de 35-40 % pour les tâches multi-étapes.

Comment configurer des hooks pour automatiser des actions déterministes ?

Un hook est un script shell exécuté automatiquement en réponse à un événement Claude Code. Contrairement aux skills (probabilistes), les hooks sont déterministes : ils se déclenchent à chaque fois, sans exception. Vous les configurez dans .claude/settings.json.

// .claude/settings.json
{
  "hooks": {
    "post-tool-use": [
      {
        "tool": "Write",
        "pattern": "*.ts",
        "command": "npx eslint --fix $FILE_PATH"
      }
    ],
    "pre-tool-use": [
      {
        "tool": "Bash",
        "command": "echo 'Commande exécutée : $TOOL_INPUT' >> .claude/audit.log"
      }
    ]
  }
}

Ce hook exécute ESLint automatiquement après chaque écriture de fichier TypeScript. Le deuxième hook journalise toutes les commandes Bash dans un fichier d'audit.

Vérifiez que vos hooks fonctionnent :

# Testez en demandant à Claude Code d'écrire un fichier .ts
# Le hook post-tool-use doit déclencher eslint --fix automatiquement

En pratique, un hook post-tool-use sur ESLint corrige 90 % des erreurs de style automatiquement, avant même que vous ne relisiez le code.

Le guide des astuces pour les commandes personnalisées propose d'autres patterns de hooks avancés.

À retenir : un hook est un script déterministe déclenché par un événement - utilisez-le pour le formatage, le linting et l'audit automatiques.

Quels hooks avancés permettent de sécuriser votre workflow ?

Les hooks de sécurité ajoutent une couche de protection déterministe à votre environnement Claude Code. Configurez un hook qui bloque les commandes destructrices :

{
  "hooks": {
    "pre-tool-use": [
      {
        "tool": "Bash",
        "command": "if echo \"$TOOL_INPUT\" | grep -qE 'rm -rf|drop table|force push'; then echo 'BLOCKED: commande dangereuse détectée' && exit 1; fi"
      },
      {
        "tool": "Write",
        "pattern": ".env*",
        "command": "echo 'BLOCKED: modification de .env interdite' && exit 1"
      }
    ]
  }
}

Ce hook intercepte trois catégories de commandes dangereuses et empêche toute modification des fichiers .env. Le code de sortie exit 1 annule l'opération.

Ajoutez un hook de notification Slack pour les opérations sensibles :

{
  "hooks": {
    "post-tool-use": [
      {
        "tool": "Bash",
        "pattern": "git push*",
        "command": "curl -s -X POST $SLACK_WEBHOOK -d '{\"text\": \"Push effectué par Claude Code sur '$(git branch --show-current)'\"}'"
      }
    ]
  }
}

Concrètement, ce hook envoie une notification Slack à chaque git push effectué par Claude Code, avec le nom de la branche concernée.

Pour intégrer vos hooks avec Git, le guide d'intégration Git en exemples montre des workflows complets.

À retenir : les hooks pre-tool-use avec exit 1 bloquent les opérations dangereuses - c'est votre filet de sécurité déterministe.

Comment combiner skills et commandes pour un workflow complet ?

La combinaison de skills, commandes et hooks forme un pipeline de développement automatisé. Voici un exemple complet pour un projet Next.js 15 avec TypeScript 5.4.

Étape 1 - Créez le skill de conventions :

# .claude/skills/project-conventions.md
Conventions du projet :
- Framework : Next.js 15 App Router
- Langage : TypeScript 5.4 strict
- Style : Prettier + ESLint flat config
- Tests : Vitest avec couverture > 80 %
- Nommage : camelCase pour les variables, PascalCase pour les composants
- Imports : chemins absolus avec alias @/

Étape 2 - Créez la commande de feature complète :

# .claude/commands/feature.md
Implémente la feature "$ARGUMENTS" en suivant ce workflow :

1. Crée la branche feature/$ARGUMENTS_SLUG
2. Implémente les fichiers nécessaires (respecte le skill project-conventions)
3. Écris les tests Vitest correspondants
4. Exécute les tests et corrige les erreurs
5. Formate avec Prettier
6. Crée un résumé des changements

Ne commite pas - laisse-moi vérifier d'abord.

Étape 3 - Configurez les hooks d'accompagnement :

{
  "hooks": {
    "post-tool-use": [
      {
        "tool": "Write",
        "pattern": "*.{ts,tsx}",
        "command": "npx prettier --write $FILE_PATH"
      }
    ]
  }
}

Lancez le pipeline complet :

/feature panier d'achat avec gestion des quantités

Résultat attendu : Claude crée la branche, génère 4-6 fichiers (composants, route API, tests), exécute Vitest, et formate le tout. Le temps total est de 60 à 90 secondes pour une feature complète.

SFEIR Institute propose la formation Claude Code en une journée pour maîtriser ces workflows d'automatisation avec des labs pratiques sur les commandes, skills et hooks.

À retenir : la combinaison skill + commande + hook crée un pipeline automatisé de bout en bout - de la branche Git au code formaté et testé.

Comment partager vos commandes en équipe via un dépôt centralisé ?

Les commandes personnalisées fonctionnent à deux niveaux : local (.claude/commands/) et projet. Pour standardiser les pratiques d'une équipe, stockez vos commandes dans le dépôt Git du projet.

# Structure recommandée pour une équipe
mkdir -p .claude/commands

# .claude/commands/team-pr.md
Prépare une pull request en suivant le template de l'équipe.

1. Exécute `git diff main...HEAD` pour lister les changements
2. Génère un titre suivant le format : type(scope): description
   Types valides : feat, fix, refactor, docs, test, chore
3. Rédige la description avec :
   - ## Contexte (pourquoi ce changement)
   - ## Changements (liste des modifications)
   - ## Tests (comment tester)
   - ## Checklist
     - [ ] Tests ajoutés/modifiés
     - [ ] Documentation mise à jour
     - [ ] Pas de console.log restant
4. Crée la PR avec `gh pr create`

En pratique, une équipe de 8 développeurs qui partage 5 commandes standardisées réduit de 25 % le temps de revue de code grâce à la cohérence des outputs.

Pour démarrer rapidement avec Claude Code, consultez le guide de démarrage rapide qui couvre l'installation et la configuration initiale.

À retenir : versionnez vos commandes dans .claude/commands/ au niveau projet pour que toute l'équipe bénéficie des mêmes automatisations.

Quels patterns avancés permettent de créer des commandes conditionnelles ?

Les commandes avancées utilisent la variable $ARGUMENTS et des instructions conditionnelles pour adapter leur comportement. Créez une commande polymorphe qui détecte le type de fichier :

# .claude/commands/improve.md
Améliore le fichier $ARGUMENTS selon son type :

Si c'est un fichier .ts ou .tsx :
- Renforce le typage (remplace `any` par des types précis)
- Ajoute des guards clauses
- Optimise les re-renders si composant React

Si c'est un fichier .test.ts :
- Augmente la couverture (vise 90 %+)
- Ajoute des cas limites (null, undefined, tableau vide)
- Utilise des test.each pour les cas paramétriques

Si c'est un fichier .md :
- Corrige la grammaire et l'orthographe
- Vérifie les liens Markdown
- Améliore la structure (H2/H3 cohérents)

Dans tous les cas : montre un diff résumé avant d'appliquer.

/improve src/components/UserProfile.tsx
/improve src/lib/auth.test.ts
/improve README.md

les commandes conditionnelles représentent 40 % des commandes créées par les utilisateurs expérimentés. La variable $ARGUMENTS accepte des chemins de fichiers, des descriptions textuelles ou des flags.

Vous pouvez combiner cette approche avec les exemples de vos premières conversations avec Claude Code pour des résultats encore plus ciblés.

Pour aller plus loin, la formation Développeur Augmenté par l'IA de SFEIR Institute consacre 2 jours à la maîtrise des workflows IA, dont un module complet sur les commandes personnalisées et les subagents.

À retenir : utilisez $ARGUMENTS et des instructions conditionnelles pour créer des commandes polymorphes qui s'adaptent au type de fichier traité.

Comment déboguer et tester vos commandes personnalisées ?

Le débogage des commandes custom nécessite une approche méthodique. Vérifiez d'abord que Claude Code détecte vos commandes :

# Listez les commandes disponibles dans Claude Code
# Tapez "/" dans le prompt pour voir l'autocomplétion

Si votre commande n'apparaît pas, contrôlez ces points :

1. Le fichier est bien dans .claude/commands/ (pas dans un sous-dossier)
2. L'extension est .md (pas .txt ou .yaml)
3. Le nom de fichier ne contient pas d'espaces (utilisez des tirets)
4. Les permissions du fichier autorisent la lecture (chmod 644)

Testez votre commande avec un cas minimal :

# Commande de test
/ma-commande argument-simple

# Si erreur, vérifiez le fichier
cat .claude/commands/ma-commande.md

Concrètement, 80 % des problèmes de commandes custom viennent d'un emplacement incorrect du fichier Markdown ou d'un oubli de l'extension .md.

La FAQ des commandes personnalisées et skills répond aux questions les plus fréquentes sur la résolution de problèmes.

À retenir : tapez / pour vérifier la détection, puis testez avec un argument minimal - 80 % des erreurs sont liées à l'emplacement du fichier.

Faut-il investir dans les commandes avancées pour votre équipe ?

La formation Développeur Augmenté par l'IA – Avancé d'une journée chez SFEIR Institute couvre les subagents, les hooks de sécurité et l'orchestration multi-agents avec des exercices pratiques sur vos propres projets.

Les commandes personnalisées, skills et hooks forment un écosystème d'extensibilité qui mûrit avec votre usage de Claude Code. Voici un récapitulatif des mécanismes et de leurs cas d'usage :

En 2026, l'écosystème de plugins et marketplaces continue de se développer. Les registres communautaires comme claude-commands sur npm comptent plus de 1 200 commandes partagées. Explorez ces ressources pour accélérer votre démarrage.

Pour les compléments sur les astuces d'optimisation, consultez les astuces pour les commandes personnalisées et skills et les exemples d'intégration Git.

À retenir : commencez par une commande slash simple, ajoutez un skill pour vos conventions, puis sécurisez avec des hooks - l'adoption progressive garantit un ROI mesurable dès la première semaine.