Commandes personnalisées et skills - Aide-mémoire

Cet aide-mémoire regroupe toutes les syntaxes pour créer vos propres commandes slash, configurer des skills réutilisables, orchestrer des subagents et automatiser vos workflows Claude Code avec des hooks. Consultez cette fiche pratique pour maîtriser les commandes personnalisées, les skills et l'extensibilité de Claude Code en quelques minutes.

Les commandes personnalisées et skills dans Claude Code constituent le système d'extensibilité qui permet d'adapter l'agent IA à vos workflows spécifiques. Claude Code propose quatre mécanismes complémentaires : les commandes slash custom, les skills, les subagents et les hooks.

Quelles sont les commandes personnalisées les plus utilisées dans Claude Code ?

Les commandes slash custom étendent le jeu de commandes intégrées. Chaque commande correspond à un fichier Markdown stocké dans .claude/commands/ (projet) ou ~/.claude/commands/ (global). Notez que les commandes personnalisées ont été fusionnées dans les skills : .claude/commands/.md reste pris en charge comme forme historique, tandis que .claude/skills//SKILL.md est le mécanisme documenté actuel (les deux créent une commande /nom). Consultez la référence complète des commandes pour la liste exhaustive des commandes intégrées.

En pratique, une commande slash custom réduit un prompt de 200 mots à 2 mots. La fiche des commandes slash essentielles couvre les commandes intégrées en détail.

À retenir : chaque commande slash custom est un fichier Markdown dans .claude/commands/ qui encapsule un prompt réutilisable.

Comment créer une commande slash personnalisée étape par étape ?

Une commande personnalisée est un fichier Markdown dont le nom devient le suffixe de la commande. Créez le répertoire .claude/commands/ à la racine de votre projet si ce n'est pas déjà fait.

Structure du fichier de commande

# Créer le répertoire de commandes projet
mkdir -p .claude/commands

# Créer une commande /review
touch .claude/commands/review.md

Le contenu du fichier Markdown constitue le prompt envoyé à Claude Code. Vous pouvez utiliser la variable $ARGUMENTS pour capturer les arguments passés après la commande.

<!-- .claude/commands/review.md -->
Analyse le fichier $ARGUMENTS et fournis :
1. Les bugs potentiels
2. Les problèmes de performance
3. Les suggestions d'amélioration
Réponds en français avec des exemples de code corrigé.

Portée projet vs globale

Exécutez votre commande en tapant /review src/auth.ts dans le prompt Claude Code. La commande accepte tous les arguments textuels après le nom. Concrètement, le fichier fait entre 5 et 500 lignes selon la complexité du prompt.

Pour éviter les erreurs courantes lors de la création, consultez le guide des erreurs fréquentes qui détaille les pièges classiques.

À retenir : nommez vos fichiers de commande avec des noms courts et explicites, car le nom du fichier devient la commande.

Comment fonctionnent les skills pour que l'IA apprenne vos patterns ?

Les skills représentent un niveau au-dessus des commandes slash : ce sont des capacités réutilisables que Claude Code peut charger selon le contexte. Un skill se définit dans un fichier SKILL.md placé dans un sous-dossier dédié de .claude/skills/, et s'invoque ensuite comme une commande slash /nom-du-skill.

À ne pas confondre avec le fichier CLAUDE.md, qui relève du système de mémoire : il contient les instructions et conventions du projet, chargées automatiquement à chaque session.

Définir un skill

# Skill projet : créer le dossier puis le fichier SKILL.md
mkdir -p .claude/skills/revue-typescript
touch .claude/skills/revue-typescript/SKILL.md

Le fichier CLAUDE.md, distinct des skills, se place à la racine du projet (./CLAUDE.md ou ./.claude/CLAUDE.md) et décrit vos conventions d'équipe. La mémoire automatique constitue un troisième mécanisme : Claude Code conserve un store par projet dans ~/.claude/projects//memory/MEMORY.md, séparé des skills.

les skills réduisent significativement le nombre de corrections manuelles sur les projets qui les adoptent. Vérifiez que votre fichier SKILL.md contient des instructions claires et concises ainsi qu'une description précise du déclencheur.

La page dédiée aux commandes personnalisées et skills approfondit la mécanique de chargement contextuel des skills.

Bonnes pratiques pour les skills

• Soyez spécifique : "Utilise vitest pour les tests" plutôt que "utilise un bon framework de test"
• Donnez des exemples : incluez des blocs de code montrant le pattern attendu
• Limitez la taille : visez 50 à 200 lignes par fichier pour un chargement rapide
• Structurez par thème : séparez les conventions de nommage, les patterns d'architecture et les règles de test

