Étendre Claude avec des skills

Les skills étendent ce que Claude peut faire. Créez un fichier SKILL.md avec des instructions, et Claude l’ajoute à sa boîte à outils. Claude utilise les skills quand c’est pertinent, ou vous pouvez en invoquer une directement avec /skill-name. Créez une skill quand vous continuez à coller le même playbook, checklist ou procédure multi-étapes dans le chat, ou quand une section de CLAUDE.md s’est transformée en procédure plutôt qu’en fait. Contrairement au contenu de CLAUDE.md, le corps d’une skill ne se charge que quand elle est utilisée, donc le matériel de référence long coûte presque rien jusqu’à ce que vous en ayez besoin.

Pour les commandes intégrées comme /help et /compact, et les skills groupées comme /debug et /simplify, consultez la référence des commandes.Les commandes personnalisées ont été fusionnées dans les skills. Un fichier à .claude/commands/deploy.md et une skill à .claude/skills/deploy/SKILL.md créent tous les deux /deploy et fonctionnent de la même manière. Vos fichiers .claude/commands/ existants continuent de fonctionner. Les skills ajoutent des fonctionnalités optionnelles : un répertoire pour les fichiers de support, un frontmatter pour contrôler si vous ou Claude invoquez la skill, et la capacité pour Claude de les charger automatiquement quand c’est pertinent.

Les skills Claude Code suivent la norme ouverte Agent Skills, qui fonctionne sur plusieurs outils d’IA. Claude Code étend la norme avec des fonctionnalités supplémentaires comme le contrôle d’invocation, l’exécution de subagent, et l’injection de contexte dynamique.

Skills groupées

Claude Code inclut un ensemble de skills groupées qui sont disponibles dans chaque session, notamment /simplify, /batch, /debug, /loop et /claude-api. Contrairement à la plupart des commandes intégrées, qui exécutent une logique fixe directement, les skills groupées sont basées sur des prompts : elles donnent à Claude des instructions détaillées et le laissent orchestrer le travail en utilisant ses outils. Vous les invoquez de la même manière que n’importe quelle autre skill, en tapant / suivi du nom de la skill. Les skills groupées sont listées aux côtés des commandes intégrées dans la référence des commandes, marquées Skill dans la colonne Objectif.

Démarrage

Créer votre première skill

Cet exemple crée une skill qui résume les modifications non validées dans votre référentiel git et signale tout ce qui est risqué. Elle extrait le diff en direct dans l’invite avant que Claude ne le lise, de sorte que la réponse est ancrée dans votre arborescence de travail réelle plutôt que dans ce que Claude peut deviner à partir des fichiers ouverts. Claude charge la skill automatiquement quand vous demandez des informations sur vos modifications, ou vous pouvez l’invoquer directement avec /summarize-changes.

Créer le répertoire de la skill

Créez un répertoire pour la skill dans votre dossier de skills personnelles. Les skills personnelles sont disponibles dans tous vos projets.

mkdir -p ~/.claude/skills/summarize-changes

Écrire SKILL.md

Chaque skill a besoin d’un fichier SKILL.md avec deux parties : un frontmatter YAML entre les marqueurs --- qui dit à Claude quand utiliser la skill, et du contenu markdown avec les instructions que Claude suit quand la skill s’exécute. Le nom du répertoire devient la commande que vous tapez, et la description aide Claude à décider quand charger la skill automatiquement.Enregistrez ceci dans ~/.claude/skills/summarize-changes/SKILL.md :

---
description: Résume les modifications non validées et signale tout ce qui est risqué. À utiliser quand l'utilisateur demande ce qui a changé, veut un message de commit, ou demande d'examiner son diff.
---

## Modifications actuelles

!`git diff HEAD`

## Instructions

Résumez les modifications ci-dessus en deux ou trois points, puis listez tous les risques que vous remarquez tels que la gestion des erreurs manquante, les valeurs codées en dur, ou les tests qui doivent être mis à jour. Si le diff est vide, dites qu'il n'y a pas de modifications non validées.

La ligne !`git diff HEAD` utilise l’injection de contexte dynamique : Claude Code exécute la commande et remplace la ligne par sa sortie avant que Claude ne voie le contenu de la skill, de sorte que les instructions arrivent avec le diff actuel déjà intégré.

Tester la skill

Ouvrez un projet git, apportez une petite modification à n’importe quel fichier, et démarrez Claude Code en exécutant claude. Vous pouvez tester la skill de deux façons.Laisser Claude l’invoquer automatiquement en posant une question qui correspond à la description :

What did I change?

Ou l’invoquer directement avec le nom de la skill :

/summarize-changes

De l’une ou l’autre façon, Claude devrait répondre avec un court résumé de votre modification et une liste de risques.

Où vivent les skills

L’endroit où vous stockez une skill détermine qui peut l’utiliser :

Localisation	Chemin	S’applique à
Entreprise	Voir paramètres gérés	Tous les utilisateurs de votre organisation
Personnel	`~/.claude/skills/<skill-name>/SKILL.md`	Tous vos projets
Projet	`.claude/skills/<skill-name>/SKILL.md`	Ce projet uniquement
Plugin	`<plugin>/skills/<skill-name>/SKILL.md`	Où le plugin est activé

Quand les skills partagent le même nom à différents niveaux, l’entreprise remplace le personnel, et le personnel remplace le projet. Les skills de plugin utilisent un espace de noms plugin-name:skill-name, donc elles ne peuvent pas entrer en conflit avec d’autres niveaux. Si vous avez des fichiers dans .claude/commands/, ils fonctionnent de la même manière, mais si une skill et une commande partagent le même nom, la skill a la priorité.

Détection de changement en direct

