Claude Code est livré avec un assistant IA polyvalent. Les skills (compétences) vous permettent de le spécialiser. Une skill est un fichier markdown qui apprend à Claude Code comment gérer un type de tâche spécifique : déployer sur Kubernetes, écrire des migrations de base de données, réviser des pull requests ou suivre les conventions de codage de votre équipe.
La différence entre « écris-moi un composant React » et « écris-moi un composant React en suivant notre design system, en utilisant nos hooks personnalisés, avec des error boundaries appropriées et des attributs d'accessibilité » réside dans une skill.
La documentation officielle de Claude Code précise désormais une chose : les commandes personnalisées ont été fusionnées dans les skills. Les fichiers existants dans .claude/commands/ fonctionnent toujours, mais les skills sont l'abstraction recommandée car elles supportent des métadonnées plus riches, des fichiers de support et un chargement automatique. Si vous standardisez le workflow d'une équipe aujourd'hui, construisez-le d'abord comme une skill et traitez les anciennes commandes comme une voie de compatibilité.
Ce que sont réellement les Skills
Une skill réside dans un répertoire avec un point d'entrée SKILL.md. Claude peut la charger automatiquement lorsque la description correspond à la tâche en cours, ou vous pouvez l'invoquer directement avec /nom-de-la-skill.
.claude/
skills/
deploy/
SKILL.md # /deploy
review-pr/
SKILL.md # /review-pr
write-test/
SKILL.md # /write-test
Claude supporte toujours .claude/commands/deploy.md, et la commande slash fonctionnera toujours. Mais la version moderne est .claude/skills/deploy/SKILL.md.
Cela ressemble à un petit changement de nom. Mais c'est important car les skills peuvent comporter des fichiers de support, du frontmatter, des contrôles d'invocation et des indices pour les sous-agents. Un simple fichier de commande peut dire à Claude quoi faire. Une skill peut dire à Claude comment votre équipe attend que le travail soit fait.
Écrire votre première Skill
Voici un exemple pratique : une skill qui impose les conventions de messages de commit de votre équipe.
Créez .claude/skills/commit/SKILL.md :
---
name: commit
description: Generate and validate conventional commits for this repo.
---
# Commit Workflow
## Étapes
1. Exécuter `git diff --staged` pour voir ce qui est committé
2. Analyser les changements et catégoriser : feat, fix, refactor, docs, test, chore
3. Écrire un message de commit suivant notre convention :
- Format : `type(scope): description`
- Le scope est le nom du package ou du module
- La description est à l'impératif, en minuscules, sans point final
- Le corps explique POURQUOI, pas QUOI
4. Si les changements touchent plusieurs scopes, créer des commits séparés
5. Exécuter `git commit -m "message"` avec le message généré
## Règles
- Ne jamais utiliser `--no-verify` pour ignorer les hooks
- Ne jamais amender des commits déjà publiés
- Si les tests échouent en pre-commit, corriger le problème d'abord
## Exemples
- `feat(billing): add stripe webhook handler`
- `fix(auth): handle expired refresh tokens`
- `refactor(api): extract rate limiter to shared package`
Désormais, /commit donne à Claude Code un workflow structuré au lieu d'une instruction vague comme « committe mes changements ».
Si vous avez déjà des fichiers de commandes hérités, gardez-les en fonctionnement pendant votre migration, mais ne continuez pas à investir dans l'ancienne structure. La documentation officielle est claire : les skills sont la voie de l'avenir.
Où résident les Skills désormais
Claude Code découvre actuellement les skills à partir de quatre emplacements :
- skills personnelles :
~/.claude/skills/<nom-de-la-skill>/SKILL.md - skills de projet :
.claude/skills/<nom-de-la-skill>/SKILL.md - skills de projet imbriquées dans les monorepos
- skills fournies par des plugins
Cela vous donne une séparation nette :
- les skills personnelles pour votre propre style de travail
- les skills de projet pour les conventions du repo
- les skills de plugin pour des workflows packagés réutilisables
Pour l'adoption par l'équipe, committez les skills de projet dans le repo. C'est la différence entre « j'ai un bon prompt sur mon ordinateur » et « l'équipe dispose désormais d'un workflow reproductible ».
Modèles de conception de Skills
Le modèle Liste de contrôle (Checklist)
Idéal pour les tâches comportant plusieurs étapes de vérification.
# Liste de contrôle pré-déploiement
Avant de déployer, vérifiez chaque point :
- [ ] `pnpm typecheck` passe avec succès
- [ ] `pnpm test` passe avec succès
- [ ] Aucun console.log dans le code de production
- [ ] Variables d'environnement documentées dans .env.example
- [ ] Les migrations de base de données sont réversibles
- [ ] Les changements d'API sont rétrocompatibles
Si une vérification échoue, arrêtez-vous et signalez le problème. Ne procédez pas au déploiement.
Le modèle Arbre de décision
Idéal pour les tâches où l'approche dépend du contexte.
# Workflow de correction de bug
1. Reproduire le bug (trouver ou écrire un test qui échoue)
2. Identifier la cause racine :
- S'il s'agit d'une erreur de type → corriger la définition du type à la source
- S'il s'agit d'une race condition → ajouter un verrouillage/séquençage approprié
- S'il manque une validation → ajouter une validation de schéma à la bordure
- S'il s'agit d'une erreur de logique → corriger et ajouter un test de régression
3. Vérifier que la correction ne casse pas les tests existants
4. Écrire un test qui aurait détecté ce bug
Le modèle Template
Idéal pour générer une sortie cohérente.
# Nouvel Endpoint API
Créer un nouvel endpoint API en suivant nos conventions :
## Structure des fichiers
- Route handler : `apps/api/src/routes/{resource}/{action}.ts`
- Schéma : `apps/api/src/schemas/{resource}.ts`
- Test : `apps/api/src/routes/{resource}/__tests__/{action}.test.ts`
## Éléments requis
- Schéma Zod pour la validation des requêtes
- Middleware d'authentification
- Rate limiting
- Réponses d'erreur structurées utilisant errorResponse()
- Réponses de succès utilisant successResponse()
- Commentaires de documentation OpenAPI
Installer des Skills de la communauté
L'écosystème Claude Code dispose d'une bibliothèque croissante de skills communautaires. Installez-les avec :
npx add-skill username/repo-name -y
Collections de skills populaires :
coreyhaines31/marketingskills(29 skills marketing/SEO)hedging8563/lemondata-api-skill(intégration de l'API LemonData)
Les skills installées apparaissent dans ~/.claude/commands/ et fonctionnent sur tous les projets.
Les packs de skills installés exposent de plus en plus de véritables skills plutôt que de simples fichiers markdown de commandes slash. Si vous maintenez votre propre repo, le modèle de OpenCode + LemonData s'applique ici aussi : gardez la skill proche du workflow, pas cachée dans des fichiers de prompts ad hoc.
Skills de Projet vs Globales
| Emplacement | Portée | Cas d'utilisation |
|---|---|---|
.claude/skills/ |
Ce projet uniquement | Conventions de projet, workflows de déploiement |
~/.claude/skills/ |
Tous les projets | Préférences personnelles, habitudes réutilisables |
.claude/commands/ |
Compatibilité héritée | Anciens fichiers de commandes slash qui fonctionnent encore |
Les skills de projet doivent être committées dans votre repo pour que toute l'équipe en bénéficie. Les skills globales sont destinées aux préférences de workflow personnelles.
Avancé : Skills avec Hooks
Les skills peuvent référencer des hooks (commandes shell qui s'exécutent lors d'événements spécifiques) pour une application automatisée :
# Vérification Pre-Commit
Avant tout commit, les hooks suivants s'exécutent automatiquement :
- `pre-commit` : exécute typecheck + lint
- `post-commit` : met à jour le changelog
Si un hook échoue, examinez la sortie d'erreur et corrigez le problème.
N'utilisez pas --no-verify pour contourner les hooks.
Les hooks eux-mêmes sont configurés dans .claude/settings.json :
{
"hooks": {
"pre-commit": "pnpm typecheck && pnpm lint-staged"
}
}
C'est là que les skills deviennent plus que de simples extraits de prompts. Une configuration d'équipe utile comporte souvent trois couches :
- une skill qui indique le workflow à Claude
- des hooks qui imposent le workflow
- une documentation de repo qui explique le workflow aux humains
Si l'une de ces couches manque, le système devient fragile. Une skill sans hooks devient consultative. Des hooks sans skills deviennent opaques. Une doc sans l'un ou l'autre devient une politique obsolète que personne ne suit.
Les fichiers de support sont la véritable amélioration
La raison la plus importante de préférer les skills à l'ancien markdown de commande est la gestion des fichiers de support.
Avec un fichier de commande, tout doit résider dans un seul bloc. Avec un répertoire de skill, vous pouvez conserver :
- des templates
- des exemples
- des helpers shell
- des notes de référence plus longues
- des scripts de validation
Cela vous permet de garder SKILL.md court et pertinent tout en donnant à Claude du matériel structuré à exploiter quand c'est nécessaire.
C'est particulièrement utile pour :
- les workflows de déploiement
- les listes de contrôle de migration de schéma
- les processus de revue de code en plusieurs étapes
- les guides d'intégration spécifiques au produit
Si votre équipe utilise également plusieurs modèles ou plusieurs outils de codage, associez cette page au comparatif des modèles de codage et au guide de configuration Cursor / Cline / Windsurf. De bonnes skills comptent encore plus lorsque le modèle sous-jacent ou l'éditeur change.
Conseils pour des Skills efficaces
Soyez spécifique sur les chemins de fichiers et les conventions de nommage. « Créer un composant » est vague. « Créer un composant dans
src/components/ui/en utilisant le nommage PascalCase » est actionnable.Incluez des exemples de sortie correcte. Claude Code apprend mieux à partir d'exemples que de règles abstraites.
Définissez ce qu'il ne faut PAS faire. « Ne jamais utiliser le type
any» est plus facile à faire respecter que « utiliser des types appropriés ».Gardez les skills ciblées. Une skill par workflow. Une skill de 200 lignes qui couvre tout est moins utile que cinq skills de 40 lignes qui gèrent chacune bien une tâche.
Versionnez vos skills. À mesure que vos conventions évoluent, mettez à jour les skills. Des skills obsolètes sont pires que pas de skills du tout car elles imposent d'anciens modèles.
Décidez si la skill doit se charger automatiquement ou ne s'exécuter que manuellement. Beaucoup d'équipes oublient cela et se demandent ensuite pourquoi Claude invoque une skill de déploiement dans des conversations non liées.
Impact concret
Les équipes qui adoptent les skills rapportent des améliorations constantes :
- Les cycles de revue de code diminuent car les conventions sont appliquées avant la revue
- Le temps d'onboarding diminue car les nouveaux développeurs reçoivent les mêmes conseils que les vétérans
- La qualité du code généré par l'IA s'améliore car l'IA dispose d'un contexte explicite sur les standards du projet
L'investissement est faible (30 minutes pour écrire vos premières skills) et le bénéfice s'accumule à chaque interaction.
Le modèle mental le plus utile est celui-ci : une skill n'est pas un raccourci pour Claude. C'est un artefact de workflow versionné pour votre équipe.
Si vous ne devez écrire qu'une seule skill, choisissez celle qui encode la décision répétée la plus coûteuse de votre codebase.
Construisez avec l'IA, guidé par vos propres règles. LemonData vous donne une seule clé API pour les modèles de codage de différents fournisseurs, de sorte qu'une fois vos workflows encodés en skills, vous pouvez changer de modèle sans reconstruire toute votre chaîne d'outils.