Maîtriser Claude Code Partie 5 : Skills

Tu as construit des commandes personnalisées. Elles sont super pour les workflows que tu déclenches explicitement — /review, /commit, /deploy. Mais qu'en est-il des connaissances que Claude devrait appliquer automatiquement sans que tu aies besoin de te rappeler de les invoquer ?

C'est ce que font les Skills. Ce sont des modules de connaissances spécialisées que Claude découvre et charge quand ils sont pertinents, pas quand tu les appelles explicitement. Pense aux Commandes comme des outils que tu prends en main ; les Skills sont de l'expertise que Claude développe.

Commandes vs Skills : quelle est la différence ?

La distinction est importante car elle change la façon dont tu structures ton automatisation.

Commandes Slash (de la Partie 4) :

• Tu les invoques explicitement : /review, /commit
• Chargées immédiatement quand tu les appelles
• Idéales pour les workflows que tu veux déclencher intentionnellement
• Simples fichiers markdown avec frontmatter optionnel

Skills :

• Claude les invoque automatiquement quand ta requête correspond
• Chargés paresseusement — seule la description est lue au démarrage, le contenu complet se charge à l'utilisation
• Idéaux pour les standards, patterns et connaissances spécialisées que Claude devrait toujours appliquer
• Peuvent regrouper des fichiers de support, des exemples et des scripts exécutables

Voici le modèle mental : les Commandes sont des verbes (des choses que tu fais), les Skills sont de l'expertise (des choses que Claude sait).

Quand tu dis « revois cette PR », tu pourrais vouloir que Claude :

1. Lance ta commande /review (action explicite)
2. Applique les standards de revue de code de ton équipe depuis un Skill (connaissance automatique)

Les deux ont leur place.

Comment fonctionnent réellement les Skills

La magie des Skills, c'est la divulgation progressive. Voici le flux :

Au démarrage : Claude lit uniquement le name et la description du fichier SKILL.md de chaque Skill. Surcoût minimal.

Quand tu fais une requête : Claude compare ta requête aux descriptions des Skills. S'il y a correspondance, il demande : « J'ai trouvé un Skill qui pourrait aider. Tu veux que je l'utilise ? »

À la confirmation : Le contenu complet du SKILL.md se charge dans le contexte. Les fichiers de support ne se chargent que si Claude en a besoin pendant l'exécution.

Ça veut dire que tu peux avoir des dizaines de Skills sans pénalité de performance. Ils sont chargés à la demande, pas d'emblée.

Astuce : Écris les descriptions de Skills avec des mots-clés que les utilisateurs diraient naturellement. « Aide avec les documents » ne se déclenchera pas. « Revue des pull requests en utilisant les directives de sécurité OWASP et les standards de formatage de l'équipe » oui.

Structure d'un fichier Skill

Les Skills vivent dans des répertoires avec un fichier SKILL.md obligatoire :

.claude/skills/
└── code-review/
    ├── SKILL.md           # Obligatoire - instructions et frontmatter
    ├── examples/          # Optionnel - exemples de sortie
    │   ├── good-review.md
    │   └── bad-review.md
    ├── templates/         # Optionnel - templates de sortie
    │   └── review-template.md
    └── scripts/           # Optionnel - helpers exécutables
        └── lint-check.sh

Contraintes clés :

• SKILL.md est obligatoire (nom de fichier sensible à la casse)
• Garde SKILL.md sous 500 lignes pour des performances optimales
• Les fichiers de support sont découverts via les liens dans SKILL.md
• Les scripts s'exécutent sans charger leur code source dans le contexte — seule la sortie consomme des tokens

Où vivent les Skills

Les Skills suivent une hiérarchie — les niveaux supérieurs écrasent les inférieurs :

Enterprise — Paramètres gérés pour tous les utilisateurs de l'organisation (priorité la plus haute)

Personnel — ~/.claude/skills/ — Tes Skills, disponibles dans tous les projets

Projet — .claude/skills/ — Skills d'équipe, commités dans git

Plugin — skills/ dans le répertoire du plugin — Disponibles pour quiconque a le plugin installé

La répartition est similaire aux Commandes : les Skills personnels te suivent partout, les Skills projet sont partagés avec ton équipe.

Le template SKILL.md

Voici l'anatomie d'un Skill bien structuré :

---
Name: code-review
Description: "Review pull requests using OWASP security guidelines, performance best practices, and team formatting standards"
Allowed-tools: Read, Grep, Glob
Model: claude-sonnet-4-5-20250929
---
# Code Review Standards

## Purpose
Apply consistent code review standards across all PRs.

## When to Use
- Reviewing pull requests
- Checking code for security issues
- Validating against team conventions

## Instructions

### Security Checks
1. SQL injection vulnerabilities
2. XSS attack vectors
3. Authentication bypasses
4. Sensitive data exposure

### Performance Checks
1. N+1 query patterns
2. Unnecessary re-renders
3. Memory leaks
4. Blocking operations