Claude Code surveille les répertoires de skills pour les changements de fichiers. Ajouter, modifier ou supprimer une skill sous ~/.claude/skills/, le .claude/skills/ du projet, ou un .claude/skills/ à l’intérieur d’un répertoire --add-dir prend effet dans la session actuelle sans redémarrage. Créer un répertoire de skills de haut niveau qui n’existait pas quand la session a commencé nécessite de redémarrer Claude Code pour que le nouveau répertoire puisse être surveillé.

Découverte automatique à partir de répertoires parents et imbriqués

Les skills de projet se chargent à partir de .claude/skills/ dans votre répertoire de démarrage et dans chaque répertoire parent jusqu’à la racine du référentiel, de sorte que démarrer Claude dans un sous-répertoire récupère toujours les skills définies à la racine. Quand vous travaillez avec des fichiers dans des sous-répertoires en dessous de votre répertoire de démarrage, Claude Code découvre également les skills à partir des répertoires .claude/skills/ imbriqués à la demande. Par exemple, si vous modifiez un fichier dans packages/frontend/, Claude Code recherche également les skills dans packages/frontend/.claude/skills/. Cela supporte les configurations monorepo où les packages ont leurs propres skills. Chaque skill est un répertoire avec SKILL.md comme point d’entrée :

my-skill/
├── SKILL.md           # Instructions principales (obligatoire)
├── template.md        # Modèle pour que Claude remplisse
├── examples/
│   └── sample.md      # Exemple de sortie montrant le format attendu
└── scripts/
    └── validate.sh    # Script que Claude peut exécuter

Le SKILL.md contient les instructions principales et est obligatoire. Les autres fichiers sont optionnels et vous permettent de créer des skills plus puissantes : des modèles pour que Claude remplisse, des exemples de sortie montrant le format attendu, des scripts que Claude peut exécuter, ou une documentation de référence détaillée. Référencez ces fichiers à partir de votre SKILL.md pour que Claude sache ce qu’ils contiennent et quand les charger. Voir Ajouter des fichiers de support pour plus de détails.

Les fichiers dans .claude/commands/ fonctionnent toujours et supportent le même frontmatter. Les skills sont recommandées puisqu’elles supportent des fonctionnalités supplémentaires comme les fichiers de support.

Skills à partir de répertoires supplémentaires

Le drapeau --add-dir accorde l’accès aux fichiers plutôt que la découverte de configuration, mais les skills sont une exception : .claude/skills/ dans un répertoire ajouté est chargé automatiquement. Voir Détection de changement en direct pour savoir comment les modifications sont détectées pendant une session. Les autres configurations .claude/ comme les subagents, les commandes et les styles de sortie ne sont pas chargées à partir de répertoires supplémentaires. Voir le tableau des exceptions pour la liste complète de ce qui est et n’est pas chargé, et les façons recommandées de partager la configuration entre les projets.

Les fichiers CLAUDE.md des répertoires --add-dir ne sont pas chargés par défaut. Pour les charger, définissez CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1. Voir Charger à partir de répertoires supplémentaires.

Configurer les skills

Les skills sont configurées via le frontmatter YAML en haut de SKILL.md et le contenu markdown qui suit.

Types de contenu de skill

Les fichiers de skill peuvent contenir n’importe quelles instructions, mais réfléchir à la façon dont vous voulez les invoquer aide à guider ce qu’il faut inclure : Le contenu de référence ajoute des connaissances que Claude applique à votre travail actuel. Conventions, modèles, guides de style, connaissances du domaine. Ce contenu s’exécute en ligne pour que Claude puisse l’utiliser aux côtés du contexte de votre conversation.

---
name: api-conventions
description: API design patterns for this codebase
---

When writing API endpoints:
- Use RESTful naming conventions
- Return consistent error formats
- Include request validation

Le contenu de tâche donne à Claude des instructions étape par étape pour une action spécifique, comme les déploiements, les commits ou la génération de code. Ce sont souvent des actions que vous voulez invoquer directement avec /skill-name plutôt que de laisser Claude décider quand les exécuter. Ajoutez disable-model-invocation: true pour empêcher Claude de la déclencher automatiquement.

---
name: deploy
description: Deploy the application to production
context: fork
disable-model-invocation: true
---

Deploy the application:
1. Run the test suite
2. Build the application
3. Push to the deployment target

Votre SKILL.md peut contenir n’importe quoi, mais réfléchir à la façon dont vous voulez que la skill soit invoquée (par vous, par Claude, ou les deux) et où vous voulez qu’elle s’exécute (en ligne ou dans un subagent) aide à guider ce qu’il faut inclure. Pour les skills complexes, vous pouvez également ajouter des fichiers de support pour garder la skill principale concentrée. Gardez le corps lui-même concis. Une fois qu’une skill se charge, son contenu reste dans le contexte d’un tour à l’autre, donc chaque ligne a un coût de token récurrent. Énoncez ce qu’il faut faire plutôt que de narrer comment ou pourquoi, et appliquez le même test de concision que vous feriez pour le contenu de CLAUDE.md.

Référence du frontmatter

Au-delà du contenu markdown, vous pouvez configurer le comportement de la skill en utilisant les champs du frontmatter YAML entre les marqueurs --- en haut de votre fichier SKILL.md :

---
name: my-skill
description: What this skill does
disable-model-invocation: true
allowed-tools: Read Grep
---

Your skill instructions here...

Tous les champs sont optionnels. Seul description est recommandé pour que Claude sache quand utiliser la skill.

