Claude Code Skills : Créer des Commandes Personnalisées pour Automatiser ton Vibe Coding

Tu utilises Claude Code au quotidien et tu te retrouves à répéter les mêmes instructions encore et encore ? « Fais un commit propre », « Lance les tests puis corrige les erreurs », « Déploie en production »... Et si tu pouvais transformer chacune de ces routines en une simple commande /deploy, /commit ou /test ? C'est exactement ce que permettent les Claude Code Skills : des commandes personnalisées que tu crées toi-même pour automatiser ton workflow de Vibe Coding.

Dans ce guide ultra pédagogique, on va voir ensemble ce qu'est un skill, comment le créer pas à pas, et surtout : 7 skills prêts à copier-coller qui vont transformer ta productivité. Que tu sois débutant ou vibe coder intermédiaire, tu vas repartir avec un arsenal de commandes personnalisées opérationnelles.

Qu'est-ce qu'un skill dans Claude Code ?

Un skill, c'est une recette que tu donnes à Claude Code. Au lieu de lui expliquer à chaque fois ce que tu veux, tu écris tes instructions une seule fois dans un fichier, et tu les invoques ensuite avec une simple commande slash (/nom-du-skill).

Concrètement, un skill est un fichier SKILL.md qui contient deux choses :

• Un en-tête YAML (appelé « frontmatter ») qui donne un nom et une description au skill
• Des instructions en Markdown que Claude suivra quand le skill sera activé

Pense à un skill comme un mode d'emploi automatisé. Au lieu de dire à Claude « lance les tests, vérifie les erreurs, corrige-les, puis relance les tests », tu crées un skill /test qui fait tout ça automatiquement. Un seul mot, une action complète.

Les skills suivent le standard ouvert Agent Skills (agentskills.io), ce qui signifie qu'ils sont compatibles avec d'autres outils IA au-delà de Claude Code.

L'évolution : des slash commands aux skills

Si tu as déjà utilisé les anciennes « slash commands » de Claude Code (les fichiers dans .claude/commands/), bonne nouvelle : les skills sont leur évolution. Tes anciens fichiers continuent de fonctionner. Un fichier à .claude/commands/review.md et un skill à .claude/skills/review/SKILL.md créent tous les deux la commande /review.

Mais les skills ajoutent des fonctionnalités puissantes :

• Un dossier complet pour stocker des fichiers de support (templates, scripts, exemples)
• Un frontmatter YAML pour contrôler qui peut invoquer le skill (toi ou Claude automatiquement)
• Le chargement automatique : Claude peut détecter quand un skill est pertinent et le charger tout seul

Skills vs Subagents : quelle différence ?

Avant d'aller plus loin, clarifions une confusion fréquente. Claude Code propose deux mécanismes d'extension : les skills et les subagents. Ils ne font pas la même chose.

Critère	Skill	Subagent
Définition	Un fichier d'instructions (SKILL.md) que Claude suit	Un assistant IA spécialisé avec son propre contexte
Contexte	S'exécute dans ta conversation en cours (par défaut)	S'exécute dans une fenêtre de contexte isolée
Complexité	Simple : un fichier Markdown suffit	Plus avancé : configuration YAML étendue
Cas d'usage	Tâches ponctuelles, workflows, conventions	Tâches complexes nécessitant isolation et spécialisation
Outils	Peut restreindre les outils via allowed-tools	Outils configurables + hooks + permissions
Modèle IA	Utilise le modèle de la conversation	Peut utiliser un modèle différent (Haiku, Sonnet...)
Fichier	.claude/skills/nom/SKILL.md	.claude/agents/nom.md
Invocation	/nom-du-skill	Délégation automatique par Claude

En résumé : utilise un skill quand tu veux créer un raccourci pour une tâche courante (commit, deploy, review...). Utilise un subagent quand tu as besoin d'un « employé spécialisé » qui travaille de son côté avec ses propres outils et permissions.

Pour 90 % des cas d'usage en Vibe Coding, les skills suffisent largement. C'est par là qu'on commence.

Anatomie d'un skill : comprendre la structure

Chaque skill est un dossier contenant au minimum un fichier SKILL.md. Voici la structure type :