À retenir : un skill se définit dans .claude/skills//SKILL.md et s'invoque par / ; le fichier CLAUDE.md relève quant à lui de la mémoire du projet, pas des skills.

Comment orchestrer des subagents dans Claude Code ?

Les subagents sont des instances autonomes de Claude lancées par l'agent principal via l'outil Agent (l'ancien nom Task reste accepté comme alias). Chaque subagent dispose de son propre contexte et de ses propres outils. Utilisez les subagents pour paralléliser des tâches indépendantes comme la recherche et l'implémentation.

Types de subagents disponibles

Comment invoquer un subagent

Vous ne « codez » pas l'appel : il suffit de décrire la tâche et Claude délègue automatiquement au subagent intégré le plus adapté. Vous pouvez aussi cibler explicitement un subagent en le mentionnant avec @agent- :

@agent-explore trouve toutes les routes API qui utilisent l'authentification

En pratique, un subagent Explore parcourt rapidement un dépôt volumineux sans charger l'intégralité des fichiers dans le contexte principal. Claude peut exécuter plusieurs subagents en parallèle pour des tâches indépendantes ; pour une parallélisation soutenue au-delà d'une session, appuyez-vous sur les agent teams.

Concrètement, les subagents protègent le contexte principal : un subagent de recherche qui lit 200 fichiers ne pollue pas la fenêtre de contexte de l'agent parent.

Pour comprendre comment gérer efficacement le contexte entre agent principal et subagents, consultez le guide de gestion du contexte.

À retenir : les subagents parallélisent le travail et protègent votre fenêtre de contexte. Utilisez Explore pour la recherche et general-purpose pour l'implémentation.

Quels hooks permettent d'automatiser les workflows de manière déterministe ?

Les hooks sont des commandes shell exécutées automatiquement en réponse à des événements Claude Code. Contrairement aux skills (probabilistes), les hooks sont déterministes : ils s'exécutent à chaque fois, sans exception. Configurez vos hooks dans le fichier .claude/settings.json.

Configuration des hooks

La structure comporte trois niveaux : l'événement, un tableau de groupes par matcher, et un tableau hooks de gestionnaires (chacun avec un champ type).

{
 "hooks": {
 "PostToolUse": [
 {
 "matcher": "Edit",
 "hooks": [
 {
 "type": "command",
 "command": "npx eslint --fix \"$(jq -r '.tool_input.file_path')\""
 }
 ]
 }
 ],
 "PreToolUse": [
 {
 "matcher": "Bash",
 "hooks": [
 {
 "type": "command",
 "command": "echo 'Commande Bash détectée'"
 }
 ]
 }
 ]
 }
}

Un hook ne reçoit pas de variables comme $CLAUDE_FILE_PATH : Claude Code lui transmet un objet JSON sur l'entrée standard (stdin). Lisez-y les champs dont vous avez besoin avec jq, par exemple tool_name=$(jq -r '.tool_name') ou file_path=$(jq -r '.tool_input.file_path').

Événements hook disponibles

les hooks PostToolUse réduisent très significativement les allers-retours de correction de linting. Lancez un test rapide en ajoutant un hook de logging pour vérifier que la configuration fonctionne.

La gestion des permissions lors de l'exécution des hooks est détaillée dans l'aide-mémoire permissions et sécurité. Pour combiner hooks et commandes Git, consultez l'aide-mémoire intégration Git.

À retenir : les hooks garantissent une exécution déterministe. Utilisez-les pour le linting automatique, le logging et les validations obligatoires.

Comment étendre Claude Code avec des plugins et le MCP ?

Le Model Context Protocol (MCP) est le standard ouvert d'Anthropic pour connecter Claude Code à des outils externes. MCP permet d'ajouter des serveurs qui exposent des outils, des ressources et des prompts supplémentaires.

Configuration MCP

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "/chemin/vers/projet"]
 },
 "memory": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-memory"]
 }
 }
}

Placez cette configuration dans .mcp.json à la racine du projet (portée projet, partagée via Git) ou ajoutez le serveur avec claude mcp add pour une portée locale/utilisateur (stockée dans ~/.claude.json). Le fichier settings.json n'est pas un emplacement valide pour mcpServers. L'écosystème MCP compte des centaines de serveurs communautaires couvrant les bases de données, les API cloud et les outils DevOps.

Note : les serveurs server-filesystem, server-memory et server-everything font partie des serveurs de référence toujours maintenus dans le dépôt officiel. Les anciens exemples server-github, server-postgres et server-brave-search ont été déplacés vers les serveurs de référence archivés et ne sont plus les cibles d'installation recommandées. Pour les paquets à jour, consultez le registre officiel des serveurs MCP (github.com/modelcontextprotocol/servers).

