Comment créer des Claude Skills utiles sans coder ?

Pour créer des Claude Skills, je pars d’un dossier simple avec un fichier SKILL.md, puis j’ajoute du code seulement si le besoin l’impose. Le vrai sujet, c’est la description, le workflow et ce que Claude charge au bon moment.

C’est quoi un Claude Skill ?

Un Claude Skill, c’est un petit dossier réutilisable qui décrit une compétence que Claude peut appliquer quand le contexte s’y prête. Le cœur du dossier, c’est un fichier obligatoire SKILL.md. C’est lui qui explique à Claude quoi faire, quand le faire, comment le faire, et sous quelle forme rendre le résultat.

Je le vois comme une fiche méthode propre. Pas juste un prompt qu’on colle à la main. Plutôt une façon de documenter un process récurrent, par exemple analyser un devis, préparer un compte rendu client, contrôler une facture, reformuler une offre, générer une réponse SAV. Chez un client, on avait transformé une procédure interne assez floue en Skill. Rien de magique, juste des règles claires. Le gain venait surtout du fait que tout le monde obtenait enfin des réponses cohérentes.

Dans SKILL.md, je mets généralement ces éléments :

• La finalité : Ce que le Skill doit produire et pourquoi il existe.
• Les conditions d’utilisation : Les cas où Claude doit l’activer, et ceux où il ne doit pas l’utiliser.
• Le workflow : Les étapes à suivre, dans l’ordre, sans improviser.
• Les règles : Les contraintes métier, le ton, les vérifications, les erreurs à éviter.
• Le format de sortie : Le rendu attendu, par exemple un tableau, une synthèse, une checklist ou un email prêt à envoyer.

Le dossier peut rester très simple. Un seul fichier Markdown suffit parfois. Mais on peut aussi ajouter des ressources complémentaires : des scripts, des modèles, des exemples, des fichiers de référence. Ça devient utile quand le Skill doit s’appuyer sur une grille d’analyse, un modèle d’email, une nomenclature produit ou une procédure interne.

La logique intéressante, c’est la portabilité. Avec la norme ouverte Agent Skills, on structure une compétence de manière plus propre qu’un prompt isolé. L’idée n’est pas de sur-vendre le truc. C’est juste plus robuste. Claude peut reconnaître le Skill, comprendre son périmètre et l’appliquer comme une méthode réutilisable.

analyse-devis-client/
  SKILL.md
  references/
    grille-controle-devis.md
    exemples-devis-valides.md
  scripts/
    verifier-totaux.py

Élément	Rôle	Statut
SKILL.md	Décrit la finalité, les règles, le workflow et le format de sortie.	Obligatoire
references	Stocke des exemples, modèles, grilles ou documents métier.	Optionnel
scripts	Ajoute des traitements automatisés si besoin.	Optionnel
Exemples	Aide Claude à comprendre le niveau attendu et les cas limites.	Optionnel

Faut-il coder pour créer un skill ?

Non, il n’est pas nécessaire de coder pour créer un Claude Skill basique. Un simple fichier Markdown, souvent nommé SKILL.md, suffit largement pour commencer. C’est même ce que je conseille presque toujours au départ, parce qu’un bon skill commence par une intention propre, pas par du code.

Si votre objectif, c’est de donner des instructions à Claude, cadrer un format de réponse, appliquer une méthode ou guider une tâche répétable, le Markdown fait très bien le travail. Vous décrivez le contexte, les règles, les étapes à suivre, le style attendu, et Claude s’appuie dessus quand le skill est utilisé.

Le code devient utile dans un autre cas. Quand vous voulez des traitements déterministes, c’est-à-dire un résultat prévisible avec les mêmes données d’entrée. Ou quand vous voulez transformer des fichiers, analyser des données structurées, générer des visualisations, appeler une API, connecter un outil externe. Là, un script peut sécuriser le résultat et éviter que Claude improvise.

La règle simple que je garde en tête est celle-ci : instructions seules = pas de code. Automatisation, déterminisme ou intégration = code.

