Dans ce tutoriel, nous vous montrons comment créer votre premier Skill dans Claude Code, un mécanisme qui permet d'enregistrer une fois pour toutes une consigne réutilisable dans n'importe quelle conversation. Nous prendrons le cas concret d'un skill qui transforme automatiquement l'échange en cours en une documentation technique propre, prête à être versée dans un wiki interne.

Cet article est la suite logique du tutoriel d'installation de Claude Code que nous avons publié précédemment. Si Claude Code n'est pas encore opérationnel sur votre poste, je vous invite à consulter notre article dédié avant de poursuivre :

IT-Connect - Installer et prendre en main Claude Code en CLI

Dans tous les métiers de l'IT et notamment en administration système, on passe souvent la journée à répondre aux mêmes questions, à dérouler les mêmes procédures et surtout à réécrire les mêmes consignes de mise en forme quand il s'agit de documenter ce que l'on vient de faire. "Mets-moi ça au format runbook avec les sections But, Pré-requis, Procédure, Validation, Rollback, problèmes courants"… Combien de fois avez-vous tapé une phrase de ce genre à votre assistant ? Les Skills ont été pensés exactement pour cela : écrire la procédure une seule fois, puis la réutiliser automatiquement dans toutes les conversations suivantes.

Nous verrons notamment dans cet article ce qu'est un Skill, où le placer dans votre arborescence (sous Linux comme sous Windows), comment rédiger un SKILL.md propre, comment lui faire utiliser un template de référence, et enfin comment l'utiliser.

Un Skill, c'est quoi ?

Un Skill, dans Claude Code, est tout simplement un dossier qui contient un fichier SKILL.md et, éventuellement, quelques fichiers de référence supplémentaires. Le SKILL.md est l'élément principal : il contient en en-tête le nom du skill, sa description et quelques options, suivi d'un corps en markdown qui décrit, en langage naturel, ce que Claude doit faire quand le Skill est activé.

L'analogie est celle d'une procédure interne écrite une fois et appliquée à chaque fois que le cas se présente. Au lieu de ré-expliquer à votre assistant "génère-moi une doc avec ces sections, dans ce ton, avec ces conventions, utilise bien tel format", vous écrivez la procédure dans un fichier et vous laissez Claude s'y référer. L'intérêt est double : gain de temps (plus besoin de reformuler), et surtout constance du résultat d'une conversation à l'autre.

Un détail dont on reparlera plus loin : la clé pour que Claude invoque lui-même le Skill au bon moment, sans que vous ayez à y penser, c'est la qualité de la description inscrite dans le SKILL.md. C'est elle qui joue le rôle de "panneau indicateur" pour l'assistant.

Pour moi, l'intérêt majeur du skill est celui-ci : j'ai beau démarrer plein de conversations sur des sujets techniques différents, quand je veux que le modèle synthétise cela en documentation, je n'ai plus besoin de reformuler ma demande concernant la syntaxe, le format, etc. On peut vraiment voir ça comme une capacité commune et identique, quel que soit la conversation et son contenu.

Les trois portées : utilisateur, projet, plugin

Un skill peut être installé à trois endroits différents, et ce choix n'est pas anodin.

