Create Skill — Créateur de skills Claude Code

Guide la création de skills de qualité pour Claude Code — de l'idée au fichier prêt à l'emploi.

Anatomie d'une skill

skills/
└── ma-skill/
    └── SKILL.md          # Requis — frontmatter YAML + instructions
    └── reference/        # Optionnel — guides, exemples, données

Format SKILL.md

---

name: ma-skill
description: "Quand et pourquoi cette skill se charge — inclure les déclencheurs, contextes et mots-clés pour que Claude sache quand l'activer automatiquement."

Titre — Sous-titre court

Phrase d'introduction : ce que fait la skill et pourquoi elle existe.

Sections d'instructions

Instructions que Claude suivra quand la skill est active.

Règles du frontmatter

Champ	Format	Obligatoire
name	kebab-case, lowercase	Oui
description	Guillemets doubles, une phrase dense	Oui

Scope — Où créer la skill

Scope	Chemin	Quand
Plugin codebloom	skills/<name>/SKILL.md (racine codebloom)	Skill distribuée avec le plugin
Projet	skills/<name>/SKILL.md (racine du projet courant)	Skill spécifique à ce projet
Global	~/.claude/skills/<name>/SKILL.md	Skill active sur tous les projets

Par défaut, proposer le scope projet. Demander si l'utilisateur veut un autre scope.

Process

1. Interview — Comprendre le besoin

Poser ces 4 questions (adapter selon le contexte, ne pas poser celles dont la réponse est évidente) :

1. Quoi — Que doit faire la skill ? Quel comportement Claude doit-il adopter ?
2. Quand — Dans quels contextes doit-elle se déclencher ? (actions utilisateur, types de fichiers, patterns de code, phrases-clés)
3. Format — Quel est le résultat attendu ? (texte, modifications de fichiers, checklist, rapport)
4. Scope — Projet, global, ou plugin codebloom ?

Creuser les cas limites :

• Quand la skill ne doit PAS se déclencher (faux positifs)
• Interactions avec d'autres skills existantes (complémentarité, chevauchement)
• Niveau d'intervention : bloquant (impose) ou consultatif (signale et guide)

Ne pas avancer tant que le besoin n'est pas clair. Un besoin flou produit une skill inutile.

2. Recherche — Vérifier le contexte

Avant d'écrire :

• Lister les skills existantes dans le scope cible (éviter les doublons)
• Vérifier les conventions du projet (CLAUDE.md, DESIGN_SYSTEM.md)
• Identifier si une skill existante pourrait être étendue plutôt qu'une nouvelle créée

Si une skill existante couvre 80%+ du besoin, proposer de l'enrichir au lieu d'en créer une nouvelle.

3. Rédaction — Écrire la skill

La description (frontmatter) — C'est le déclencheur

La description est ce que Claude lit pour décider s'il charge la skill. C'est le champ le plus critique.

Structure efficace :

"[Rôle]. Activer quand : [liste de déclencheurs concrets]. [Mots-clés et phrases alternatives]. Ne pas activer [exclusions]."

Principes :

• Décrire les contextes concrets, pas des abstractions ("quand Claude modifie du HTML/JSX" > "quand du code UI est impliqué")
• Inclure les variantes de formulation ("créer", "ajouter", "générer", "build", "make")
• Lister les exclusions explicites pour éviter les faux positifs
• Une description trop vague se déclenche partout, trop restrictive se déclenche jamais

Le corps — Ce sont les instructions

Règles d'écriture :

1. Impératif — "Vérifie que..." pas "Il faudrait vérifier que..."
2. Expliquer le pourquoi — Chaque règle importante explique son raisonnement. "Ne pas imbriquer plus de 3 niveaux — au-delà, la complexité cognitive explose" > "Ne JAMAIS imbriquer plus de 3 niveaux"
3. Concret — Exemples de code, tableaux, templates. Pas de principes abstraits sans illustration
4. Progressif — Les informations essentielles d'abord, les détails ensuite. Claude charge d'abord le frontmatter (~100 mots), puis le corps si pertinent
5. Autonome — La skill doit fonctionner sans contexte externe. Si elle dépend d'un fichier, le mentionner explicitement

Structure recommandée :

Titre — Sous-titre

Phrase d'intro (quoi + pourquoi).

Activation (optionnel — si les conditions sont complexes)

• Contextes de déclenchement
• Contextes d'exclusion

Principes / Règles

Les comportements attendus, organisés par thème.

Process (si la skill est procédurale)

Étapes numérotées.

Anti-patterns (optionnel)

Ce qu'il ne faut PAS faire, avec le pourquoi.

Taille : Viser < 200 lignes. Au-delà, extraire les détails dans un dossier reference/. Claude charge le SKILL.md entier — un fichier trop long dilue les instructions critiques.

Skill garde-fou vs. skill procédurale

Type	Comportement	Exemples
Garde-fou	Se charge en fond, signale et guide sans bloquer	code-quality, security-first, accessibility
Procédurale	Suit un process étape par étape quand invoquée	interview, wp-pack

Un garde-fou ne doit jamais bloquer le travail — il alerte, propose des alternatives, et laisse l'utilisateur décider. Une skill procédurale peut imposer un ordre d'étapes.

4. Création — Écrire le fichier

1. Créer le dossier skills/<name>/
2. Écrire SKILL.md avec frontmatter + corps
3. Si la skill a des ressources (guides, exemples), les placer dans reference/

5. Vérification — Valider la skill

Checklist avant de confirmer :

• name en kebab-case, unique parmi les skills existantes
• description contient des déclencheurs concrets ET des exclusions
• Le corps est < 200 lignes (ou les détails sont dans reference/)
• Chaque règle importante explique son pourquoi
• Pas de chevauchement majeur avec une skill existante
• Le scope est correct (projet / global / plugin)
• La skill ne bloque pas le travail (garde-fou) ou a un process clair (procédurale)

6. Documentation — Mettre à jour les références

Selon le scope :

• Plugin codebloom : Mettre à jour CLAUDE.md (tableau Skills) et README.md
• Projet : Mentionner dans le CLAUDE.md du projet
• Global : Informer l'utilisateur que la skill est active sur tous ses projets

Exemples de bonnes descriptions

Trop vague — se déclenche partout

description: "Aide avec le code"

Trop restrictive — ne se déclenche jamais

description: "Activer uniquement quand l'utilisateur tape exactement /check-types"

Juste — contextes concrets + exclusions

description: "Garde-fou TypeScript strict. Activer quand Claude écrit ou modifie du TypeScript : types any, assertions non-null, enums, interfaces. Couvre : inférence, generics, utility types, discriminated unions. Ne pas activer pour du JavaScript pur ou du code non-TypeScript."

Règles

• Ne pas deviner — Si le besoin est flou, poser des questions. Mieux vaut 2 minutes d'interview que 10 minutes de réécriture.
• Une skill = une responsabilité — Si la skill fait deux choses distinctes, c'est deux skills.
• Enrichir > Créer — Vérifier si une skill existante peut absorber le besoin avant d'en créer une nouvelle.
• La description fait le travail — 80% de l'efficacité d'une skill dépend de sa description. Investir le temps là-dessus.