Chez les clients, le piège classique, c’est de coder trop tôt. On ajoute un script Python, une logique compliquée, parfois même une intégration, alors que le workflow n’est pas encore clair. Et au final, on automatise un flou. Je préfère d’abord écrire le skill en Markdown, le tester sur quelques cas réels, puis seulement ajouter du code si le besoin résiste.

Nom : Synthèse de réunion

Description : Aider à transformer des notes de réunion brutes en synthèse claire et exploitable.

Quand l’utiliser : Utiliser ce skill quand l’utilisateur fournit des notes, une transcription ou un compte rendu informel de réunion.

Étapes à suivre :
1. Identifier les sujets principaux.
2. Extraire les décisions prises.
3. Lister les actions à mener avec les responsables si disponibles.
4. Signaler les points flous ou incomplets.
5. Produire une synthèse courte et structurée.

Format de sortie :
- Résumé
- Décisions
- Actions
- Points à clarifier

Avant d’ajouter un script, je me pose toujours quelques questions simples :

• Est-ce que Claude peut faire ça correctement avec de bonnes instructions ?
• Est-ce que le résultat doit être exactement reproductible ?
• Est-ce qu’il y a des données à transformer ou calculer ?
• Est-ce qu’il faut lire, générer ou modifier un fichier ?
• Est-ce qu’un outil externe ou une API doit être appelée ?

Si la réponse est non partout, je reste en Markdown. C’est plus rapide, plus lisible, et souvent largement suffisant.

Comment Claude active un skill ?

Claude active un skill progressivement. Il ne charge pas tout d’un coup. Il commence par les métadonnées, puis il lit les instructions, puis il va chercher les ressources seulement si elles sont utiles. C’est ce qu’on appelle la divulgation progressive. Dit simplement, Claude ouvre juste ce dont il a besoin, au moment où il en a besoin.

Discovery, c’est la première étape. Claude regarde surtout le nom du skill et sa description pour décider si ce skill colle à la demande. Et là, la description fait une grosse partie du travail. Elle doit dire clairement quand utiliser le skill, pour quel type de demande, et dans quel contexte. J’ai vu des skills très bien faits ne jamais être appelés juste parce que leur description était trop vague. Un skill “Analyse commerciale” ne dit pas grand-chose. Un skill “À utiliser pour analyser un fichier CSV de ventes, identifier les tendances, les anomalies et produire une synthèse actionnable pour une équipe business”, là Claude comprend.

Instruction loading, c’est la deuxième étape. Si Claude estime que le skill est pertinent, il charge le corps du fichier SKILL.md. C’est là qu’on met le workflow, les règles, les contraintes, les formats de sortie, les choses à vérifier. Ces instructions deviennent importantes dans la session. Dans Claude Code, c’est encore plus sensible, parce que le contenu rendu peut rester présent comme instruction persistante. Donc si j’écris une règle floue ou trop ponctuelle, elle peut polluer la suite.

Supporting resources, c’est la troisième étape. Claude ne lit pas automatiquement les scripts, les exemples ou les fichiers de référence. Il les consulte seulement à la demande. Bonne nouvelle : un fichier de référence ne consomme pas de tokens tant qu’il n’est pas lu. Les scripts, eux, peuvent être exécutés via bash, et seul leur résultat entre dans le contexte. C’est très pratique pour éviter de charger 200 lignes de logique quand on a juste besoin du résultat.

Étape	Ce que Claude lit	Ce que ça implique
Discovery	Nom et description	La description doit être précise, orientée usage, avec le bon contexte.
Instruction loading	Contenu du SKILL.md	Les règles doivent être claires, durables et utiles pendant toute la session.
Supporting resources	Scripts, exemples, fichiers de référence	Les ressources doivent être séparées et appelées seulement quand elles apportent vraiment quelque chose.

Mon conseil simple : Écrivez des instructions durables plutôt que des étapes ponctuelles. Un bon skill ne dit pas juste “fais ça maintenant”. Il donne à Claude une façon fiable de raisonner et de produire le bon résultat, même quand la demande varie un peu.

Où placer et nommer ses skills ?

