Compétences Claude Code : Créez des flux de travail personnalisés pour votre assistant de codage IA

Claude Code est livré avec un assistant IA polyvalent. Les compétences vous permettent de le spécialiser. Une compétence 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, revoir 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 suivant notre design system, utilisant nos hooks personnalisés, avec des gestionnaires d’erreurs appropriés et des attributs d’accessibilité » est une compétence.

Ce que sont réellement les compétences

Une compétence est un fichier markdown dans .claude/commands/ (au niveau du projet) ou ~/.claude/commands/ (global). Lorsque vous tapez /nom-de-la-competence dans Claude Code, le contenu du fichier est injecté dans la conversation comme instructions.

.claude/
  commands/
    deploy.md          # /deploy
    review-pr.md       # /review-pr
    write-test.md      # /write-test

C’est tout. Pas de syntaxe spéciale, pas de compilation, pas de SDK. Juste du markdown qui décrit comment faire quelque chose.

Écrire votre première compétence

Voici un exemple concret : une compétence qui applique les conventions de messages de commit de votre équipe.

Créez .claude/commands/commit.md :

# Workflow de Commit

## Étapes
1. Exécutez `git diff --staged` pour voir ce qui est en cours de commit
2. Analysez les changements et catégorisez : feat, fix, refactor, docs, test, chore
3. Rédigez un message de commit suivant notre convention :
   - Format : `type(scope) : description`
   - Scope est le nom du package ou module
   - Description à l’impératif, en minuscules, sans point final
   - Le corps explique le POURQUOI, pas le QUOI
4. Si les changements touchent plusieurs scopes, créez des commits séparés
5. Exécutez `git commit -m "message"` avec le message généré

## Règles
- N’utilisez jamais `--no-verify` pour passer outre les hooks
- Ne modifiez jamais un commit déjà publié
- Si les tests échouent lors du pre-commit, corrigez 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`

Maintenant, /commit donne à Claude Code un workflow structuré au lieu d’une instruction vague « commit mes changements ».

Modèles de conception des compétences

Le modèle checklist

Idéal pour les tâches avec plusieurs étapes de vérification.

# Checklist avant déploiement

Avant de déployer, vérifiez chaque point :

- [ ] `pnpm typecheck` passe
- [ ] `pnpm test` passe
- [ ] Pas de console.log dans le code de production
- [ ] Variables d’environnement documentées dans .env.example
- [ ] Migrations de base de données réversibles
- [ ] Changements API rétrocompatibles

Si une vérification échoue, arrêtez-vous et signalez le problème. Ne poursuivez pas le déploiement.

Le modèle arbre décisionnel

Idéal pour les tâches où l’approche dépend du contexte.

# Workflow de correction de bug

1. Reproduisez le bug (trouvez ou écrivez un test qui échoue)
2. Identifiez la cause racine :
   - Si c’est une erreur de type → corrigez la définition de type à la source
   - Si c’est une condition de concurrence → ajoutez un verrouillage/séquençage approprié
   - Si c’est une validation manquante → ajoutez une validation de schéma à la frontière
   - Si c’est une erreur logique → corrigez et ajoutez un test de régression
3. Vérifiez que la correction ne casse pas les tests existants
4. Écrivez un test qui aurait détecté ce bug

Le modèle template

Idéal pour générer une sortie cohérente.

# Nouveau point d’API

Créez un nouveau point d’API suivant nos conventions :

## Structure des fichiers
- Gestionnaire de route : `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
- Limitation de débit
- Réponses d’erreur structurées avec errorResponse()
- Réponses de succès avec successResponse()
- Commentaires de documentation OpenAPI

Installer des compétences communautaires

L’écosystème Claude Code dispose d’une bibliothèque croissante de compétences communautaires. Installez-les avec :

npx add-skill username/repo-name -y

Collections populaires de compétences :

• coreyhaines31/marketingskills (29 compétences marketing/SEO)
• hedging8563/lemondata-api-skill (intégration API LemonData)

Les compétences installées apparaissent dans ~/.claude/commands/ et fonctionnent dans tous les projets.

Compétences de projet vs globales

Emplacement	Périmètre	Cas d’usage
.claude/commands/	Ce projet uniquement	Conventions de projet, workflows de déploiement
~/.claude/commands/	Tous les projets	Préférences personnelles, outils généraux

Les compétences de projet doivent être commitées dans votre repo pour que toute l’équipe en bénéficie. Les compétences globales sont pour les préférences personnelles de workflow.

Avancé : compétences avec hooks

Les compétences peuvent référencer des hooks (commandes shell exécutées à des événements spécifiques) pour une application automatisée :

# Vérification avant commit

Avant chaque 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"
  }
}

Conseils pour des compétences efficaces

1. Soyez précis sur les chemins de fichiers et conventions de nommage. « Créer un composant » est vague. « Créer un composant dans src/components/ui/ en utilisant la convention PascalCase » est exploitable.

2. Incluez des exemples de sortie correcte. Claude Code apprend mieux à partir d’exemples que de règles abstraites.

3. Définissez ce qu’il NE FAUT PAS faire. « Ne jamais utiliser le type any » est plus applicable que « utiliser les bons types ».

4. Gardez les compétences ciblées. Une compétence par workflow. Une compétence de 200 lignes qui couvre tout est moins utile que cinq compétences de 40 lignes qui gèrent chacune bien une tâche.

5. Versionnez vos compétences. Au fur et à mesure que vos conventions évoluent, mettez à jour les compétences. Des compétences obsolètes sont pires que pas de compétences car elles imposent d’anciens schémas.

Impact concret

Les équipes qui adoptent les compétences constatent des améliorations constantes :

• Les cycles de revue de code diminuent car les conventions sont appliquées avant la revue
• Le temps d’intégration diminue car les nouveaux développeurs reçoivent les mêmes consignes 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 compétences) et le retour sur investissement se cumule à chaque interaction.

---

Construisez avec l’IA, guidé par vos propres règles. lemondata.cc fournit l’infrastructure API pour des outils de développement pilotés par IA.