Portée utilisateur : Le skill est placé dans votre dossier personnel et sera disponible dans toutes vos conversations Claude Code, quel que soit le dossier dans lequel vous travaillez.
- Sous Linux / macOS : ~/.claude/skills/
- Sous Windows : %USERPROFILE%\.claude\skills\ (généralement C:\Users\<votre-user>\.claude\skills\)
- C'est la portée que nous allons utiliser dans ce tutoriel.
Portée projet : Le skill est placé dans .claude/skills/ à la racine d'un dépôt Git. Il est alors versionné avec le code, partagé automatiquement avec toute l'équipe qui clone le dépôt. C'est l'option à retenir pour des skills spécifiques à un projet (conventions de commit maison, génération de doc d'API dédiée, etc.).
Portée plugin / marketplace : Un skill peut être packagé dans un plugin Claude Code et distribué via la marketplace. C'est le format à viser quand vous souhaitez diffuser votre skill au-delà de votre équipe, mais c'est aussi le plus lourd à produire. Nous n'y toucherons pas aujourd'hui.

Deux modes d'invocation

Une fois le Skill en place, il peut être déclenché de deux manières différentes :

Invocation explicite : vous tapez /<nom-du-skill> dans l'invite de Claude Code, par exemple /tech-doc. Idéal quand vous savez précisément ce que vous attendez.
Auto-déclenchement : Claude parcourt l'ensemble des Skills disponibles et, en fonction de leur description, décide de lui-même d'en invoquer un si le contexte s'y prête. Dire "documente-moi la procédure qu'on vient de voir" peut suffire à déclencher notre futur tech-doc, sans que vous ayez à taper la commande.

C'est cette seconde modalité qui change tout. Elle transforme vos skills en réflexes de l'assistant qu'il utilise de lui-même : vous écrivez votre souhait en langage naturel, Claude reconnaît qu'un skill correspond, et l'utilise. Mais pour que la magie opère, il faut que la description soit bien rédigée, car c'est elle que Claude utilise pour savoir si le skill peut l'aider pour la tâche demandée ou non. Nous allons y revenir au moment d'écrire notre SKILL.md.

Création du Skill tech-doc

Préparer l'arborescence

Passons à l'action ! Nous allons créer un Skill nommé tech-doc qui produira une doc technique (runbook) à partir du sujet de la discussion en cours. L'arborescence cible est la suivante :

tech-doc/
├── SKILL.md
└── templates/
    └── runbook.md

Ce dossier doit être placé dans ce que nous avons décrit comme le niveau utilisateur précédemment. Sous Linux ou macOS, en une commande :

# Création de l'arborescence du Skill (Linux / macOS)
mkdir -p ~/.claude/skills/tech-doc/
mkdir ~/.claude/skills/tech-doc/templates

Sous Windows, en PowerShell :

# Création de l'arborescence du Skill (Windows PowerShell)
New-Item -ItemType Directory Force -Path "$env:USERPROFILE\.claude\skills\tech-doc"
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.claude\skills\tech-doc\templates"

Une fois les dossiers créés, pensez à vérifier dans Claude Code que votre Skill sera bien détecté. La commande /skills affiche les skills chargés dans la session courante : si votre tech-doc n'y apparaît pas (après l'avoir écrit, bien sûr), c'est généralement qu'un fichier est au mauvais endroit, ou que le fichier du SKILL.md est mal formé.

Rédaction du fichier SKILL.md

Nous allons à présent rédiger le cœur du Skill. Ouvrez le fichier SKILL.md dans votre éditeur préféré :

---
name: tech-doc
description: Génère une documentation technique au format runbook à partir du sujet de la conversation en cours. À invoquer quand l'utilisateur demande de "documenter", "produire un runbook", "formaliser une procédure", "mettre au propre les étapes" ou toute formulation équivalente visant à transformer un échange technique en documentation réutilisable.
---
    
# Skill : tech-doc
## Objectif
Produire un **runbook court** qui synthétise la procédure technique discutée dans la conversation en cours.