Dans Claude Code, je range mes skills dans .claude/skills/. C’est le dossier à retenir. Les anciennes commandes personnalisées de .claude/commands/ existent encore dans beaucoup de projets, mais côté commande, elles ont été fusionnées avec les skills. En pratique, un skill et une custom command déclenchent maintenant le même mécanisme.

Le point important, c’est le nom. Un fichier de commande et un skill qui portent le même nom produisent la même commande. S’il y a conflit, le skill prend le dessus. C’est logique, mais ça peut surprendre quand on migre un vieux projet. J’ai déjà vu un client modifier une commande dans .claude/commands/ pendant vingt minutes, sans comprendre pourquoi Claude ignorait ses changements. Le skill du même nom existait dans .claude/skills/, et c’est lui qui gagnait.

.claude/
  skills/
    summarize-client-call/
      SKILL.md
    create-seo-brief/
      SKILL.md
    clean-csv-data/
      SKILL.md

  commands/
    clean-csv-data.md

Dans cet exemple, clean-csv-data existe deux fois. La commande appelée sera celle du skill dans .claude/skills/clean-csv-data/, pas celle de .claude/commands/clean-csv-data.md.

Je conseille de nommer les skills comme des actions concrètes. Le nom doit permettre de comprendre immédiatement ce que Claude va faire. Si le nom est flou, Claude doit deviner. Et si Claude doit deviner, vous venez d’ajouter de l’aléatoire dans votre workflow.

Nom faible	Nom utile
assistant	summarize-client-call
data	clean-csv-data
seo	create-seo-brief
tools	generate-weekly-report

Je garde quelques règles simples.

• Court, parce qu’un nom trop long devient pénible à utiliser.
• Explicite, parce que le nom sert aussi d’indice à Claude.
• Orienté usage, avec un verbe si possible, comme clean, summarize, generate.
• Pas fourre-tout, parce qu’un skill nommé marketing finira toujours par faire trop de choses.

Avant de considérer un skill comme propre, je vérifie ça.

• Le skill est bien dans .claude/skills/.
• Son nom décrit une action claire.
• Il n’a pas un nom générique.
• Il n’entre pas en conflit avec une ancienne commande.
• S’il y a conflit, je sais que le skill prend le dessus.

Comment créer un premier skill fiable ?

Je crée d’abord un skill minimal, je le teste dans une vraie demande, puis j’ajoute des ressources uniquement si elles améliorent la fiabilité. C’est vraiment le réflexe que je garde. Sur un skill d’auditeur de qualité de données, je veux d’abord cadrer le raisonnement de Claude, pas construire une usine.

Je commence par un dossier simple, par exemple :

skills/auditeur-qualite-donnees/
  SKILL.md

Dans SKILL.md, je décris le moment où le skill doit s’activer, le workflow à suivre, les règles de contrôle, et le format de sortie attendu. Le point important, c’est d’éviter les consignes vagues du genre “analyse la qualité”. Je préfère dire quoi vérifier, dans quel ordre, et comment restituer les problèmes.

# Auditeur de qualité de données

Ce skill s’active quand l’utilisateur demande d’auditer un fichier, un extrait de données, un tableau collé dans la conversation, ou une structure de données fournie dans le contexte.

Workflow :
1. Identifier le type de données fourni.
2. Repérer les colonnes ou champs disponibles.
3. Vérifier la cohérence logique des valeurs.
4. Détecter les valeurs manquantes, doublons évidents, formats incohérents, ruptures de logique, libellés ambigus.
5. Signaler uniquement les problèmes observables dans les données fournies.
6. Ne pas inventer de règles métier absentes du contexte.

Règles :
- Séparer les anomalies certaines des points à vérifier.
- Ne pas promettre de correction automatique.
- Mentionner les limites si l’échantillon est trop petit.
- Proposer des contrôles complémentaires seulement s’ils sont pertinents.

Format de sortie :
Résumé court.
Tableau des anomalies.
Impact probable.
Actions recommandées.
Questions ouvertes si nécessaire.

