Fonctionnalités avancées : skills, subagents, hooks et settings

La différence entre utiliser Claude Code comme une fenêtre de chat dans votre terminal et le faire tourner comme un environnement d'ingénierie configuré tient à cinq fonctionnalités : les slash commands personnalisées et les Skills, les subagents pour le travail en parallèle, les hooks qui déclenchent vos scripts sur des événements, les serveurs MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète → branchés sur votre projet, et le settings.json qui gouverne l'ensemble. Cette leçon entre dans le détail de chacune.

Slash commands et Skills

Vous savez déjà que Claude Code embarque des slash commands intégrées comme /clear et /init. Le vrai levier, c'est d'écrire les vôtres.

Une slash command personnalisée n'est qu'un fichier Markdown. Déposez un fichier dans .claude/commands/<nom>.md dans votre repo et il devient /<nom> dans ce projet. Placez-le dans ~/.claude/commands/ et il fonctionne partout. Le corps du fichier est le prompt ; Claude l'exécute avec le contexte de votre projet attaché.

Voici un review.md qui donne à l'équipe une passe de code review cohérente :

---
description: Review staged changes for bugs, security issues, and style
allowed-tools: Bash(git diff:*), Read
---

Review the staged diff below. Flag:
1. Logic bugs and edge cases
2. Security issues (injection, secrets, auth gaps)
3. Style deviations from CLAUDE.md

Be terse. Cite file:line. Skip praise.

Staged changes:
!`git diff --cached`

Deux choses à remarquer. Le préfixe ! exécute une commande shell et injecte sa sortie dans le prompt. Le frontmatter allowed-tools cadre ce que cette commande peut toucher, de sorte que /review ne peut pas dériver et modifier des fichiers. Vous pouvez aussi passer des arguments avec $ARGUMENTS ou en positionnel $1, $2.

Les Skills sont la cousine plus lourde et réutilisable. Une Skill est un dossier contenant un SKILL.md plus les scripts, templates ou documents de référence que Claude doit charger quand la tâche l'exige. Là où une slash command est un prompt que vous déclenchez manuellement, une Skill est une capacité packagée que Claude mobilise automatiquement quand elle est pertinente : pensez à « remplir notre template de facture » ou « générer un PDF à partir de ces données ». Le même format de Skills fonctionne dans Claude Code, les applications Claude et l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →, donc une Skill que vous construisez une fois vous suit partout. Voir la présentation officielle sur docs.claude.com/en/docs/agents-and-tools/agent-skills.

Règle empirique : optez pour une slash command quand c'est *vous* qui décidez du moment de l'exécution. Construisez une Skill quand vous voulez que Claude décide, et quand la capacité a besoin de fichiers et de scripts embarqués.

Les subagents pour le travail en parallèle

Un subagent est une instance Claude séparée, avec sa propre fenêtre de contexte, son propre system promptsystem promptLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → et son propre jeu d'outils restreint, lancée par votre session principale pour traiter une tâche ciblée. L'enjeu est l'isolation : le subagent absorbe une tâche bruyante (lire 40 fichiers, exécuter une suite de tests) et ne renvoie que la conclusion, de sorte que votre contexte principal reste propre.

Vous définissez les subagents comme les commandes, avec des fichiers Markdown dans .claude/agents/. Chacun déclare un nom, une description qui indique à Claude *quand* lui déléguer, et les outils qu'il est autorisé à utiliser.

---
name: test-runner
description: Runs the test suite and diagnoses failures. Use after code changes.
tools: Bash, Read, Grep
---

You are a test specialist. Run the project's test command, read failing
output, locate the root cause, and report a concise fix. Do not edit
files unless explicitly asked.

Désormais votre session principale peut déléguer : « utilise le test-runner pour vérifier ça ». Claude lit la description, fait correspondre la tâche et délègue. Comme le subagent a sa propre fenêtre, un millier de lignes de stack traces ne pollue jamais votre conversation principale.

Le vrai levier, c'est le parallélisme. Vous pouvez demander à Claude de répartir le travail sur plusieurs subagents en même temps : un qui audite les dépendances, un qui écrit la doc, un qui refactorise un module. Ils tournent indépendamment et rendent compte. C'est le même pattern de délégation que le Claude Agent SDK expose de façon programmatique, piloté ici depuis le terminal. Gardez des attributions d'outils étroites par subagent ; un rédacteur de doc n'a rien à faire avec Bash.

Des hooks qui exécutent vos scripts sur événements

Les subagents et les commandes, vous les invoquez. Les hooks, c'est l'inverse : des commandes shell que Claude Code exécute *automatiquement* à des points définis de son cycle de vie, sans qu'on le lui demande. C'est ainsi que vous imposez des règles au lieu d'espérer que Claude les suive.

Les événements clés du cycle de vie :

• PreToolUse : avant l'exécution d'un outil (vous pouvez le bloquer)
• PostToolUse : après le succès d'un outil
• UserPromptSubmit : quand vous appuyez sur entrée
• Stop : quand Claude termine sa réponse
• SessionStart : à l'ouverture d'une session

Le cas d'usage classique : formater automatiquement chaque fichier que Claude modifie. Ajoutez ceci à votre settings.json :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "prettier --write \"$CLAUDE_FILE_PATHS\" 2>/dev/null"
          }
        ]
      }
    ]
  }
}

Après que Claude a modifié ou écrit un fichier, Prettier le formate. Claude n'a jamais à se souvenir de vos règles de style parce que le hook les rend non négociables. Le matcher est une regex appliquée aux noms d'outils, et Claude Code passe le contexte (comme les chemins des fichiers modifiés) via des variables d'environnement.