Pour commencer avec les exemples de commandes personnalisées, vous trouverez des configurations MCP prêtes à l'emploi.

À retenir : MCP connecte Claude Code à n'importe quel outil externe via un protocole standardisé. Commencez par un serveur de référence maintenu comme server-filesystem pour un gain immédiat, puis consultez le registre officiel pour les serveurs adaptés à vos besoins.

Quels raccourcis clavier accélèrent le travail avec les commandes ?

Mémorisez ces raccourcis pour naviguer efficacement dans Claude Code. Ces combinaisons fonctionnent dans le terminal interactif de Claude Code.

SFEIR Institute propose la formation Claude Code sur une journée : vous y pratiquerez la création de commandes slash, la configuration de skills et l'orchestration de subagents sur des cas réels. Pour aller plus loin, la formation Développeur Augmenté par l'IA couvre en 2 jours l'intégration complète de l'IA dans votre workflow de développement, y compris les hooks et les pipelines CI/CD augmentés.

Consultez l'aide-mémoire d'installation pour vérifier que votre environnement est correctement configuré avant de personnaliser vos commandes.

À retenir : /compact et Échap sont les deux raccourcis les plus utiles au quotidien ; le premier gère le contexte, le second interrompt une génération non pertinente.

Comment structurer un projet avec commandes, skills et hooks combinés ?

Voici l'arborescence recommandée pour un projet qui exploite pleinement l'extensibilité de Claude Code. Organisez vos fichiers selon cette structure dès le premier jour.

mon-projet/
├── .mcp.json # Serveurs MCP (portée projet)
├── .claude/
│ ├── CLAUDE.md # Mémoire projet (conventions globales)
│ ├── settings.json # Hooks
│ ├── skills/
│ │ └── revue-typescript/
│ │ └── SKILL.md # /revue-typescript
│ └── commands/
│ ├── review.md # /review (forme historique)
│ ├── test.md # /test
│ ├── deploy.md # /deploy
│ └── changelog.md # /changelog
├── src/
│ └── components/
│ └── .claude/
│ └── CLAUDE.md # Mémoire répertoire (patterns React)
└── ...

Concrètement, cette structure n'ajoute que quelques fichiers texte légers à votre dépôt et se versionne avec Git comme n'importe quel fichier de configuration. Le fichier settings.json reste léger : sa taille dépend du nombre de hooks et de règles de permissions que vous y déclarez.

Pour maîtriser vos premières conversations avec cette configuration en place, la prise en main devient nettement plus rapide.

Si vous souhaitez approfondir ces techniques avec des exercices pratiques, la formation Développeur Augmenté par l'IA – Avancé de SFEIR consacre une demi-journée à la création de workflows personnalisés avec skills, hooks et subagents.

À retenir : regroupez commandes, skills et hooks dans .claude/ à la racine, puis versionnez tout avec Git pour partager les conventions avec votre équipe.

Quelles sont les erreurs à éviter avec les commandes personnalisées ?

Vérifiez ces points avant de déployer vos commandes custom en équipe. Les erreurs les plus fréquentes concernent le nommage des fichiers et la syntaxe des variables.

• Erreur de nommage : le fichier mon-review.md crée la commande /mon-review (le nom du fichier sans l'extension .md)
• Variable oubliée : $ARGUMENTS est sensible à la casse - $arguments ne fonctionne pas
• Fichier trop long : un prompt de plus de 2 000 mots consomme du contexte inutilement - visez 100 à 300 mots
• Hook qui bloque : un hook PreToolUse qui se termine avec le code de sortie 2 bloque l'outil. Les autres codes non nuls, dont 1 (le code d'échec Unix classique), sont des erreurs non bloquantes et l'outil s'exécute quand même. Pour imposer une politique, utilisez exit 2, et testez toujours en isolation d'abord
• MCP sans token : oublier la variable d'environnement GITHUB_TOKEN fait échouer silencieusement le serveur MCP
• Skill contradictoire : deux fichiers CLAUDE.md avec des instructions opposées créent un comportement imprévisible

Le guide complet des erreurs courantes détaille chacun de ces cas avec les solutions associées. En pratique, la grande majorité des problèmes se résolvent en vérifiant le chemin du fichier et la syntaxe de $ARGUMENTS.

À retenir : testez chaque commande en isolation avant de la partager ; un fichier mal nommé ou un hook défaillant peut bloquer tout le workflow.