Si j’ajoute un script, je le fais seulement pour un traitement déterministe via bash, par exemple compter des lignes, détecter des doublons exacts, ou lister des valeurs vides. Dans ce cas, seul l’output du script doit revenir dans le contexte, pas tout le fichier ni des logs inutiles. J’ai vu ça chez un client : trop de contexte tue la précision, surtout sur des fichiers sales.

Dans Claude Code, j’utilise ce dossier comme skill local, puis je lance une vraie demande du type : “Audite cet extrait CSV et rends-moi les anomalies au format prévu”. Je regarde si Claude suit le workflow, s’il reste prudent, et s’il ne déduit pas des règles métier qui ne sont pas écrites.

Pour Claude Web ou Desktop, je rends le skill disponible via l’upload du skill quand l’interface le permet. Je reste simple : même dossier, même SKILL.md, éventuellement des fichiers de référence si ça aide vraiment. Je ne pars pas sur des intégrations ou connecteurs non prévus.

Type de skill	Quand l’utiliser	Risque principal
Skill minimal	Pour cadrer une méthode, un format de sortie, des règles simples.	Trop vague si les règles ne sont pas assez explicites.
Skill avec fichiers de référence	Pour ajouter une nomenclature, une grille de contrôle, des exemples validés.	Ajouter des documents qui n’améliorent pas vraiment la réponse.
Skill avec scripts	Pour des contrôles déterministes, répétables, via bash par exemple.	Remonter trop d’output dans le contexte et polluer l’analyse.

Alors, vous commencez par quel skill ?

Les Claude Skills changent surtout une habitude : au lieu de répéter un prompt, je structure une compétence réutilisable. Un dossier, un SKILL.md propre, une description claire, et Claude sait quand charger les bonnes instructions. Le code n’est pas obligatoire. Il devient utile seulement quand on veut du déterminisme, des transformations ou des intégrations. Le point à ne pas rater, c’est la conception : nom, description, workflow, ressources chargées à la demande. Si vous partez simple, vous pouvez industrialiser vos usages sans alourdir vos sessions. Le bénéfice pour vous : moins de prompts copiés-collés, plus de cohérence, plus de contrôle.

FAQ

• Qu’est-ce qu’un Claude Skill ?
  Un Claude Skill est un dossier réutilisable qui contient au minimum un fichier SKILL.md. Ce fichier décrit la finalité du skill, les conditions d’utilisation, les étapes à suivre et le format de sortie attendu. On peut aussi ajouter des scripts, modèles, exemples ou fichiers de référence si le besoin le justifie.
• Est-ce qu’il faut savoir coder pour créer un Claude Skill ?
  Non. Pour un skill simple, du Markdown suffit. Le code devient utile si vous voulez automatiser un traitement déterministe, transformer des données, produire une analyse structurée ou vous connecter à des systèmes externes. Je conseille souvent de commencer sans code, puis d’en ajouter seulement quand c’est nécessaire.
• Pourquoi la description d’un skill est-elle si importante ?
  Parce que Claude lit d’abord les métadonnées, notamment le nom et la description, pour décider si le skill est pertinent. Une description floue réduit les chances d’activation au bon moment. Une bonne description explique clairement quand utiliser le skill, pour quelle demande et dans quel contexte.
• Les fichiers de référence consomment-ils des tokens ?
  Pas tant qu’ils ne sont pas lus. Claude charge les ressources complémentaires à la demande. C’est l’intérêt de la divulgation progressive : les fichiers de référence, exemples ou scripts peuvent rester disponibles sans encombrer le contexte inutilement.
• Quelle est la différence entre Claude Skills et custom commands ?
  Dans Claude Code, les anciennes custom commands et les skills ont été fusionnés. Un skill placé dans .claude/skills/ peut produire une commande. Si une commande et un skill portent le même nom, le skill prévaut. Ça pousse à bien nommer ses skills pour éviter les conflits.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent transformer leurs méthodes en systèmes fiables, pas juste empiler des outils. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos usages IA, automatiser vos process ou créer des workflows utiles avec Claude, vous pouvez me contacter.