mon-skill/
├── SKILL.md           # Instructions principales (obligatoire)
├── template.md        # Template que Claude peut utiliser (optionnel)
├── examples/
│   └── sample.md      # Exemple de résultat attendu (optionnel)
└── scripts/
    └── helper.sh      # Script exécutable (optionnel)

Le frontmatter YAML : la carte d'identité du skill

Tout fichier SKILL.md commence par un bloc YAML entre deux lignes ---. C'est ici que tu configures le comportement du skill :

---
name: mon-skill
description: Description de ce que fait le skill
disable-model-invocation: false
allowed-tools: Read, Write, Bash
---

Tes instructions en Markdown ici...

Voici les champs disponibles et leur rôle :

Champ	Obligatoire ?	Description
name	Non	Nom du skill (devient la commande /name). Si omis, utilise le nom du dossier. Lettres minuscules, chiffres et tirets uniquement.
description	Recommandé	Ce que fait le skill. Claude utilise cette description pour décider quand le charger automatiquement.
disable-model-invocation	Non	Si true, seul toi peux invoquer le skill (pas Claude automatiquement). Indispensable pour les actions à effet de bord (deploy, commit...).
user-invocable	Non	Si false, le skill n'apparaît pas dans le menu /. Utile pour du contexte de fond que Claude charge seul.
allowed-tools	Non	Liste des outils que Claude peut utiliser sans demander permission (ex : Read, Grep, Bash).
argument-hint	Non	Indice affiché pendant l'autocomplétion (ex : [fichier], [numéro-issue]).
context	Non	Mettre fork pour exécuter le skill dans un subagent isolé.
model	Non	Modèle IA à utiliser quand le skill est actif.

Les variables dynamiques

Tu peux rendre tes skills dynamiques avec des variables :

• $ARGUMENTS : tous les arguments passés après le nom du skill
• $ARGUMENTS[0], $ARGUMENTS[1]... ou $0, $1... : accès par position
• ${CLAUDE_SESSION_ID} : l'identifiant de la session en cours

Par exemple, quand tu tapes /fix-issue 42, la variable $ARGUMENTS est remplacée par 42 dans les instructions du skill.

Où placer ses skills : projet vs personnel

L'emplacement du skill détermine sa portée :

Emplacement	Chemin	Portée
Personnel	~/.claude/skills/mon-skill/SKILL.md	Disponible dans tous tes projets
Projet	.claude/skills/mon-skill/SKILL.md	Uniquement dans ce projet
Entreprise	Via les managed settings	Tous les utilisateurs de l'organisation

Règle simple :