PreToolUse est encore plus puissant parce qu'il peut bloquer. Un hook qui sort avec un statut non nul sur PreToolUse annule l'appel de l'outil. Les équipes s'en servent pour interdire les modifications dans secrets/, bloquer git push --force, ou exiger un lint réussi avant un commit. Le hook est votre garde-fou, exécuté de façon déterministe en dehors du jugement du modèle.

Une mise en garde : les hooks exécutent de vraies commandes shell avec vos permissions. Lisez ce que vous collez. Un hook venant d'un repo non fiable peut faire tout ce que vous pouvez faire. La référence complète des événements et le JSON que vos hooks peuvent émettre sont sur docs.claude.com/en/docs/claude-code/hooks.

Les serveurs MCP dans Claude Code

Vous avez découvert le Model Context Protocol comme concept : une manière standard d'exposer des outils et des données à n'importe quel client IA. Claude Code est un client MCP, ce qui veut dire que vous pouvez brancher directement dans vos sessions de terminal les mêmes serveurs que vous utiliseriez dans l'application desktop Claude.

Ajoutez-en un avec la CLI :

claude mcp add github -- npx -y @modelcontextprotocol/server-github

Cela enregistre un serveur MCP GitHub. Une fois connecté, Claude peut ouvrir des issues, lire des PR et inspecter des repos comme des outils natifs, sans code de liaison. Les serveurs que vous ajoutez peuvent être limités à un seul projet ou rendus disponibles globalement, et les serveurs à portée projet peuvent être commités dans le repo pour que toute votre équipe dispose des mêmes intégrations.

C'est le pont entre Claude Code et l'écosystème plus large. Les connecteurs que vous voyez dans les applications Claude et dans la marketplace de connecteurs reposent sur MCP, et la même spécification du protocole est documentée sur modelcontextprotocol.io. Construisez un serveur une fois et il fonctionne dans Claude Code, l'application desktop et tout ce qui parle MCP.

settings.json : le plan de contrôle

Tout ce qui précède se configure dans un seul fichier, et comprendre sa superposition est ce qui distingue une installation propre d'une installation confuse. Claude Code lit les settings depuis plusieurs emplacements, le plus spécifique l'emporte :

• ~/.claude/settings.json : vos réglages personnels par défaut, tous projets
• .claude/settings.json : réglages du projet, commités dans git, partagés avec l'équipe
• .claude/settings.local.json : vos surcharges personnelles pour le projet, ignorées par git

Cette superposition compte. Mettez les garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → valables pour toute l'équipe (le hook de formatage, les serveurs MCP autorisés) dans le .claude/settings.json partagé pour que tout le monde en hérite. Mettez vos préférences personnelles et tout chemin spécifique à votre machine dans settings.local.json pour ne pas vous battre avec vos coéquipiers dans le versioning.

La clé la plus importante est permissions, qui contrôle ce que Claude peut faire sans s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter pour demander. Vous autorisez, demandez ou refusez des patterns d'outils :

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Read",
      "Edit"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Cela laisse Claude exécuter vos scripts de test et modifier des fichiers librement, ne lit jamais votre `.env` ni vos secrets, et refuse les suppressions dangereuses. Réglez ceci une fois et vous arrêtez de surveiller les demandes de confirmation pour les opérations sûres, tout en gardant un mur infranchissable autour des dangereuses.

D'autres clés à connaître : env injecte des variables d'environnement dans chaque session, model fixe quel modèle Claude le projet utilise, et hooks (ci-dessus) vit ici aussi. Gardez le fichier partagé minimal et intentionnel, car quiconque clone le repo en hérite. Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → complet est sur docs.claude.com/en/docs/claude-code/settings.

Comment les pièces s'assemblent

Ces fonctionnalités ne sont pas des jouets séparés ; elles s'empilent. Une installation réelle ressemble à ceci :

Un hook SessionStart charge les conventions du projet. Votre bloc permissions donne le feu vert à la commande de test et met les secrets sous cloche. Une slash command /review lance votre code review standardisée à la demande. Un subagent test-runner se voit déléguer le travail bruyant d'exécuter et de diagnostiquer la suite. Un hook PostToolUse formate chaque fichier que Claude touche. Un serveur MCP GitHub permet à Claude d'ouvrir la PR quand vous avez terminé. Tout cela défini dans des fichiers qui vivent dans le repo, si bien qu'un nouveau coéquipier le clone et obtient exactement le même Claude configuré dès le premier jour.

Cette reproductibilité, c'est tout l'enjeu. Vous ne promptez pas un assistant ; vous livrez un environnement d'ingénierie configuré en même temps que votre code.

Points clés

• Écrivez des slash commands pour les tâches que vous déclenchez ; construisez des Skills pour les capacités que Claude invoque lui-même. Une commande est un prompt Markdown dans .claude/commands/ ; une Skill est un dossier packagé qui circule entre Claude Code, les applications et l'API.
• Utilisez les subagents pour protéger votre contexte principal. Déléguez les tâches bruyantes et ciblées à des agents isolés avec des attributions d'outils étroites, et répartissez-les en parallèle pour du travail indépendant.
• Rendez les règles déterministes avec les hooks. PostToolUse pour le formatage automatique, PreToolUse pour bloquer les actions interdites. Les hooks exécutent de vraies commandes shell avec vos permissions, donc auditez tout ce que vous n'avez pas écrit.
• Traitez MCP comme votre couche d'intégration. claude mcp add branche dans votre terminal les mêmes serveurs et connecteurs utilisés dans tout l'écosystème Anthropic, avec une portée projet et partageables.
• Commitez votre `settings.json` et concevez la superposition. Garde-fous et permissions partagés dans le fichier d'équipe, surcharges personnelles dans settings.local.json, pour que cloner le repo reproduise tout l'environnement configuré.