Champ	Obligatoire	Description
`name`	Non	Nom d’affichage pour la skill. S’il est omis, utilise le nom du répertoire. Lettres minuscules, chiffres et tirets uniquement (max 64 caractères).
`description`	Recommandé	Ce que fait la skill et quand l’utiliser. Claude utilise ceci pour décider quand appliquer la skill. S’il est omis, utilise le premier paragraphe du contenu markdown. Mettez en avant le cas d’utilisation clé : le texte combiné `description` et `when_to_use` est tronqué à 1 536 caractères dans la liste des skills pour réduire l’utilisation du contexte.
`when_to_use`	Non	Contexte supplémentaire pour quand Claude devrait invoquer la skill, comme les phrases déclencheurs ou les demandes d’exemple. Ajouté à `description` dans la liste des skills et compte vers le plafond de 1 536 caractères.
`argument-hint`	Non	Indice affiché lors de l’autocomplétion pour indiquer les arguments attendus. Exemple : `[issue-number]` ou `[filename] [format]`.
`arguments`	Non	Arguments positionnels nommés pour la substitution `$name` dans le contenu de la skill. Accepte une chaîne séparée par des espaces ou une liste YAML. Les noms correspondent aux positions d’argument dans l’ordre.
`disable-model-invocation`	Non	Définissez à `true` pour empêcher Claude de charger automatiquement cette skill. Utilisez pour les workflows que vous voulez déclencher manuellement avec `/name`. Empêche également la skill d’être préchargée dans les subagents. Par défaut : `false`.
`user-invocable`	Non	Définissez à `false` pour masquer du menu `/`. Utilisez pour les connaissances de base que les utilisateurs ne devraient pas invoquer directement. Par défaut : `true`.
`allowed-tools`	Non	Outils que Claude peut utiliser sans demander la permission quand cette skill est active. Accepte une chaîne séparée par des espaces ou une liste YAML.
`model`	Non	Modèle à utiliser quand cette skill est active. Le remplacement s’applique pour le reste du tour actuel et n’est pas sauvegardé dans les paramètres ; le modèle de session reprend à votre prochain prompt. Accepte les mêmes valeurs que `/model`, ou `inherit` pour garder le modèle actif.
`effort`	Non	Niveau d’effort quand cette skill est active. Remplace le niveau d’effort de la session. Par défaut : hérite de la session. Options : `low`, `medium`, `high`, `xhigh`, `max` ; les niveaux disponibles dépendent du modèle.
`context`	Non	Définissez à `fork` pour exécuter dans un contexte de subagent forké.
`agent`	Non	Quel type de subagent utiliser quand `context: fork` est défini.
`hooks`	Non	Hooks limités au cycle de vie de cette skill. Voir Hooks dans les skills et les agents pour le format de configuration.
`paths`	Non	Modèles Glob qui limitent quand cette skill est activée. Accepte une chaîne séparée par des virgules ou une liste YAML. Quand défini, Claude charge la skill automatiquement uniquement quand vous travaillez avec des fichiers correspondant aux modèles. Utilise le même format que les règles spécifiques au chemin.
`shell`	Non	Shell à utiliser pour !`command` et ```! blocs dans cette skill. Accepte `bash` (par défaut) ou `powershell`. Définir `powershell` exécute les commandes shell en ligne via PowerShell sur Windows. Nécessite `CLAUDE_CODE_USE_POWERSHELL_TOOL=1`.

Substitutions de chaîne disponibles

Les skills supportent la substitution de chaîne pour les valeurs dynamiques dans le contenu de la skill :

Variable	Description
`$ARGUMENTS`	Tous les arguments passés lors de l’invocation de la skill. Si `$ARGUMENTS` n’est pas présent dans le contenu, les arguments sont ajoutés comme `ARGUMENTS: <value>`.
`$ARGUMENTS[N]`	Accédez à un argument spécifique par index basé sur 0, comme `$ARGUMENTS[0]` pour le premier argument.
`$N`	Raccourci pour `$ARGUMENTS[N]`, comme `$0` pour le premier argument ou `$1` pour le deuxième.
`$name`	Argument nommé déclaré dans la liste du frontmatter `arguments`. Les noms correspondent aux positions dans l’ordre, donc avec `arguments: [issue, branch]` l’espace réservé `$issue` se développe en le premier argument et `$branch` en le deuxième.
`${CLAUDE_SESSION_ID}`	L’ID de session actuel. Utile pour la journalisation, la création de fichiers spécifiques à la session, ou la corrélation de la sortie de la skill avec les sessions.
`${CLAUDE_EFFORT}`	Le niveau d’effort actuel : `low`, `medium`, `high`, `xhigh`, ou `max`. Utilisez ceci pour adapter les instructions de la skill au paramètre d’effort actif.
`${CLAUDE_SKILL_DIR}`	Le répertoire contenant le fichier `SKILL.md` de la skill. Pour les skills de plugin, c’est le sous-répertoire de la skill dans le plugin, pas la racine du plugin. Utilisez ceci dans les commandes d’injection bash pour référencer les scripts ou les fichiers groupés avec la skill, indépendamment du répertoire de travail actuel.

Les arguments indexés utilisent le guillemettage de style shell, donc enveloppez les valeurs multi-mots entre guillemets pour les passer comme un seul argument. Par exemple, /my-skill "hello world" second fait que $0 se développe en hello world et $1 en second. L’espace réservé $ARGUMENTS se développe toujours en la chaîne d’argument complète telle que tapée. Exemple utilisant les substitutions :

---
name: session-logger
description: Log activity for this session
---

Log the following to logs/${CLAUDE_SESSION_ID}.log:

$ARGUMENTS

Ajouter des fichiers de support

Les skills peuvent inclure plusieurs fichiers dans leur répertoire. Cela garde SKILL.md concentré sur l’essentiel tout en permettant à Claude d’accéder au matériel de référence détaillé uniquement quand c’est nécessaire. Les grandes docs de référence, les spécifications d’API, ou les collections d’exemples n’ont pas besoin de se charger dans le contexte à chaque fois que la skill s’exécute.

my-skill/
├── SKILL.md (obligatoire - aperçu et navigation)
├── reference.md (docs API détaillées - chargées quand nécessaire)
├── examples.md (exemples d'utilisation - chargés quand nécessaire)
└── scripts/
    └── helper.py (script utilitaire - exécuté, pas chargé)

Référencez les fichiers de support à partir de SKILL.md pour que Claude sache ce que chaque fichier contient et quand le charger :

## Ressources supplémentaires

- Pour les détails complets de l'API, voir [reference.md](reference.md)
- Pour les exemples d'utilisation, voir [examples.md](examples.md)

Gardez SKILL.md sous 500 lignes. Déplacez le matériel de référence détaillé vers des fichiers séparés.

Contrôler qui invoque une skill

Par défaut, vous et Claude pouvez tous les deux invoquer n’importe quelle skill. Vous pouvez taper /skill-name pour l’invoquer directement, et Claude peut la charger automatiquement quand c’est pertinent pour votre conversation. Deux champs du frontmatter vous permettent de restreindre ceci :

disable-model-invocation: true : Seul vous pouvez invoquer la skill. Utilisez ceci pour les workflows avec des effets secondaires ou que vous voulez contrôler le timing, comme /commit, /deploy, ou /send-slack-message. Vous ne voulez pas que Claude décide de déployer parce que votre code semble prêt.
user-invocable: false : Seul Claude peut invoquer la skill. Utilisez ceci pour les connaissances de base qui ne sont pas actionnables comme une commande. Une skill legacy-system-context explique comment fonctionne un ancien système. Claude devrait le savoir quand c’est pertinent, mais /legacy-system-context n’est pas une action significative pour les utilisateurs.

Cet exemple crée une skill de déploiement que seul vous pouvez déclencher. Le champ disable-model-invocation: true empêche Claude de l’exécuter automatiquement :

---
name: deploy
description: Deploy the application to production
disable-model-invocation: true
---

Deploy $ARGUMENTS to production:

1. Run the test suite
2. Build the application
3. Push to the deployment target
4. Verify the deployment succeeded

Voici comment les deux champs affectent l’invocation et le chargement du contexte :

Frontmatter	Vous pouvez invoquer	Claude peut invoquer	Quand chargé dans le contexte
(par défaut)	Oui	Oui	Description toujours dans le contexte, la skill complète se charge quand invoquée
`disable-model-invocation: true`	Oui	Non	Description pas dans le contexte, la skill complète se charge quand vous l’invoquez
`user-invocable: false`	Non	Oui	Description toujours dans le contexte, la skill complète se charge quand invoquée

Dans une session régulière, les descriptions de skills sont chargées dans le contexte pour que Claude sache ce qui est disponible, mais le contenu complet de la skill ne se charge que quand elle est invoquée. Les subagents avec des skills préchargées fonctionnent différemment : le contenu complet de la skill est injecté au démarrage.

Cycle de vie du contenu de la skill

Quand vous ou Claude invoquez une skill, le contenu SKILL.md rendu entre dans la conversation comme un seul message et y reste pour le reste de la session. Claude Code ne relit pas le fichier de skill aux tours suivants, donc écrivez les directives qui devraient s’appliquer tout au long d’une tâche comme des instructions permanentes plutôt que des étapes ponctuelles. L’auto-compaction porte les skills invoquées en avant dans un budget de tokens. Quand la conversation est résumée pour libérer du contexte, Claude Code réattache l’invocation la plus récente de chaque skill après le résumé, en gardant les premiers 5 000 tokens de chacune. Les skills réattachées partagent un budget combiné de 25 000 tokens. Claude Code remplit ce budget en commençant par la skill la plus récemment invoquée, donc les skills plus anciennes peuvent être entièrement supprimées après la compaction si vous en avez invoqué beaucoup dans une session. Si une skill semble cesser d’influencer le comportement après la première réponse, le contenu est généralement toujours présent et le modèle choisit d’autres outils ou approches. Renforcez la description et les instructions de la skill pour que le modèle continue à la préférer, ou utilisez hooks pour appliquer le comportement de manière déterministe. Si la skill est grande ou vous avez invoqué plusieurs autres après elle, réinvoquez-la après la compaction pour restaurer le contenu complet.

Pré-approuver les outils pour une skill

Le champ allowed-tools accorde la permission pour les outils listés tandis que la skill est active, pour que Claude puisse les utiliser sans vous demander l’approbation par utilisation. Il ne restreint pas quels outils sont disponibles : chaque outil reste appelable, et vos paramètres de permission gouvernent toujours les outils qui ne sont pas listés. Pour les skills vérifiées dans le répertoire .claude/skills/ d’un projet, allowed-tools prend effet après que vous acceptiez la boîte de dialogue de confiance de l’espace de travail pour ce dossier, de la même manière que les règles de permission dans .claude/settings.json. Examinez les skills du projet avant de faire confiance à un référentiel, car une skill peut s’accorder un accès large aux outils. Cette skill permet à Claude d’exécuter les commandes git sans approbation par utilisation chaque fois que vous l’invoquez :

---
name: commit
description: Stage and commit the current changes
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---

Pour bloquer une skill d’utiliser certains outils, ajoutez plutôt des règles de refus dans vos paramètres de permission.

Passer des arguments aux skills

Vous et Claude pouvez tous les deux passer des arguments lors de l’invocation d’une skill. Les arguments sont disponibles via l’espace réservé $ARGUMENTS. Cette skill corrige un problème GitHub par numéro. L’espace réservé $ARGUMENTS est remplacé par tout ce qui suit le nom de la skill :

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---

Fix GitHub issue $ARGUMENTS following our coding standards.

1. Read the issue description
2. Understand the requirements
3. Implement the fix
4. Write tests
5. Create a commit

Quand vous exécutez /fix-issue 123, Claude reçoit « Fix GitHub issue 123 following our coding standards… » Si vous invoquez une skill avec des arguments mais que la skill n’inclut pas $ARGUMENTS, Claude Code ajoute ARGUMENTS: <your input> à la fin du contenu de la skill pour que Claude voie toujours ce que vous avez tapé. Pour accéder aux arguments individuels par position, utilisez $ARGUMENTS[N] ou le raccourci plus court $N :

---
name: migrate-component
description: Migrate a component from one framework to another
---

Migrate the $ARGUMENTS[0] component from $ARGUMENTS[1] to $ARGUMENTS[2].
Preserve all existing behavior and tests.

Exécuter /migrate-component SearchBar React Vue remplace $ARGUMENTS[0] par SearchBar, $ARGUMENTS[1] par React, et $ARGUMENTS[2] par Vue. La même skill utilisant le raccourci $N :

---
name: migrate-component
description: Migrate a component from one framework to another
---

Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.

Modèles avancés

Injecter du contexte dynamique

La syntaxe !`<command>` exécute les commandes shell avant que le contenu de la skill soit envoyé à Claude. La sortie de la commande remplace l’espace réservé, donc Claude reçoit les données réelles, pas la commande elle-même. Cette skill résume une pull request en récupérant les données de PR en direct avec le CLI GitHub. Les commandes !`gh pr diff` et autres s’exécutent d’abord, et leur sortie est insérée dans le prompt :

---
name: pr-summary
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---

## Pull request context
- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

## Your task
Summarize this pull request...

Quand cette skill s’exécute :

Chaque !`<command>` s’exécute immédiatement (avant que Claude ne voie quoi que ce soit)
La sortie remplace l’espace réservé dans le contenu de la skill
Claude reçoit le prompt complètement rendu avec les données réelles de PR

C’est du prétraitement, pas quelque chose que Claude exécute. Claude ne voit que le résultat final. Pour les commandes multi-lignes, utilisez un bloc de code clôturé ouvert avec ```! au lieu de la forme en ligne :

