Patterns et bonnes pratiques pour les Skills
Patterns courants, anti-patterns, et les habitudes des grands constructeurs de skills
⏱ Estim. ~8 min
01 · Lire
Maintenant que tu sais comment les skills fonctionnent, regardons les patterns que les devs utilisent vraiment au quotidien.
Les skills les plus populaires tombent dans quelques catégories : - Style de code — applique les conventions de nommage, les règles de format, les patterns de structure - Revue de code — checklists cohérentes pour relire des PR et des changements de code - Messages de commit — applique des formats comme Conventional Commits - Tests — colle au framework et aux patterns de test de ton projet - Documentation — standardise la façon d'écrire les docs, les commentaires, les README
Chaque pattern suit la même structure : règles claires, exemples concrets, format de sortie explicite. On va voir les deux plus utiles.
Points clés
- Les skills de style de code appliquent les conventions de nommage, format, structure
- Les skills de revue fournissent une checklist cohérente pour les revues de code
- Les skills de messages de commit appliquent des formats comme Conventional Commits
- Les skills de tests collent aux patterns de test existants de ton projet
- Les skills de documentation standardisent l'écriture des docs
02 · Exemple de code
Voici un skill qui applique le format Conventional Commits pour tous les messages de commit.
commit-style/SKILL.md
---
name: Commit Message Style
description: Enforces Conventional Commits format
instructions: Use when creating git commits
---
## Format
All commits must follow Conventional Commits:
```
<type>(<scope>): <description>
[optional body]
```
## Types
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `refactor`: Code change that neither fixes nor adds
- `test`: Adding or updating tests
- `chore`: Maintenance (dependencies, CI, build)
## Rules
- Description must be lowercase, no period at the end
- Scope is optional but encouraged
- Body should explain WHY, not WHAT (the diff shows what)
- Max 72 characters for the first line
## Examples
Good: `feat(auth): add password reset flow`
Good: `fix(api): handle null response from payment gateway`
Bad: `Fixed stuff`
Bad: `Update code`
Regarde comme c'est précis — format exact, types énumérés, limite de caractères, exemples de bons et mauvais commits. Plus tes règles sont explicites, plus les commits de Claude sont cohérents. Une instruction vague comme « écris de bons messages de commit » ne sert à rien.
03 · Exemple de code
Voici un skill qui demande à Claude de coller aux conventions de test existantes de ton projet.
test-writer/SKILL.md
---
name: Test Writer
description: Writes tests matching project conventions
instructions: Use when writing or updating tests
---
## Conventions
- Use `describe` / `it` blocks (not `test`)
- Test file goes next to source: `Foo.ts` → `Foo.test.ts`
- Use `vi.fn()` for mocks (Vitest, not Jest)
- Arrange-Act-Assert pattern in every test
## What To Test
- Happy path first
- Error cases and edge cases
- Boundary values (0, 1, -1, empty string, null)
- Never test implementation details — test behavior
## Naming
`it('should return 404 when user not found')`
Not: `it('test user')`
Ce skill référence le framework de test spécifique du projet (Vitest) et ses patterns (describe/it, vi.fn). Une instruction générique du genre « écris de bons tests » ne sert à rien — Claude essaie déjà d'écrire de bons tests. Ce skill lui dit tes conventions à toi.
04 · Quiz
Souviens-toi : un skill doit ajouter des règles que Claude ne connaîtrait pas tout seul. Laquelle de ces instructions est assez précise pour vraiment changer le comportement de Claude ?
- Sois un assistant utile qui écrit du bon code
- Quand tu écris des endpoints d'API, renvoie du JSON avec des clés en camelCase, utilise des URL en kebab-case, et utilise les codes d'erreur de notre fichier error-codes.ts
- Utilise toujours les meilleures pratiques quand tu écris du code
- Écris du code comme un ingénieur senior
05 · Glisser pour trier
Pense à ce qui fait le plus la différence dans la qualité d'un skill. Un skill vague sans exemples vaut moins qu'un skill concret — range ces pratiques de la plus impactante à la moins impactante.
(Cette section est interactive — active JavaScript pour l'utiliser.)
06 · Lire
Certains skills rendent Claude moins bon. Voici ce qu'il faut éviter : Trop vague : « Écris du bon code propre. » Claude essaie déjà. Ton skill doit ajouter des règles concrètes que Claude ne connaîtrait pas tout seul.
Trop long : un skill de 500 lignes qui écrit des règles pour chaque scénario possible sature le contexte de Claude. Garde tes skills focalisés sur un seul workflow. Plusieurs skills focalisés battent un skill mastodonte.
Duplique les comportements intégrés : Claude sait déjà formater du code, écrire du markdown, utiliser git. Ne gaspille pas l'espace du skill sur des choses que Claude fait déjà bien par défaut.
Règles contradictoires : « Toujours ajouter des commentaires » + « Garder le code minimal » crée la confusion. Avant de tester, vérifie qu'il n'y a pas de conflits internes dans tes règles.
Points clés
- N'écris pas de skill vague — sois explicite ou n'écris rien
- N'écris pas de skill mastodonte — un skill, un workflow focalisé
- Ne duplique pas ce que Claude fait déjà bien par défaut
- Vérifie qu'il n'y a pas de règles contradictoires dans un skill
07 · Lire
Tu as maintenant un super-pouvoir que la plupart des utilisateurs de Claude Code n'ont pas : la capacité d'apprendre à Claude exactement comment tu travailles.
Chaque équipe a ses conventions. Chaque dev a ses préférences. Les skills transforment ces règles tacites en instructions permanentes, partageables et versionnées.
Commence petit. Choisis le truc que tu répètes le plus souvent à Claude, transforme-le en skill. Teste, affine, commit. Puis ajoute le suivant. Avec le temps, ta collection de skills devient un multiplicateur de force — chaque skill que tu écris rend Claude meilleur sur ton travail à toi.
La différence entre un assistant IA générique et un workflow IA personnalisé ? Les skills.
Points clés
- Commence par un skill pour l'instruction que tu répètes le plus souvent
- Itère : teste, affine, commit
- Partage les skills de projet via git, toute l'équipe en profite
- Accumule ta collection avec le temps — chaque skill rend Claude plus malin sur ton travail
- Les skills font la différence entre un assistant IA générique et un workflow IA personnalisé
08 · Quiz
Tu as écrit un skill qui dit « Écris du bon code propre ». Après l'avoir testé, la sortie de Claude n'a pas l'air différente. Pourquoi ?
- Le fichier SKILL.md a une erreur de syntaxe
- Les skills ne marchent qu'avec le modèle Opus
- L'instruction est trop vague — Claude essaie déjà d'écrire du bon code
- Il faut redémarrer Claude Code après avoir ajouté un skill
09 · Compléter
Un skill de 500 lignes qui couvre tous les scénarios possibles est un anti-pattern. Tu dois plutôt écrire plusieurs skills _____, chacun couvrant un seul workflow.
Autres leçons de ce chapitre
⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.
※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.