### Style Checks
1. Naming conventions per team standards
2. Function length (max 50 lines)
3. Cyclomatic complexity

## Output Format
Organize findings by severity:
- 🚨 Critical (blocks merge)
- ⚠️ Warnings (should fix)
- 💡 Suggestions (nice to have)

## Examples
See ./examples/good-review.md for proper format.

Options du frontmatter

Les Skills supportent une configuration puissante via le frontmatter YAML :

name (obligatoire) — Identifiant du Skill. Minuscules, chiffres, tirets uniquement. Maximum 64 caractères.

description (obligatoire) — Ce qu'il fait et quand l'utiliser. Maximum 1024 caractères. C'est comme ça que Claude associe les requêtes aux Skills — sois descriptif.

allowed-tools — Outils que Claude peut utiliser sans demande de permission quand ce Skill est actif. Séparés par des virgules ou en liste YAML.

model — Surcharger le modèle quand ce Skill s'exécute. Utile pour les tâches de raisonnement complexe.

context — Défini à fork pour s'exécuter dans un contexte de sous-agent isolé avec un historique de conversation séparé.

agent — Type d'agent quand context: fork est défini. Options : Explore, Plan, general-purpose, ou personnalisé.

hooks — Définir des hooks avec portée limitée au Skill : PreToolUse, PostToolUse, Stop.

user-invocable — Défini à false pour masquer du menu / tout en permettant la découverte automatique.

disable-model-invocation — Défini à true pour empêcher Claude de l'invoquer programmatiquement (mais toujours visible dans le menu).

Créer ton premier Skill

Construisons un Skill pratique : un guide TDD (Test-Driven Development) que Claude applique automatiquement quand tu écris des tests.

Étape 1 : Créer le répertoire

Mkdir -p .claude/skills/tdd

Étape 2 : Créer SKILL.md

Cat > .claude/skills/tdd/SKILL.md << 'EOF'
---
Name: tdd
Description: "Apply test-driven development workflow when writing tests, implementing features with tests, or following red-green-refactor cycle"
Allowed-tools: Read, Write, Edit, Bash(npm test:*), Bash(bun test:*)
---
# Test-Driven Development

## Purpose
Guide development through proper TDD: Red → Green → Refactor.

## When to Use
- When user asks to "add a feature with tests"
- When user mentions "TDD" or "test-driven"
- When creating new functionality that requires tests
- When user asks to implement something "the right way"

## The TDD Cycle

### Phase 1: Red (Write Failing Test)
1. Understand the requirement fully
2. Write the simplest test that fails
3. Verify the test fails for the RIGHT reason
4. DO NOT write implementation yet

### Phase 2: Green (Make It Pass)
1. Write minimal code to pass the test
2. No extra features, no edge cases yet
3. Ugly code is acceptable—just make it green

### Phase 3: Refactor (Clean Up)
1. Improve code quality
2. Remove duplication
3. Better naming
4. Tests MUST stay green

### Repeat
For each new behavior, start the cycle again.

## Anti-Patterns to Avoid
- Writing implementation before tests
- Writing multiple tests at once
- Refactoring while tests are red
- Skipping the refactor phase

## Example Session
See ./examples/tdd-session.md for a complete walkthrough.
EOF

Étape 3 : Ajouter un exemple

Mkdir -p .claude/skills/tdd/examples
Cat > .claude/skills/tdd/examples/tdd-session.md << 'EOF'
# TDD Session: Adding Email Validation

## Requirement
Validate email format in user registration.

## Cycle 1: Basic Validation