## Environment
```!
node --version
npm --version
git status --short
```

Pour désactiver ce comportement pour les skills et les commandes personnalisées des sources utilisateur, projet, plugin ou répertoire supplémentaire, définissez "disableSkillShellExecution": true dans paramètres. Chaque commande est remplacée par [shell command execution disabled by policy] au lieu d’être exécutée. Les skills groupées et gérées ne sont pas affectées. Ce paramètre est très utile dans les paramètres gérés, où les utilisateurs ne peuvent pas le remplacer.

Pour demander un raisonnement plus approfondi quand une skill s’exécute, incluez ultrathink n’importe où dans le contenu de la skill. Voir Utiliser ultrathink pour un raisonnement approfondi ponctuel.

Exécuter les skills dans un subagent

Ajoutez context: fork à votre frontmatter quand vous voulez qu’une skill s’exécute en isolation. Le contenu de la skill devient le prompt qui pilote le subagent. Il n’aura pas accès à votre historique de conversation.

context: fork n’a de sens que pour les skills avec des instructions explicites. Si votre skill contient des directives comme « utiliser ces conventions d’API » sans une tâche, le subagent reçoit les directives mais pas de prompt actionnable, et retourne sans sortie significative.

Les skills et les subagents fonctionnent ensemble dans deux directions :