## Procédure
1.  Lire le template de référence situé dans `templates/runbook.md` (chemin relatif à l'emplacement de ce Skill) et en respecter strictement la structure.
2.  Reprendre les éléments factuels de la conversation (commandes exécutées, fichiers modifiés, décisions prises) sans en inventer.
Mentionne notamment les problèmes rencontrés et leur solutions.
3.  Ne rien ajouter qui n'ait été discuté : si une section du template n'est pas documentable depuis la conversation, écrire explicitement `À compléter` plutôt que de combler avec du contenu générique.
4.  Produire le résultat dans un fichier `runbook-<slug>.md` à la racine du dossier de travail courant, où `<slug>` est un identifiant court et lisible du sujet.
5.  À la fin, confirmer à l'utilisateur l'emplacement du fichier créé.

## Règles de forme
*   Français, vouvoiement.
*   Commandes shell dans des blocs de code avec langage précisé (`bash`, `powershell`, etc.).
*   Pas de contenu promotionnel, pas d'emoji.
*   Longueur cible : 1 à 2 pages maximum.

Quelques points méritent qu'on s'y attarde. Le champ name doit être unique sur votre poste : c'est lui qui sera reconnu comme commande d'invocation (/tech-doc). Le champ description, lui, est le levier de l'auto-déclenchement.

Il faut noter que la description est écrite à la troisième personne, de manière descriptive, comme si vous décriviez l'outil à un collègue qui doit décider quand l'utiliser. C'est exactement le rôle qu'elle joue pour Claude.

Le template runbook.md

Second fichier à créer : le modèle auquel notre SKILL.md fait référence. Son rôle est de figer la structure attendue, pour que toutes les docs produites se ressemblent, peu importe la conversation d'origine.

Ce fichier n'est pas obligatoire, son nom et format sont à adapter à vos besoins et un SKILL.md suffirait. Mais il me permet de vous montrer comment on peut passer des données additionnelles à un skill, notamment pour éviter de complexifier le .md.

Créez le fichier templates/runbook.md avec le contenu suivant :

# Runbook : <Titre de la procédure>
## But
   
<En une à deux phrases, quel est l'objectif opérationnel ?>
    
## Pré-requis
*   <Accès, droits, version de l'outil, etc.>

## Procédure
1.  <Étape 1 - avec la commande exacte si pertinent>
2.  <Étape 2>
3.  <Étape 3>

## Validation
* <Comment vérifier que l'opération est réussie (commande, log, test fonctionnel) ?>
    
## Rollback
* <Comment revenir à l'état antérieur si quelque chose se passe mal ?>
    
## Références  
*   <Liens vers la doc officielle, tickets, articles connexes>

Voilà, notre skill est complet. Un petit conseil au passage, hors sujet mais utile : versionnez votre dossier ~/.claude/skills/ dans un dépôt Git personnel. Avec le temps, vous allez accumuler plusieurs skills (celui-ci, et sans doute d'autres pour vos usages récurrents), et il serait dommage de les perdre à chaque changement de machine. Un simple git init dans ce dossier, poussé sur un dépôt et vos skills vous suivront partout.

Utilisation du Skill au quotidien

Invocation explicite

Bien ! Testons maintenant notre skill. Lancez Claude Code dans n'importe quel dossier, discutez d'un sujet technique pendant quelques échanges, puis tapez simplement :

/tech-doc

Claude lit alors le SKILL.md, suit les instructions qu'il contient (lecture du template, extraction des éléments de la conversation, génération du runbook), et crée le fichier dans votre dossier de travail. C'est aussi simple que cela.

Si rien ne se passe ou si Claude vous répond qu'il ne connaît pas ce skill, le réflexe est de taper /skills pour vérifier qu'il figure bien dans la liste chargée. Les causes classiques d'un skill qui reste "muet" sont : en-tête du SKILL.md mal fermé (les trois tirets --- d'ouverture ou de fermeture oubliés), fichier placé au mauvais endroit, ou encore encodage du fichier qui n'est pas de l'UTF-8.

Voici à quoi ressemble cette invocation explicite :

Invocation explicite d'un skill dans Claude Code.

Nous voyons ici le skill (tech-doc), puis la sortie de son exécution et le chemin vers le fichier créé.

Auto-déclenchement par Claude

Voyons à présent la seconde modalité, super pratique et confortable à l'usage. Reprenez une conversation technique, puis au moment de la clore, formulez simplement une demande en langage naturel :

"Pour mémoire, documente-moi la procédure qu'on vient de dérouler en runbook."

Vous verrez alors Claude annoncer qu'il invoque le Skill tech-doc, puis produire le runbook. Il a fait le lien tout seul, grâce à la description du SKILL.md qui mentionne explicitement les verbes "documenter" et "procédure". C'est tout l'intérêt d'une description bien écrite : vous ne pensez plus au skill, c'est le skill qui vient à vous.

Utilisation autonome du skill par Claude Code d'après ma demande en langage naturelle.

Suite à notre demande en langage naturel, Claude identifie le skill à utiliser et l'exécute de lui-même. Comme précédemment, à l'activation du skill, Claude lit les instructions du SKILL.md et enchaîne avec ce qui est demandé à l'intérieur : la lecture du fichier modèle runbook.md, c'est ce que je montre dans la capture d'écran ci-dessus.

Il faut savoir que plusieurs skills peuvent coexister et se chevaucher partiellement. Dans ce cas, Claude choisit celui dont la description colle le mieux à la demande. D'où l'importance, à mesure que votre bibliothèque de skills grandira, de rester spécifique dans vos descriptions, et d'éviter les formulations trop larges qui risqueraient de déclencher le mauvais skill au mauvais moment.

Voilà, nous avons un runbook propre, structuré, prêt à être rangé dans votre wiki interne. Et surtout, le même /tech-doc fonctionnera à l'identique dans votre prochaine conversation, qu'elle porte sur une GPO, un script PowerShell ou un debug fréquent sur les postes utilisateur. Vous avez défini la structure une fois, et vous la réutilisez à l'infini.

Conclusion

Nous avons vu dans cet article ce qu'est un skill Claude Code, comment le placer selon la portée recherchée (utilisateur, projet, plugin), comment rédiger un SKILL.md dont la description permet un auto-déclenchement intelligent par Claude, et comment lui donner un fichier de template pour figer la structure de la sortie. Nous avons également appris à l'invoquer de deux manières (explicite via /tech-doc, ou en langage naturel).

N'hésitez pas à partager vos propres idées de Skills adminsys dans les commentaires, ou à venir échanger avec notre communauté sur notre serveur Discord !

Ajouter IT-Connect à mes
sources préférées

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

Claude Code : qu’est-ce qu’un Skill et comment en créer un ?