### Red
```typescript
// user.test.ts
It('should reject invalid email format', () => {
  expect(() => new User('notanemail')).toThrow('Invalid email');
});
```
Run: `npm test` → FAILS (User doesn't validate emails yet)

### Green
```typescript
// user.ts
Constructor(email: string) {
  if (!email.includes('@')) {
    throw new Error('Invalid email');
  }
  this.email = email;
}
```
Run: `npm test` → PASSES

### Refactor
Extract validation:
```typescript
Private validateEmail(email: string): void {
  if (!email.includes('@')) {
    throw new Error('Invalid email');
  }
}
```

## Cycle 2: Domain Validation

### Red
```typescript
It('should reject email without domain', () => {
  expect(() => new User('test@')).toThrow('Invalid email');
});
```
...continue cycle...
EOF

Étape 4 : Utilise-le

Maintenant quand tu dis « ajoutons la validation d'email avec des tests propres », Claude va :

1. Reconnaître que ça correspond à la description du Skill TDD
2. Demander si tu veux utiliser le Skill TDD
3. Suivre automatiquement le cycle Rouge → Vert → Refactor

La collection Superpowers

La bibliothèque de Skills la plus populaire est obra/superpowers avec plus de 16 500 étoiles. Elle est éprouvée et couvre les workflows de développement courants.

Installation

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Ou clone directement :

Git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers

Note : Les Skills utilisent un espace de noms par répertoire similaire à la façon dont les commandes sont organisées dans la Partie 4. Les mêmes patterns d'organisation s'appliquent — les sous-répertoires créent des espaces de noms pour une meilleure organisation.

Skills clés inclus

/superpowers:brainstorm — Idéation structurée avant de commencer des fonctionnalités complexes. À utiliser avant de sauter dans le code.

/superpowers:write-plan — Créer des plans d'implémentation pour les migrations ou les refactors multi-fichiers.

/superpowers:execute-plan — Exécuter des plans par lots contrôlés avec des points de contrôle.

/superpowers:tdd — Développement piloté par les tests avec le cycle complet Rouge/Vert/Refactor.

/superpowers:debug — Débogage systématique avec traçage de la cause racine.

Pourquoi ça marche

Superpowers, ce n'est pas juste des prompts — ce sont des patterns prouvés en production. Le Skill TDD, par exemple, inclut :

• Détection d'anti-patterns (écrire les tests après le code)
• Patterns de tests asynchrones
• Structure d'assertions correcte
• Déclencheurs de refactoring

Ces patterns viennent d'une utilisation en conditions réelles par des milliers de développeurs.

Idées de Skills pratiques

Voici des Skills qui valent le coup d'être construits pour ton équipe :

Documentation API — Appliquer automatiquement tes standards de documentation API quand Claude écrit ou met à jour des endpoints.

Gestion des erreurs — Imposer des patterns cohérents de gestion d'erreurs (ta classe ApiError, le format de logging, les messages destinés aux utilisateurs).

Patterns base de données — Appliquer les conventions de ton équipe pour les requêtes, transactions, migrations.

Revue de sécurité — Vérifier automatiquement les problèmes OWASP Top 10 lors de la revue de code.

Patterns de composants — Imposer la structure et le nommage de tes composants React/Vue/Svelte.

Messages de commit — Appliquer automatiquement le format conventional commit.

Skills + Scripts : le combo puissant

Voici quelque chose de sous-utilisé : les Skills peuvent intégrer des scripts exécutables qui s'exécutent sans charger leur code source dans le contexte.

.claude/skills/security-audit/
├── SKILL.md
└── scripts/
    ├── check-dependencies.sh
    ├── scan-secrets.py
    └── validate-permissions.js

Dans ton SKILL.md :

## Scripts Disponibles

Lance-les pour des vérifications automatisées :
- `./scripts/check-dependencies.sh` - Scanner les packages vulnérables
- `./scripts/scan-secrets.py` - Trouver les secrets en dur
- `./scripts/validate-permissions.js` - Vérifier les permissions des fichiers

Claude peut exécuter ces scripts, mais seule la sortie consomme du contexte — pas le code source du script. C'est parfait pour une logique de validation complexe qui est plus fiable sous forme de code testé que de commandes générées par un LLM.

Skills vs Commandes : quand utiliser quoi

Utilise les Commandes quand :

• Tu veux un contrôle explicite sur le moment d'exécution
• Le workflow est initié par l'utilisateur (déployer, commiter, générer)
• Tu as besoin de passer des arguments ($ARGUMENTS, $1, $2)
• L'action est discrète et autonome

Utilise les Skills quand :

• Les connaissances doivent s'appliquer automatiquement selon le contexte
• Tu veux des standards cohérents sans avoir à te rappeler de les invoquer
• L'expertise couvre plusieurs types de requêtes
• Tu encodes les connaissances de l'équipe que Claude devrait toujours avoir

Utilise les deux ensemble :

• La commande /review déclenche la revue
• Le Skill code-review fournit les standards à appliquer

Disponibilité des Skills

Les Skills nécessitent un abonnement payant :

• Pro, Max, Team, Enterprise — Support complet des Skills
• Tier gratuit — Pas de Skills

Si tu es sur le tier gratuit et que tu veux encoder les connaissances de l'équipe, utilise plutôt le répertoire .claude/rules/ de la Partie 3. Les rules sont toujours chargées ; les Skills sont chargés paresseusement.

Découvrir des Skills

Topics GitHub :

Https://github.com/topics/claude-skills

Collections communautaires :

• obra/superpowers — Patterns de développement de base
• obra/superpowers-skills — Skills contribués par la communauté
• SkillsMP — Marketplace pour les Skills Claude/ChatGPT

La spécification Agent Skills — Publiée en décembre 2025 comme standard ouvert. OpenAI a adopté le même format pour Codex CLI et ChatGPT, donc les Skills que tu construis pour Claude fonctionnent avec d'autres outils.

La suite

Les Skills donnent à Claude des connaissances spécialisées qui s'activent automatiquement. Mais que se passe-t-il si tu as besoin que Claude fasse plusieurs choses simultanément ? Si une tâche pourrait bénéficier d'une exécution parallèle ?

C'est là que les Subagents entrent en jeu. Dans la Partie 6 : Subagents, nous explorerons comment faire apparaître des agents spécialisés qui travaillent en parallèle — lancer des tests tout en générant de la documentation tout en vérifiant les problèmes de sécurité, le tout en même temps.