Approche	Prompt système	Tâche	Charge également
Skill avec `context: fork`	Du type d’agent (`Explore`, `Plan`, etc.)	Contenu de SKILL.md	CLAUDE.md
Subagent avec champ `skills`	Corps markdown du subagent	Message de délégation de Claude	Skills préchargées + CLAUDE.md

Avec context: fork, vous écrivez la tâche dans votre skill et choisissez un type d’agent pour l’exécuter. Pour l’inverse (définir un subagent personnalisé qui utilise les skills comme matériel de référence), voir Subagents.

Exemple : Skill de recherche utilisant l’agent Explore

Cette skill exécute la recherche dans un agent Explore forké. Le contenu de la skill devient la tâche, et l’agent fournit des outils en lecture seule optimisés pour l’exploration de la base de code :

---
name: deep-research
description: Research a topic thoroughly
context: fork
agent: Explore
---

Research $ARGUMENTS thoroughly:

1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Summarize findings with specific file references

Quand cette skill s’exécute :

Un nouveau contexte isolé est créé
Le subagent reçoit le contenu de la skill comme son prompt (« Research $ARGUMENTS thoroughly… »)
Le champ agent détermine l’environnement d’exécution (modèle, outils et permissions)
Les résultats sont résumés et retournés à votre conversation principale

Le champ agent spécifie quelle configuration de subagent utiliser. Les options incluent les agents intégrés (Explore, Plan, general-purpose) ou n’importe quel subagent personnalisé de .claude/agents/. S’il est omis, utilise general-purpose.

Restreindre l’accès aux skills de Claude

Par défaut, Claude peut invoquer n’importe quelle skill qui n’a pas disable-model-invocation: true défini. Les skills qui définissent allowed-tools accordent à Claude l’accès à ces outils sans approbation par utilisation quand la skill est active. Vos paramètres de permission gouvernent toujours le comportement d’approbation de base pour tous les autres outils. Quelques commandes intégrées sont également disponibles via l’outil Skill, notamment /init, /review et /security-review. Les autres commandes intégrées comme /compact ne le sont pas. Trois façons de contrôler quelles skills Claude peut invoquer : Désactiver toutes les skills en refusant l’outil Skill dans /permissions :

# Add to deny rules:
Skill

Autoriser ou refuser des skills spécifiques en utilisant les règles de permission :

# Allow only specific skills
Skill(commit)
Skill(review-pr *)

# Deny specific skills
Skill(deploy *)