• Ton skill est utile sur tous tes projets (commit, review...) ? Place-le dans ~/.claude/skills/
• Ton skill est spécifique à un projet (deploy vers un hébergeur particulier, conventions d'un framework...) ? Place-le dans .claude/skills/ à la racine du projet

En cas de conflit de nom, la priorité est : entreprise > personnel > projet.

7 skills prêts à copier-coller

Passons à la pratique. Voici 7 skills concrets, testés et documentés. Pour chacun, tu trouveras le code complet du SKILL.md, les instructions d'installation et un exemple d'utilisation. Tu connais sans doute déjà les commandes essentielles de Claude Code ; les skills vont te permettre de les combiner et de les enrichir.

1. Le skill /commit : des commits propres à chaque fois

Ce skill génère un commit Git avec un message structuré, en suivant la convention Conventional Commits.

Installation :

---
name: commit
description: Créer un commit Git propre avec un message conventionnel
disable-model-invocation: true
argument-hint: [message-optionnel]
allowed-tools: Bash, Read, Grep
---

Crée un commit Git propre en suivant ces étapes :

1. **Analyse les changements** : lance `git diff --staged` pour voir ce qui est stagé. Si rien n'est stagé, lance `git diff` pour voir les modifications non stagées et propose de les ajouter.

2. **Génère le message de commit** en respectant le format Conventional Commits :
   - `feat:` pour une nouvelle fonctionnalité
   - `fix:` pour une correction de bug
   - `refactor:` pour du refactoring
   - `docs:` pour de la documentation
   - `test:` pour des tests
   - `chore:` pour de la maintenance
   - `style:` pour du formatage

3. **Format du message** :
   ```
   type(scope): description courte en français

   - Détail 1 des changements
   - Détail 2 des changements
   ```

4. Si un message est passé en argument (`$ARGUMENTS`), utilise-le comme base pour le message de commit.

5. **Montre le message proposé** et demande confirmation avant de committer.

6. Exécute le commit avec `git commit`.

Ne fais JAMAIS de `git push` automatiquement.

Utilisation :

/commit
/commit ajout de la page d'inscription

2. Le skill /deploy : déployer en production en toute sécurité

Ce skill automatise le processus de déploiement avec des vérifications de sécurité intégrées.

Installation :

---
name: deploy
description: Déployer l'application en production avec vérifications
disable-model-invocation: true
argument-hint: [staging|production]
allowed-tools: Bash, Read
---

Déploie l'application vers l'environnement $ARGUMENTS (par défaut : production).

## Étapes obligatoires AVANT le déploiement

1. **Vérification Git** :
   - Vérifie qu'il n'y a pas de changements non commités (`git status`)
   - Vérifie que la branche est à jour avec le remote (`git fetch && git status`)

2. **Tests** :
   - Lance la suite de tests complète
   - Si un test échoue, ARRÊTE le déploiement et affiche les erreurs
   - Ne continue JAMAIS si les tests échouent

3. **Build** :
   - Lance le build de production
   - Vérifie qu'il n'y a pas d'erreurs ni de warnings critiques

## Déploiement

4. **Push** :
   - Si l'environnement est `staging` : déploie vers la branche staging
   - Si l'environnement est `production` : déploie vers la branche main

5. **Vérification post-déploiement** :
   - Confirme que le déploiement s'est terminé avec succès
   - Affiche l'URL de l'application déployée si disponible

## Important
- Affiche chaque étape clairement avant de l'exécuter
- Demande confirmation avant le push final
- En cas d'erreur à n'importe quelle étape, ARRÊTE tout et explique le problème

Utilisation :

/deploy production
/deploy staging

3. Le skill /review : une code review automatisée

Ce skill analyse le code récemment modifié et fournit un retour structuré, comme le ferait un développeur senior.

Installation :

---
name: review
description: Faire une code review approfondie du code modifié. Utiliser après avoir écrit ou modifié du code.
argument-hint: [fichier-ou-branche]
allowed-tools: Read, Grep, Glob, Bash
---

Effectue une code review approfondie et structurée.

## Ce qu'il faut analyser

Si un argument est fourni ($ARGUMENTS), review ce fichier ou cette branche spécifiquement.
Sinon, analyse les changements récents avec `git diff` et `git diff --staged`.

## Checklist de review

### 1. Lisibilité
- Les noms de variables et fonctions sont-ils clairs et descriptifs ?
- Le code est-il facile à comprendre sans commentaire ?
- Y a-t-il de la duplication qui pourrait être factorisée ?

### 2. Logique et bugs potentiels
- Y a-t-il des cas limites non gérés ?
- Les erreurs sont-elles correctement catchées et gérées ?
- Y a-t-il des problèmes de null/undefined potentiels ?

### 3. Sécurité
- Y a-t-il des données sensibles exposées (clés API, mots de passe) ?
- Les entrées utilisateur sont-elles validées ?
- Y a-t-il des risques d'injection (SQL, XSS) ?

### 4. Performance
- Y a-t-il des opérations coûteuses dans des boucles ?
- Les requêtes à la base de données sont-elles optimisées ?
- Y a-t-il des fuites mémoire potentielles ?

### 5. Bonnes pratiques
- Le code respecte-t-il les conventions du projet ?
- Les types sont-ils correctement définis (si TypeScript) ?
- Y a-t-il des tests pour les nouvelles fonctionnalités ?

## Format de sortie

Organise ton retour par priorité :
- **Critique** (à corriger absolument) : bugs, failles de sécurité
- **Important** (à corriger) : problèmes de logique, maintenabilité
- **Suggestion** (à considérer) : améliorations, optimisations

Pour chaque point, montre le code problématique ET propose une correction.

Utilisation :

/review
/review src/components/Auth.tsx
/review feature/payment

4. Le skill /test : générer et exécuter des tests

Ce skill génère des tests pour le code existant, les exécute, et corrige les échecs automatiquement.

Installation :

---
name: test
description: Générer des tests, les exécuter et corriger les échecs. Utiliser quand on veut tester du code ou corriger des tests cassés.
argument-hint: [fichier-à-tester]
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
---

Génère et exécute des tests pour le code spécifié.

## Étape 1 : Comprendre le contexte

1. Si un fichier est spécifié ($ARGUMENTS), analyse ce fichier
2. Sinon, identifie les fichiers récemment modifiés avec `git diff --name-only`
3. Détecte le framework de test utilisé dans le projet (Jest, Vitest, Pytest, etc.)
4. Repère les fichiers de test existants pour comprendre les conventions du projet

## Étape 2 : Générer les tests

Pour chaque fichier à tester :
1. Analyse les fonctions et leurs signatures
2. Identifie les cas nominaux (happy path)
3. Identifie les cas limites (edge cases) : valeurs nulles, tableaux vides, erreurs réseau...
4. Génère les tests en suivant le pattern AAA (Arrange, Act, Assert)
5. Place les tests dans le bon dossier selon les conventions du projet

## Étape 3 : Exécuter les tests

1. Lance les tests générés
2. Si des tests échouent :
   - Analyse l'erreur
   - Corrige le test OU le code source (selon ce qui est pertinent)
   - Relance les tests
   - Répète jusqu'à ce que tous les tests passent (max 3 itérations)

## Étape 4 : Rapport

Affiche un résumé :
- Nombre de tests créés
- Nombre de tests passés/échoués
- Couverture estimée des cas testés
- Cas limites non couverts (à tester manuellement)

Utilisation :

/test src/utils/payment.ts
/test

5. Le skill /docs : générer de la documentation

Ce skill génère ou met à jour la documentation technique d'un fichier ou d'un module.

Installation :

---
name: docs
description: Générer ou mettre à jour la documentation technique d'un fichier ou module
argument-hint: [fichier-ou-dossier]
allowed-tools: Read, Write, Edit, Grep, Glob
---

Génère une documentation technique claire et utile.

## Cible

Si un argument est fourni ($ARGUMENTS), documente ce fichier ou dossier.
Sinon, documente les fichiers récemment modifiés.

## Types de documentation à générer

### Pour une fonction/méthode :
- Description concise de ce qu'elle fait
- Paramètres avec types et descriptions
- Valeur de retour
- Exemple d'utilisation
- Exceptions/erreurs possibles

### Pour un composant (React, Vue...) :
- Description du composant
- Props avec types, défauts et descriptions
- Exemples d'utilisation avec différentes configurations
- Notes sur le comportement et les cas limites

### Pour un module/dossier :
- README.md avec vue d'ensemble
- Architecture et responsabilités
- Dépendances principales
- Guide de démarrage rapide

### Pour une API :
- Endpoints avec méthodes HTTP
- Paramètres de requête et body
- Réponses avec codes de statut
- Exemples de requêtes (curl)

## Règles
- Écris en français
- Utilise le format JSDoc/TSDoc pour le code TypeScript/JavaScript
- Utilise le format docstring pour Python
- Sois concis : documente le « pourquoi », pas le « quoi » (le code parle de lui-même)
- Ajoute des exemples concrets et exécutables

Utilisation :

/docs src/api/
/docs src/components/PaymentForm.tsx

6. Le skill /refactor : refactoriser intelligemment

Ce skill analyse le code et propose des refactorisations ciblées, en expliquant chaque changement.

Installation :

---
name: refactor
description: Analyser et refactoriser du code pour améliorer la lisibilité, la performance et la maintenabilité
argument-hint: [fichier-ou-dossier]
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
---

Analyse et refactorise le code spécifié ($ARGUMENTS).

## Principes de refactoring

Applique ces principes par ordre de priorité :

1. **Lisibilité d'abord** : le code doit être compréhensible sans commentaire
2. **DRY** (Don't Repeat Yourself) : élimine la duplication
3. **Responsabilité unique** : chaque fonction fait UNE chose
4. **Nommage explicite** : les noms doivent dire ce que fait le code
5. **Gestion d'erreurs** : ne jamais ignorer silencieusement une erreur

## Processus

### 1. Analyse
- Lis le code et identifie les « code smells »
- Classe les problèmes par impact (critique, important, mineur)
- Vérifie qu'il y a des tests existants (pour ne rien casser)

### 2. Planification
- Propose un plan de refactoring avec les changements prévus
- Explique POURQUOI chaque changement est bénéfique
- Estime le risque de régression pour chaque changement

### 3. Exécution
- Applique les changements un par un
- Après chaque changement, lance les tests si disponibles
- Si un test casse, annule le changement et explique pourquoi

### 4. Vérification
- Lance la suite de tests complète
- Vérifie que le build passe
- Résume les changements effectués avec avant/après

## Important
- Ne change JAMAIS le comportement visible du code (sauf correction de bug évident)
- Privilégie les petits changements incrémentaux aux refactorings massifs
- Si le code n'a pas de tests, propose d'en ajouter AVANT de refactoriser

Utilisation :

/refactor src/utils/helpers.ts
/refactor src/components/

7. Le skill /seo : optimiser le contenu pour le référencement

Ce skill analyse une page ou un article de blog et fournit des recommandations SEO actionnables.

Installation :

---
name: seo
description: Analyser et optimiser le contenu d'une page web ou article de blog pour le SEO
disable-model-invocation: true
argument-hint: [fichier-html-ou-url]
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
---

Analyse et optimise le contenu pour le référencement naturel (SEO).

## Cible

Analyse le fichier ou la page spécifié ($ARGUMENTS).

## Checklist SEO à vérifier

### 1. Balises essentielles
- Le title est-il entre 50-60 caractères ? Contient-il le mot-clé principal ?
- La meta description est-elle entre 150-160 caractères ? Est-elle incitative ?
- Y a-t-il un seul H1 ? Contient-il le mot-clé principal ?
- La hiérarchie des titres est-elle logique (H1 > H2 > H3) ?

### 2. Contenu
- Le mot-clé principal apparaît-il dans les 100 premiers mots ?
- La densité du mot-clé est-elle entre 1-2 % ?
- Y a-t-il des variations sémantiques et des mots-clés secondaires ?
- Le contenu dépasse-t-il 1500 mots pour un article informatif ?

### 3. Maillage interne
- Y a-t-il des liens internes pertinents ?
- Les ancres de lien sont-elles descriptives (pas de « cliquez ici ») ?
- Le maillage est-il naturel et intégré dans le texte ?

### 4. Images
- Toutes les images ont-elles un attribut alt descriptif ?
- Les alt contiennent-ils des mots-clés pertinents ?

### 5. Technique
- Les URLs sont-elles propres et contiennent-elles des mots-clés ?
- Y a-t-il des liens cassés ?
- Le temps de chargement est-il optimisé (images lourdes, scripts bloquants) ?

## Format de sortie

1. **Score SEO** : note sur 100
2. **Points forts** : ce qui est bien fait
3. **Corrections urgentes** : à faire immédiatement
4. **Améliorations suggérées** : pour aller plus loin
5. **Meta tags optimisés** : proposer des versions améliorées

Utilisation :

/seo src/pages/blog/mon-article.html
/seo public/index.html

Comment installer un skill pas à pas

Récapitulons le processus complet d'installation avec un exemple concret. Imaginons que tu veux installer le skill /commit en tant que skill personnel (disponible dans tous tes projets).

Étape 1 : Demander à Claude de créer le skill

C'est la méthode la plus simple : demande directement à Claude de le faire pour toi. Copie le contenu du skill /commit vu plus haut, puis envoie ce prompt à Claude Code :

Claude va créer automatiquement le dossier et le fichier. Tu n'as rien d'autre à faire. C'est l'un des avantages du Vibe Coding : tu délègues les tâches répétitives à l'IA, y compris la configuration de tes outils.

Étape 3 : Vérifier que le skill est détecté

Dans Claude Code, tape simplement :

/commit

Si le skill est bien détecté, Claude Code l'affichera dans la liste d'autocomplétion dès que tu tapes /co. Tu peux aussi demander à Claude :

Quels skills sont disponibles ?

Et il te listera tous les skills actifs avec leur description.

Étape 4 : Tester le skill

Fais une petite modification dans ton projet, puis invoque le skill :

/commit

Claude va analyser tes changements, générer un message de commit propre et te demander confirmation. Si tout fonctionne, ton skill est prêt.

Astuce : les skills sont détectés en temps réel. Tu peux modifier un SKILL.md pendant une session Claude Code et les changements seront pris en compte immédiatement, sans redémarrage.

Partager ses skills avec son équipe

L'un des grands avantages des skills placés dans le dossier .claude/skills/ d'un projet : ils sont versionnés avec le code. Cela signifie que quand tu fais un git push, tes skills sont partagés avec toute l'équipe.

Workflow recommandé

1. Crée tes skills projet dans .claude/skills/ à la racine du repo
2. Commite-les avec ton code : demande simplement à Claude :

   Prompt à envoyer à Claude :

   Fais un commit avec les skills qu'on vient de créer

   Il s'occupera d'ajouter les fichiers et de générer un message de commit propre automatiquement.

3. Documente tes skills dans le fichier CLAUDE.md du projet pour que l'équipe sache qu'ils existent
4. Itère avec l'équipe : chacun peut proposer des améliorations via des pull requests

Cette approche garantit que tous les membres de l'équipe utilisent les mêmes conventions de commit, les mêmes processus de déploiement et les mêmes standards de code review.

Bonnes pratiques pour des skills efficaces

Après avoir créé et utilisé des dizaines de skills, voici les règles d'or qui font la différence :

1. Des descriptions riches et précises

La description de ton skill est cruciale. C'est elle que Claude utilise pour décider quand charger automatiquement le skill. Sois explicite sur les situations d'utilisation :

# Mauvais :
description: Review le code

# Bon :
description: Faire une code review approfondie du code modifié. Utiliser après avoir écrit ou modifié du code, avant un commit ou une pull request.

2. Utilise disable-model-invocation pour les actions à risque

Toute action qui a un effet de bord (modifier la base de données, déployer, envoyer un email, faire un commit) doit avoir disable-model-invocation: true. Tu ne veux pas que Claude décide tout seul de déployer parce que le code « a l'air prêt ».

3. Garde tes skills courts et focalisés

Un skill doit faire une seule chose bien. Si ton SKILL.md dépasse 500 lignes, c'est qu'il fait trop de choses. Découpe-le en plusieurs skills ou déplace les détails dans des fichiers de support.

4. Inclus des exemples de sortie attendue

Claude suit mieux les instructions quand il a un exemple concret du résultat attendu. Ajoute une section « Exemple de sortie » dans ton SKILL.md.

5. Teste et itère

Comme du code, un skill se teste et s'améliore. Commence simple, utilise-le quelques fois, note ce qui manque, puis affine les instructions. Les meilleurs skills sont ceux qui ont été rodés par l'usage.

Les limites des skills et quand passer aux subagents

Les skills sont puissants, mais ils ont des limites. Voici les situations où tu devrais envisager de passer aux subagents :

• Tâches très longues : un skill s'exécute dans ta conversation. Si la tâche consomme beaucoup de contexte (analyse de centaines de fichiers, logs volumineux), un subagent avec son propre contexte est plus adapté.
• Isolation stricte : si tu veux qu'une tâche ne puisse absolument pas modifier certains fichiers, les permissions granulaires des subagents sont plus robustes que le allowed-tools d'un skill.
• Modèle différent : tu peux vouloir utiliser Haiku (plus rapide et moins cher) pour l'exploration, et garder Opus pour l'écriture de code. Seuls les subagents permettent de choisir le modèle.
• Parallélisme : les subagents peuvent s'exécuter en arrière-plan pendant que tu continues à travailler. Les skills bloquent ta conversation.

Astuce intermédiaire : tu peux combiner les deux. Ajoute context: fork dans le frontmatter d'un skill pour qu'il s'exécute dans un subagent tout en restant invocable via une simple commande slash.

---
name: deep-research
description: Recherche approfondie dans le codebase
context: fork
agent: Explore
---

Recherche $ARGUMENTS de manière approfondie...

Avec cette configuration, /deep-research système d'authentification lance la recherche dans un subagent isolé et te renvoie un résumé une fois terminée.

Injecter du contexte dynamique dans un skill

Les skills les plus avancés utilisent la syntaxe !`commande` pour exécuter des commandes shell avant que Claude ne voie les instructions. Le résultat de la commande remplace le placeholder.

Voici un exemple de skill qui résume une pull request en récupérant les données live depuis GitHub :

---
name: pr-summary
description: Résumer les changements d'une pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---

## Contexte de la PR
- Diff de la PR : !`gh pr diff`
- Commentaires : !`gh pr view --comments`
- Fichiers modifiés : !`gh pr diff --name-only`

## Ta tâche
Résume cette pull request en français :
1. Objectif principal de la PR
2. Changements majeurs
3. Points d'attention pour le reviewer

Quand tu invoques /pr-summary, les commandes gh s'exécutent d'abord, et Claude reçoit les résultats réels, pas les commandes.

FAQ : questions fréquentes sur les Claude Code Skills

Mon skill n'apparaît pas dans la liste, que faire ?

Vérifie que le fichier s'appelle bien SKILL.md (avec la bonne casse) et qu'il est dans un sous-dossier de .claude/skills/ ou ~/.claude/skills/. Vérifie aussi que le frontmatter YAML est correctement formaté (pas de tabulations, uniquement des espaces).

Peut-on utiliser des skills avec Cursor ou d'autres éditeurs ?

Les skills suivent le standard ouvert Agent Skills. Certains éditeurs commencent à les supporter. Pour le moment, l'intégration la plus complète reste avec Claude Code. Consulte notre comparatif Claude Code vs Cursor pour plus de détails.

Combien de skills peut-on avoir ?

Il n'y a pas de limite stricte, mais les descriptions des skills occupent du contexte. Le budget est de 2 % de la fenêtre de contexte (environ 16 000 caractères par défaut). Si tu as beaucoup de skills, utilise /context pour vérifier qu'aucun n'est exclu. Tu peux aussi augmenter la limite avec la variable d'environnement SLASH_COMMAND_TOOL_CHAR_BUDGET.

Comment débugger un skill qui ne fonctionne pas comme prévu ?

Commence par invoquer le skill directement avec /nom-du-skill et observe ce que Claude fait. Si les instructions ne sont pas suivies, reformule-les de manière plus explicite. Ajoute des exemples de résultats attendus. Et garde en tête la règle d'or : les instructions courtes et précises fonctionnent mieux que les longs paragraphes.

Quelle est la différence entre un skill et un fichier CLAUDE.md ?

Le fichier CLAUDE.md définit des règles permanentes que Claude suit tout le temps (conventions de code, structure du projet, préférences). Un skill est une action à la demande que tu invoques quand tu en as besoin. Les deux sont complémentaires : CLAUDE.md pour le contexte permanent, skills pour les tâches ponctuelles.

Les anciens fichiers dans .claude/commands/ fonctionnent-ils encore ?

Oui, parfaitement. Les fichiers dans .claude/commands/ continuent de fonctionner et supportent le même frontmatter que les skills. La migration vers .claude/skills/ est optionnelle mais recommandée pour bénéficier des fonctionnalités avancées (fichiers de support, chargement automatique).

Conclusion : les skills, le vrai multiplicateur de productivité

Les Claude Code Skills transforment des workflows répétitifs en commandes simples et réutilisables. Au lieu de réécrire les mêmes instructions à chaque session, tu les écris une fois et tu les invoques en un mot.

Les 7 skills présentés dans cet article couvrent les tâches les plus courantes du développement : commit, déploiement, code review, tests, documentation, refactoring et SEO. Mais le vrai pouvoir des skills, c'est que tu peux créer les tiens, adaptés exactement à ton workflow et à ton projet.

Commence par un ou deux skills simples, teste-les au quotidien, puis enrichis ta collection au fil du temps. C'est cette approche progressive qui distingue les vibe coders efficaces de ceux qui passent leur temps à répéter les mêmes instructions. Et si tu veux aller encore plus loin, les participants de notre formation Vibe Coding apprennent à construire des workflows complets avec skills, subagents et automatisations dès les premières soirées.

Pour approfondir

• Claude Code : le guide complet
• CLAUDE.md : le fichier qui rend Claude Code 10x plus efficace
• Commandes essentielles Claude Code : la cheatsheet du Vibe Coder
• MCP Servers et Claude Code : connecter l'IA à vos outils
• Claude Code Team Agents : orchestrer une équipe d'IA

Sources

• Documentation officielle Claude Code : Extend Claude with skills
• Documentation officielle Claude Code : Create custom subagents
• Agent Skills : le standard ouvert
• Repository officiel Anthropic : Skills