Pour la quinzième fois de la semaine, vous réexpliquez à Claude comment structurer vos reviews de PR. Comme un professeur en septembre qui redit les règles à chaque heure de cours. À un moment, ce n'est plus un problème d'IA — c'est un problème d'architecture.
Chaque fois que vous expliquez vos standards de code à Claude, vous payez un impôt. Chaque review de PR où vous redécrivez la structure du feedback attendu. Chaque commit message où vous rappelez votre format préféré. Chaque tâche de documentation où vous réexpliquez la voix de votre entreprise.
Cet impôt s'accumule. Sur une équipe de cinq développeurs qui lancent vingt sessions Claude par jour, vous dépensez un vrai budget cognitif sur les mêmes instructions, encore et encore. Ce n'est pas un problème Claude — c'est un problème d'architecture.
Les Skills règlent cela.
Un skill est un fichier markdown. Vous écrivez comment vous souhaitez que Claude traite une tâche — une seule fois — et Claude l'applique automatiquement dès que la situation correspond. Aucune commande à taper. Aucun prompt à copier-coller. Plus besoin de rappeler vos préférences à chaque session.
C'est une directive persistante qui ne s'active que lorsque c'est pertinent. Vous créez un fichier SKILL.md. Il contient une description — le champ que Claude lit pour décider s'il doit utiliser le skill — et les instructions réelles pour la tâche.
# SKILL.md — Standards de Review PR
description: Utiliser ce skill lors des reviews de pull requests.
S'applique à toute revue de code, feedback PR, ou
évaluation de merge request.
## Checklist de Review
- Vérifier les breaking changes sur les API publiques
- Valider la couverture de tests sur les nouveaux chemins
- Signaler tout credential ou secret en dur
- S'assurer que le error handling suit les patterns de l'équipe
- Valider les conventions de nommage (camelCase pour JS)
## Format du Feedback
Structurer chaque review comme suit :
1. Résumé — verdict en une ligne
2. Critique — à corriger avant merge
3. Suggestions — nice to have
4. Kudos — ce qui a été bien faitLorsque vous demandez à Claude de reviewer une PR, il compare votre requête avec les descriptions de tous les skills disponibles. Il trouve le bon. Il charge les instructions complètes. Il applique vos standards. Vous n'expliquez plus jamais le format.
Ce n'est pas de la magie — c'est de l'architecture bien pensée.
Les skills vivent dans des emplacements spécifiques selon qui en a besoin. C'est là que le parallèle avec l'architecture agent devient concret.
Les skills personnels se trouvent dans ~/.claude/skills/ et vous suivent sur l'ensemble de vos projets. Vos préférences : style de commit messages, format de documentation, manière d'expliquer le code. Ce sont les comportements appris de votre agent personnel. Persistants. Portables. Les vôtres.
Les skills projet se trouvent dans .claude/skills/ à la racine du dépôt et sont livrés avec lui. Toute personne qui clone le repo les récupère automatiquement. Standards de code d'équipe, charte graphique, patterns d'API. La mémoire institutionnelle qui survit aux changements de personnel.
Claude Code dispose de plusieurs couches de personnalisation. Les différences sont importantes.
Les fichiers claude.md se chargent dans chaque conversation. Si vous souhaitez que Claude utilise systématiquement le mode strict TypeScript, c'est une directive claude.md. Elle est toujours présente, occupe en permanence de l'espace dans la fenêtre de contexte, quelle que soit la tâche en cours.
Les Skills se chargent à la demande. Seuls le nom et la description sont indexés. Votre checklist de review PR n'occupe pas le contexte lorsque vous déboguez un memory leak — elle se charge uniquement quand vous demandez effectivement une review. C'est de la gestion intelligente des ressources. Les fenêtres de contexte ne sont pas infinies, et chaque token compte.
Les Slash commands exigent de les taper et de s'en souvenir. Les skills, non — Claude les active lui-même dès qu'il reconnaît la situation. C'est la différence entre un outil qu'on va chercher et une connaissance qui est simplement là.
C'est exactement le même principe qui sous-tend la conception des agents Glorics. Nos agents Monitor ne scannent pas chaque source de données pour chaque client à chaque exécution. Ils comparent le brief de mission à leurs capacités, ne chargent que les outils pertinents, et exécutent. Même pattern. Échelle différente.
Les skills sont les plus efficaces pour de la connaissance spécialisée qui s'applique à des tâches précises. La règle est simple : si vous vous retrouvez à expliquer la même chose à Claude plus de deux fois, c'est un skill qui attend d'être écrit.
Les meilleurs candidats : les standards de code review de votre équipe, les formats de commit messages convenus, la charte graphique de vos projets web, les templates de documentation pour des contextes spécifiques, les patterns de test propres à votre stack.
Le champ description est déterminant — c'est le moteur de correspondance. Rédigez-le comme une fiche de poste : assez précis pour s'activer sur les bonnes tâches, assez ouvert pour ne pas manquer les cas limites.
Les skills illustrent à petite échelle une question que nous posons constamment chez Glorics : comment construire des agents qui accumulent de l'intelligence institutionnelle dans la durée ?
Un fichier skill est statique — vous l'écrivez, Claude le lit. Mais le pattern qu'il établit est la fondation de systèmes d'apprentissage dynamiques où les agents construisent et affinent leur propre mémoire opérationnelle. Un orchestrateur lit la mission. Des agents spécialisés ne chargent que ce dont ils ont besoin. La connaissance accumulée persiste entre les sessions, et gagne en précision à chaque itération.
Ce n'est pas de la science-fiction. C'est ce que nous livrons le lundi matin.