Syntaxe de permission : Skill(name) pour une correspondance exacte, Skill(name *) pour une correspondance de préfixe avec n’importe quels arguments. Masquer les skills individuelles en ajoutant disable-model-invocation: true à leur frontmatter. Cela supprime la skill du contexte de Claude entièrement.

Le champ user-invocable contrôle uniquement la visibilité du menu, pas l’accès à l’outil Skill. Utilisez disable-model-invocation: true pour bloquer l’invocation programmatique.

Remplacer la visibilité des skills à partir des paramètres

Le paramètre skillOverrides contrôle la visibilité des skills à partir de vos paramètres au lieu du frontmatter de la skill elle-même. Utilisez-le pour les skills dont le SKILL.md vous ne voulez pas modifier, comme celles archivées dans un référentiel de projet partagé ou fournies par un serveur MCP. Le menu /skills l’écrit pour vous : mettez en surbrillance une skill et appuyez sur Space pour parcourir les états, puis Enter pour enregistrer dans .claude/settings.local.json. Chaque clé est un nom de skill et chaque valeur est l’un des quatre états :

Valeur	Listée à Claude	Dans le menu `/`
`"on"`	Nom et description	Oui
`"name-only"`	Nom uniquement	Oui
`"user-invocable-only"`	Masqué	Oui
`"off"`	Masqué	Masqué

Une skill absente de skillOverrides est traitée comme "on". L’exemple ci-dessous réduit une skill à son nom et désactive une autre entièrement :

{
  "skillOverrides": {
    "legacy-context": "name-only",
    "deploy": "off"
  }
}

Les skills de plugin ne sont pas affectées par skillOverrides. Gérez-les via /plugin à la place.

Partager les skills

Les skills peuvent être distribuées à différentes portées selon votre audience :

Skills de projet : Validez .claude/skills/ dans le contrôle de version
Plugins : Créez un répertoire skills/ dans votre plugin
Gérées : Déployez à l’échelle de l’organisation via les paramètres gérés

Générer une sortie visuelle

Les skills peuvent grouper et exécuter des scripts dans n’importe quel langage, donnant à Claude des capacités au-delà de ce qui est possible dans un seul prompt. Un modèle puissant est la génération de sortie visuelle : des fichiers HTML interactifs qui s’ouvrent dans votre navigateur pour explorer les données, déboguer ou créer des rapports. Cet exemple crée un explorateur de base de code : une vue d’arbre interactive où vous pouvez développer et réduire les répertoires, voir les tailles de fichiers en un coup d’œil, et identifier les types de fichiers par couleur. Créez le répertoire Skill :

mkdir -p ~/.claude/skills/codebase-visualizer/scripts

Enregistrez ceci dans ~/.claude/skills/codebase-visualizer/SKILL.md. La description indique à Claude quand activer cette Skill, et les instructions indiquent à Claude d’exécuter le script groupé. Le chemin du script utilise ${CLAUDE_SKILL_DIR} pour qu’il se résolve correctement que la skill soit installée au niveau personnel, projet ou plugin :

---
name: codebase-visualizer
description: Generate an interactive collapsible tree visualization of your codebase. Use when exploring a new repo, understanding project structure, or identifying large files.
allowed-tools: Bash(python3 *)
---

# Codebase Visualizer

Generate an interactive HTML tree view that shows your project's file structure with collapsible directories.

## Usage

Run the visualization script from your project root:

```bash
python3 ${CLAUDE_SKILL_DIR}/scripts/visualize.py .
```

This creates `codebase-map.html` in the current directory and opens it in your default browser.

## What the visualization shows

- **Collapsible directories**: Click folders to expand/collapse
- **File sizes**: Displayed next to each file
- **Colors**: Different colors for different file types
- **Directory totals**: Shows aggregate size of each folder

Enregistrez ceci dans ~/.claude/skills/codebase-visualizer/scripts/visualize.py. Ce script analyse une arborescence de répertoires et génère un fichier HTML autonome avec :

Une barre latérale de résumé montrant le nombre de fichiers, le nombre de répertoires, la taille totale et le nombre de types de fichiers
Un graphique en barres décomposant la base de code par type de fichier (top 8 par taille)
Un arbre réductible où vous pouvez développer et réduire les répertoires, avec des indicateurs de type de fichier codés par couleur

Le script nécessite Python 3 mais utilise uniquement les bibliothèques intégrées, donc il n’y a pas de packages à installer :

#!/usr/bin/env python3
"""Generate an interactive collapsible tree visualization of a codebase."""

import json
import sys
import webbrowser
from html import escape
from pathlib import Path
from collections import Counter

IGNORE = {'.git', 'node_modules', '__pycache__', '.venv', 'venv', 'dist', 'build'}

def scan(path: Path, stats: dict) -> dict:
    result = {"name": path.name, "children": [], "size": 0}
    try:
        for item in sorted(path.iterdir()):
            if item.name in IGNORE or item.name.startswith('.'):
                continue
            if item.is_file():
                size = item.stat().st_size
                ext = item.suffix.lower() or '(no ext)'
                result["children"].append({"name": item.name, "size": size, "ext": ext})
                result["size"] += size
                stats["files"] += 1
                stats["extensions"][ext] += 1
                stats["ext_sizes"][ext] += size
            elif item.is_dir():
                stats["dirs"] += 1
                child = scan(item, stats)
                if child["children"]:
                    result["children"].append(child)
                    result["size"] += child["size"]
    except PermissionError:
        pass
    return result

def generate_html(data: dict, stats: dict, output: Path) -> None:
    ext_sizes = stats["ext_sizes"]
    total_size = sum(ext_sizes.values()) or 1
    sorted_exts = sorted(ext_sizes.items(), key=lambda x: -x[1])[:8]
    colors = {
        '.js': '#f7df1e', '.ts': '#3178c6', '.py': '#3776ab', '.go': '#00add8',
        '.rs': '#dea584', '.rb': '#cc342d', '.css': '#264de4', '.html': '#e34c26',
        '.json': '#6b7280', '.md': '#083fa1', '.yaml': '#cb171e', '.yml': '#cb171e',
        '.mdx': '#083fa1', '.tsx': '#3178c6', '.jsx': '#61dafb', '.sh': '#4eaa25',
    }
    lang_bars = "".join(
        f'<div class="bar-row"><span class="bar-label">{ext}</span>'
        f'<div class="bar" style="width:{(size/total_size)*100}%;background:{colors.get(ext,"#6b7280")}"></div>'
        f'<span class="bar-pct">{(size/total_size)*100:.1f}%</span></div>'
        for ext, size in sorted_exts
    )
    def fmt(b):
        if b < 1024: return f"{b} B"
        if b < 1048576: return f"{b/1024:.1f} KB"
        return f"{b/1048576:.1f} MB"

    html = f'''<!DOCTYPE html>
<html><head>
  <meta charset="utf-8"><title>Codebase Explorer</title>
  <style>
    body {{ font: 14px/1.5 system-ui, sans-serif; margin: 0; background: #1a1a2e; color: #eee; }}
    .container {{ display: flex; height: 100vh; }}
    .sidebar {{ width: 280px; background: #252542; padding: 20px; border-right: 1px solid #3d3d5c; overflow-y: auto; flex-shrink: 0; }}
    .main {{ flex: 1; padding: 20px; overflow-y: auto; }}
    h1 {{ margin: 0 0 10px 0; font-size: 18px; }}
    h2 {{ margin: 20px 0 10px 0; font-size: 14px; color: #888; text-transform: uppercase; }}
    .stat {{ display: flex; justify-content: space-between; padding: 8px 0; border-bottom: 1px solid #3d3d5c; }}
    .stat-value {{ font-weight: bold; }}
    .bar-row {{ display: flex; align-items: center; margin: 6px 0; }}
    .bar-label {{ width: 55px; font-size: 12px; color: #aaa; }}
    .bar {{ height: 18px; border-radius: 3px; }}
    .bar-pct {{ margin-left: 8px; font-size: 12px; color: #666; }}
    .tree {{ list-style: none; padding-left: 20px; }}
    details {{ cursor: pointer; }}
    summary {{ padding: 4px 8px; border-radius: 4px; }}
    summary:hover {{ background: #2d2d44; }}
    .folder {{ color: #ffd700; }}
    .file {{ display: flex; align-items: center; padding: 4px 8px; border-radius: 4px; }}
    .file:hover {{ background: #2d2d44; }}
    .size {{ color: #888; margin-left: auto; font-size: 12px; }}
    .dot {{ width: 8px; height: 8px; border-radius: 50%; margin-right: 8px; }}
  </style>
</head><body>
  <div class="container">
    <div class="sidebar">
      <h1>📊 Summary</h1>
      <div class="stat"><span>Files</span><span class="stat-value">{stats["files"]:,}</span></div>
      <div class="stat"><span>Directories</span><span class="stat-value">{stats["dirs"]:,}</span></div>
      <div class="stat"><span>Total size</span><span class="stat-value">{fmt(data["size"])}</span></div>
      <div class="stat"><span>File types</span><span class="stat-value">{len(stats["extensions"])}</span></div>
      <h2>By file type</h2>
      {lang_bars}
    </div>
    <div class="main">
      <h1>📁 {escape(data["name"])}</h1>
      <ul class="tree" id="root"></ul>
    </div>
  </div>
  <script>
    const data = {json.dumps(data)};
    const colors = {json.dumps(colors)};
    function fmt(b) {{ if (b < 1024) return b + ' B'; if (b < 1048576) return (b/1024).toFixed(1) + ' KB'; return (b/1048576).toFixed(1) + ' MB'; }}
    function esc(s) {{ return s.replace(/[&<>"']/g, c => ({{"&":"&amp;","<":"&lt;",">":"&gt;",'"':"&quot;","'":"&#39;"}}[c])); }}
    function render(node, parent) {{
      if (node.children) {{
        const det = document.createElement('details');
        det.open = parent === document.getElementById('root');
        det.innerHTML = `<summary><span class="folder">📁 ${{esc(node.name)}}</span><span class="size">${{fmt(node.size)}}</span></summary>`;
        const ul = document.createElement('ul'); ul.className = 'tree';
        node.children.sort((a,b) => (b.children?1:0)-(a.children?1:0) || a.name.localeCompare(b.name));
        node.children.forEach(c => render(c, ul));
        det.appendChild(ul);
        const li = document.createElement('li'); li.appendChild(det); parent.appendChild(li);
      }} else {{
        const li = document.createElement('li'); li.className = 'file';
        li.innerHTML = `<span class="dot" style="background:${{colors[node.ext]||'#6b7280'}}"></span>${{esc(node.name)}}<span class="size">${{fmt(node.size)}}</span>`;
        parent.appendChild(li);
      }}
    }}
    data.children.forEach(c => render(c, document.getElementById('root')));
  </script>
</body></html>'''
    output.write_text(html)

if __name__ == '__main__':
    target = Path(sys.argv[1] if len(sys.argv) > 1 else '.').resolve()
    stats = {"files": 0, "dirs": 0, "extensions": Counter(), "ext_sizes": Counter()}
    data = scan(target, stats)
    out = Path('codebase-map.html')
    generate_html(data, stats, out)
    print(f'Generated {out.absolute()}')
    webbrowser.open(f'file://{out.absolute()}')

Pour tester, ouvrez Claude Code dans n’importe quel projet et demandez « Visualize this codebase. » Claude exécute le script, génère codebase-map.html, et l’ouvre dans votre navigateur. Ce modèle fonctionne pour n’importe quelle sortie visuelle : graphiques de dépendances, rapports de couverture de test, documentation d’API, ou visualisations de schéma de base de données. Le script groupé fait le gros du travail tandis que Claude gère l’orchestration.

Dépannage

Skill ne se déclenche pas

Si Claude n’utilise pas votre skill quand attendu :

Vérifiez que la description inclut les mots-clés que les utilisateurs diraient naturellement
Vérifiez que la skill apparaît dans « What skills are available? »
Essayez de reformuler votre demande pour correspondre plus étroitement à la description
Invoquez-la directement avec /skill-name si la skill est invocable par l’utilisateur

Skill se déclenche trop souvent

Si Claude utilise votre skill quand vous ne le voulez pas :

Rendez la description plus spécifique
Ajoutez disable-model-invocation: true si vous voulez uniquement l’invocation manuelle

Les descriptions de skills sont coupées court

Les descriptions de skills sont chargées dans le contexte pour que Claude sache ce qui est disponible. Tous les noms de skills sont toujours inclus, mais si vous avez beaucoup de skills, les descriptions sont raccourcies pour tenir dans le budget de caractères, ce qui peut supprimer les mots-clés dont Claude a besoin pour correspondre à votre demande. Le budget s’adapte à 1 % de la fenêtre de contexte du modèle. Quand il déborde, les descriptions des skills que vous invoquez le moins sont supprimées en premier, de sorte que les skills que vous utilisez réellement conservent leur texte complet. Exécutez /doctor pour voir si le budget déborde et quelles skills sont affectées. Pour augmenter le budget, définissez le paramètre skillListingBudgetFraction (par exemple 0.02 = 2 %) ou la variable d’environnement SLASH_COMMAND_TOOL_CHAR_BUDGET à un nombre de caractères fixe. Pour libérer du budget pour d’autres skills, définissez les entrées de faible priorité sur "name-only" dans skillOverrides afin qu’elles s’affichent sans description. Vous pouvez également réduire le texte description et when_to_use à la source : mettez en avant le cas d’utilisation clé, puisque le texte combiné de chaque entrée est limité à 1 536 caractères indépendamment du budget. Le plafond est configurable avec maxSkillDescriptionChars.

Ressources connexes

Déboguer votre configuration : diagnostiquer pourquoi un skill n’apparaît pas ou ne se déclenche pas
Subagents : déléguer les tâches à des agents spécialisés
Plugins : empaqueter et distribuer les skills avec d’autres extensions
Hooks : automatiser les workflows autour des événements d’outils
Memory : gérer les fichiers CLAUDE.md pour le contexte persistant
Commands : référence pour les commandes intégrées et les skills groupées
Permissions : contrôler l’accès aux outils et aux skills

Agents et travail parallèle

Outils et plugins

Automatisation

Dépannage

Étendre Claude avec des skills

Skills groupées

Démarrage

Créer votre première skill

Où vivent les skills

Détection de changement en direct

Découverte automatique à partir de répertoires parents et imbriqués

Skills à partir de répertoires supplémentaires

Configurer les skills

Types de contenu de skill

Référence du frontmatter

Substitutions de chaîne disponibles

Ajouter des fichiers de support

Contrôler qui invoque une skill

Cycle de vie du contenu de la skill

Pré-approuver les outils pour une skill

Passer des arguments aux skills

Modèles avancés

Injecter du contexte dynamique

Exécuter les skills dans un subagent

Exemple : Skill de recherche utilisant l’agent Explore

Restreindre l’accès aux skills de Claude

Remplacer la visibilité des skills à partir des paramètres

Partager les skills

Générer une sortie visuelle

Dépannage

Skill ne se déclenche pas

Skill se déclenche trop souvent

Les descriptions de skills sont coupées court

Ressources connexes

Agents et travail parallèle

Outils et plugins

Automatisation

Dépannage

Documentation Index

​Skills groupées

​Démarrage

​Créer votre première skill

​Où vivent les skills

​Détection de changement en direct

​Découverte automatique à partir de répertoires parents et imbriqués

​Skills à partir de répertoires supplémentaires

​Configurer les skills

​Types de contenu de skill

​Référence du frontmatter

​Substitutions de chaîne disponibles

​Ajouter des fichiers de support

​Contrôler qui invoque une skill

​Cycle de vie du contenu de la skill

​Pré-approuver les outils pour une skill

​Passer des arguments aux skills

​Modèles avancés

​Injecter du contexte dynamique

​Exécuter les skills dans un subagent

​Exemple : Skill de recherche utilisant l’agent Explore

​Restreindre l’accès aux skills de Claude

​Remplacer la visibilité des skills à partir des paramètres

​Partager les skills

​Générer une sortie visuelle

​Dépannage

​Skill ne se déclenche pas

​Skill se déclenche trop souvent

​Les descriptions de skills sont coupées court

​Ressources connexes

Skills groupées

Démarrage

Créer votre première skill

Où vivent les skills

Détection de changement en direct

Découverte automatique à partir de répertoires parents et imbriqués

Skills à partir de répertoires supplémentaires

Configurer les skills

Types de contenu de skill

Référence du frontmatter

Substitutions de chaîne disponibles

Ajouter des fichiers de support

Contrôler qui invoque une skill

Cycle de vie du contenu de la skill

Pré-approuver les outils pour une skill

Passer des arguments aux skills

Modèles avancés

Injecter du contexte dynamique

Exécuter les skills dans un subagent

Exemple : Skill de recherche utilisant l’agent Explore

Restreindre l’accès aux skills de Claude

Remplacer la visibilité des skills à partir des paramètres

Partager les skills

Générer une sortie visuelle

Dépannage

Skill ne se déclenche pas

Skill se déclenche trop souvent

Les descriptions de skills sont coupées court

Ressources connexes