Ce que la création de plus de 30 skills Claude Code m'a appris

Ce que la création de plus de 30 skills Claude Code m'a appris

Il y a trois mois, j'ai supprimé en masse quatorze skills de ma configuration Claude Code. Pas archivées. Supprimées. C'étaient des skills dans lesquelles j'avais investi du temps réel à construire, tester et itérer. Des skills dont j'étais fier.

Elles dégradaient mon travail.

Pas de manière dramatique -- ça aurait été facile à repérer. De manière subtile. Une skill de génération de contenu qui écrasait les capacités d'écriture natives améliorées de Claude. Une skill de messages de commit qui produisait des résultats rigides et formulaïques alors que le modèle avait appris à en écrire de meilleurs tout seul. Une skill de revue de code si prescriptive que Claude cochait des cases au lieu de réfléchir vraiment à la qualité du code.

La suppression massive m'a appris quelque chose que je n'avais lu dans aucune documentation : construire des skills est la partie facile. Construire des skills qui restent utiles, qui composent bien entre elles, qui améliorent réellement votre flux de travail six mois plus tard -- c'est une discipline entièrement différente. Et c'est une discipline que j'ai dû apprendre à la dure.

J'ai maintenant construit et maintenu plus de trente skills actives à travers quatre sites web de marques différentes, un pipeline de création de contenu, un workflow d'audit de sécurité et mon environnement de développement quotidien. Certaines de ces skills tournent depuis presque un an. D'autres ont duré une semaine avant que je réalise qu'elles résolvaient le mauvais problème.

Ce qui suit n'est pas un tutoriel sur comment créer votre première skill. Si c'est ce qu'il vous faut, la documentation officielle d'Anthropic et leur cours Skilljar sur les Agent Skills vous permettront de démarrer. Ceci traite de ce qui se passe après vos dix premières skills -- les patterns qui émergent, les erreurs qui se répètent et les décisions architecturales qui séparent les skills que vous utiliserez pendant des années de celles que vous supprimerez dans un mois.

Voici la question qui a tout changé pour moi : quel type de skill suis-je réellement en train de construire ?

Pourquoi la plupart des skills meurent jeunes -- et un changement de mentalité qui résout le problème

Je pensais qu'une skill était une skill était une skill. Vous écrivez quelques instructions en markdown, peut-être ajoutez un script ou deux, vous le placez dans .claude/skills/ et vous passez à autre chose. Cette approche fonctionnait bien quand j'avais trois skills. Quand j'en ai eu quinze, ma configuration était un chaos.

Les skills entraient en conflit les unes avec les autres. Certaines chargeaient du contexte non pertinent 90 % du temps. D'autres étaient si génériques qu'elles amélioraient à peine la sortie de Claude. Une skill -- mon "contrôle qualité de code" originel -- contredisait ma skill de "pratiques de test" d'une manière que je n'ai pas remarquée pendant des semaines.

Le déclic est venu quand j'ai commencé à catégoriser mes skills par ce qu'elles font réellement, pas par leur sujet. Après avoir catalogué tout dans ma configuration et étudié comment les équipes internes d'Anthropic organisent leurs propres skills (ils en ont partagé une partie publiquement), j'ai remarqué que chaque skill utile s'inscrit clairement dans l'une d'environ neuf catégories. Les skills confuses et difficiles à maintenir ? C'étaient toujours celles qui essayaient de chevaucher plusieurs catégories à la fois.

Voici la taxonomie que j'utilise désormais avant de construire quoi que ce soit de nouveau.

Les skills de référence bibliothèques et API expliquent comment utiliser correctement un outil, SDK ou bibliothèque interne spécifique. Ma skill Aria entre parfaitement dans cette catégorie -- elle encode les directives de marque, les règles de voix, les exigences SEO et les patterns d'architecture de contenu pour quatre sites web différents. Sans elle, Claude écrit des articles compétents qui ne ressemblent en rien à ma marque.

Les skills de vérification produit décrivent comment tester ou vérifier que la sortie est effectivement correcte. Associées à Playwright, tmux ou des scripts personnalisés. J'ai sous-investi ici pendant des mois. Plus de détails à ce sujet plus loin.

Les skills de récupération et analyse de données se connectent à vos stacks de données et de monitoring -- UIDs de datasource Grafana, IDs de dashboard, patterns de requêtes courants. Claude arrête de deviner les noms de colonnes et commence à écrire des requêtes qui fonctionnent vraiment.

Les skills d'automatisation de processus métier et d'équipe automatisent les workflows répétitifs. Ma skill standup-post agrège l'activité GitHub, les mises à jour de tickets et les messages Slack en une mise à jour quotidienne formatée. Instructions simples, valeur cumulative.

Les skills de scaffolding et templates de code génèrent du boilerplate pour des patterns spécifiques de votre codebase. Une skill Laravel "nouvelle migration" avec les conventions et les pièges de votre équipe fait gagner trente minutes à chaque fois.

Les skills de qualité et revue de code appliquent des standards. Ma configuration de revue adversariale lance un sous-agent pour critiquer le code, implémente les corrections et itère jusqu'à ce que les trouvailles se dégradent en détails insignifiants.

Les skills CI/CD et déploiement aident à récupérer, pousser et déployer. Ma skill babysit-pr surveille les PRs, relance les CI instables, résout les conflits de merge et active l'auto-merge.

Les skills de runbook prennent un symptôme et parcourent une investigation multi-outils pour produire un rapport structuré. Des mines d'or pour les rotations d'astreinte.

Les skills d'opérations d'infrastructure gèrent la maintenance routinière avec des garde-fous -- workflows de dépendances, investigation des coûts, nettoyage des ressources orphelines avec confirmation obligatoire avant les actions destructives.

Dès que j'ai commencé à demander "dans quelle catégorie cela s'inscrit-il ?" avant d'écrire une seule ligne de markdown, mes skills sont devenues plus précises. Si une skill essaie d'être à la fois un vérificateur de qualité de code ET un template de scaffolding, je la divise en deux. Si elle ne rentre clairement dans aucune catégorie, je remets en question son existence même.

Mais catégoriser les skills n'est que le point de départ. Le véritable savoir-faire réside dans la manière dont vous les écrivez.

La section gotchas vaut plus que tout le reste de la skill combiné

Je vais avancer une affirmation qui peut sembler extrême : la partie la plus précieuse de toute skill est sa section gotchas. Pas les instructions. Pas les exemples. Pas la configuration. Les gotchas.

Voici pourquoi. Claude sait déjà beaucoup de choses. Il sait écrire du Python, structurer un composant React, construire une REST API. Quand vous écrivez une skill qui explique l'utilisation basique de quelque chose que Claude comprend déjà, vous gaspillez des tokens et contraignez la flexibilité du modèle. Mais quand vous documentez les modes de défaillance spécifiques -- les edge cases que Claude rencontre de manière répétée, les hypothèses qu'il fait et qui sont fausses dans votre contexte spécifique, les bugs subtils qui n'apparaissent qu'en production -- c'est là que les skills prouvent leur valeur.

Ma skill de contenu Aria a une section "Phrases Interdites" de plus de cinquante éléments. Des choses comme "Dans le monde en constante évolution d'aujourd'hui" et "Plongeons dans le vif du sujet" et "Par ailleurs" -- des phrases qui signalent instantanément un contenu généré par l'IA. Je n'ai pas écrit cette liste en une seule fois. Je l'ai construite sur trois mois en repérant Claude qui retombait dans le langage d'IA, en ajoutant chaque contrevenant à la liste de gotchas et en observant la qualité de la sortie s'améliorer à chaque ajout.

Même pattern avec ma skill de migrations Laravel. La syntaxe réelle de migration ? Claude la maîtrise parfaitement. Mais les gotchas -- "ne jamais utiliser ->change() sur une colonne qui a un index dans MySQL 5.7", "toujours ajouter ->after('column_name') pour maintenir l'ordre des colonnes", "notre base de staging utilise un collation différent de la production" -- ces entrées empêchent des bugs qui prendraient autrement des heures à debugger.

La leçon pratique : commencez chaque nouvelle skill avec un ensemble minimal d'instructions et une section gotchas vide. Utilisez la skill pendant une semaine. Chaque fois que Claude fait quelque chose d'incorrect ou d'inattendu, ajoutez-le aux gotchas. Au bout d'un mois, votre section gotchas sera la partie la plus raffinée et éprouvée au combat de la skill. Ce sera aussi la partie qui vous fera gagner le plus de temps.

Je révise maintenant mes sections gotchas mensuellement. Certaines entrées sont promues dans les instructions principales parce qu'elles sont si fondamentales. D'autres sont supprimées parce que Claude s'est amélioré et ne commet plus cette erreur nativement. Ce cycle de maintenance est ennuyeux mais c'est la différence entre une skill qui reste affûtée et une qui se dégrade lentement.

Cette habitude de révision mensuelle mène directement à une autre leçon que j'ai mis un temps embarrassant à apprendre.

Les skills sont des dossiers, pas des fichiers -- et ça change tout

Une idée fausse que j'ai gardée bien trop longtemps : une skill est "juste un fichier markdown". Techniquement, un fichier SKILL.md est tout ce dont vous avez besoin. Mais dès que vous traitez les skills comme des dossiers -- avec des scripts, des fichiers de référence, des templates et des données -- leur puissance se multiplie.

Voici la structure de ma skill de contenu Aria telle qu'elle existe aujourd'hui :

aria/
  SKILL.md              # Core instructions, loaded on trigger
  aria-system-prompt.md # Full brand guidelines, loaded on demand
  references/
    banned-phrases.md   # AI detection trigger phrases
    footer-templates.md # Brand-specific CTA footers
    headline-formulas.md # Proven header structures by brand
  assets/
    post-template.md    # Skeleton for new blog posts
  scripts/
    word-count.sh       # Validates 3,000-5,000 word requirement

Le fichier SKILL.md est maintenu sous 500 lignes. Il contient l'identité centrale, la philosophie d'écriture et les pointeurs vers les fichiers de référence. Quand Claude génère un article pour mejba.me, il lit les sections spécifiques à la marque depuis le system prompt. Quand il doit vérifier un titre contre des formules éprouvées, il consulte references/headline-formulas.md. La liste de phrases interdites vit dans son propre fichier parce qu'elle change fréquemment et je ne veux pas que les modifications polluent mes instructions principales.

C'est de la divulgation progressive en action. Claude ne charge pas tout en une fois. Le frontmatter YAML -- nom et description -- entre dans le prompt au démarrage de la session. C'est environ 100 tokens. Le corps du SKILL.md se charge quand Claude détermine que la skill est pertinente. Les fichiers de référence ne se chargent que quand le SKILL.md dirige explicitement Claude à les lire.

Pourquoi est-ce important ? Parce que la gestion de la fenêtre de contexte est une contrainte réelle. Chaque token d'instructions de skill est un token qui ne peut pas être utilisé pour la tâche réelle. Si je déversais tout mon système Aria -- directives de marque pour quatre sites web, cinquante phrases interdites, templates de footer, formules de titres, le blueprint complet d'architecture de contenu -- dans un seul fichier SKILL.md, ce seraient des milliers de tokens chargés pour chaque conversation, même celles où je demande juste à Claude de corriger une faute de frappe.

La structure en dossiers rend aussi la maintenance radicalement plus facile. Quand j'ai besoin de mettre à jour les phrases interdites, j'édite un fichier. Quand j'ajoute une nouvelle marque, je mets à jour le system prompt sans toucher à la logique centrale de la skill. Quand un collègue veut comprendre ce que fait la skill, il lit le SKILL.md. Quand il veut comprendre les directives de marque approfondies, il lit les fichiers de référence.

Un pattern que j'ai commencé à utiliser récemment : inclure des fichiers template dans assets/ que Claude copie et remplit plutôt que de générer à partir de zéro. Mon template d'article de blog inclut le bloc de métadonnées, les marqueurs de structure par phases et le footer obligatoire. Claude n'a pas besoin de se souvenir du format exact -- il copie simplement le template et remplit les blancs. Moins d'erreurs de format, une sortie plus cohérente.

Si vous préférez que quelqu'un construise ce type d'architecture de skills pour vos propres workflows, j'accepte des configurations et intégrations Claude Code sur mesure. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Il y a une subtilité ici que j'ai failli manquer -- et elle concerne ce que vous ne mettez PAS dans la skill.

Ce que j'ai appris sur le fait de ne pas brider Claude

Mes skills de première génération étaient des dictateurs. Chaque étape prescrite. Chaque format de sortie verrouillé. Chaque décision prise à l'avance.

Les résultats étaient cohérents. Ils étaient aussi médiocres.

Le problème de la sur-spécification d'une skill est que vous perdez la capacité d'adaptation de Claude. Vous convertissez essentiellement un moteur de raisonnement intelligent en un remplisseur de templates. Et les remplisseurs de templates ne gèrent pas les edge cases. Ils ne vous surprennent pas avec une meilleure approche que celle que vous aviez prévue. Ils ne détectent pas les erreurs dans vos propres instructions.

J'ai appris cette leçon avec ma skill de revue de code. La version un était une checklist de vingt étapes : vérifier les imports inutilisés, vérifier la gestion des erreurs, confirmer la couverture de tests, valider les conventions de nommage... Claude parcourait méthodiquement chaque élément et produisait une revue parfaitement formatée. Mais les revues passaient à côté de ce qui comptait vraiment -- les préoccupations architecturales, les implications de performance, les vulnérabilités de sécurité qui ne rentraient dans aucun élément de la checklist.

La version deux a réduit la checklist à cinq principes et une section gotchas. Au lieu de "vérifier les imports inutilisés", elle disait "priorise les trouvailles par impact réel sur la fiabilité en production". Au lieu de prescrire le format de sortie, elle disait "structure ta revue pour aider l'auteur à comprendre le pourquoi derrière chaque trouvaille".

Les revues se sont radicalement améliorées. Claude a commencé à détecter des choses que la checklist ne couvrait jamais -- des race conditions, des violations de contrats d'API, des bugs subtils de gestion d'état. Il réfléchissait au code au lieu de cocher des cases.

Le principe que je suis désormais : donnez à Claude l'information dont il a besoin et la flexibilité pour s'adapter à la situation. Dites-lui ce qui compte, pas exactement quoi faire. Incluez vos gotchas et contraintes, mais laissez de la place au modèle pour appliquer son propre jugement.

Il y a un moyen concret de tester si vous avez sur-spécifié : exécutez la même tâche trois fois avec votre skill. Si les sorties sont quasi identiques en structure et en contenu, votre skill est probablement trop rigide. Si elles sont cohérentes en qualité mais variées dans l'approche, vous avez trouvé le bon équilibre.

Ce principe de flexibilité s'applique aussi aux déclencheurs de skills -- et c'est là que le champ description devient critique.

Le champ description est du marketing pour le modèle, pas pour les humains

Quand Claude Code démarre une session, il construit une liste de chaque skill disponible avec sa description. Cette liste est ce que Claude scanne pour décider "y a-t-il une skill pour cette requête ?". Le champ description n'est pas un résumé pour les lecteurs humains. C'est une spécification de déclencheur pour le modèle.

J'ai fait cette erreur avec mon premier lot de skills. Ma skill de messages de commit avait une description comme : "Aide à écrire de meilleurs messages de commit". Vague. Générique. Claude la déclenchait pour tout ce qui touchait de près ou de loin à git, y compris quand je voulais juste vérifier un log ou un diff.

La description révisée : "Utiliser quand l'utilisateur demande de créer un commit, d'écrire un message de commit, ou dit /commit. Ne pas déclencher pour git log, git diff, git status ou d'autres opérations git en lecture seule".

La différence est colossale. Claude déclenche maintenant la skill précisément quand j'en ai besoin et reste en retrait quand ce n'est pas le cas.

Quelques patterns que j'ai trouvés efficaces pour les descriptions :

Déclencheurs positifs -- ce qui devrait activer la skill : "Utiliser quand l'utilisateur demande de créer un article de blog, d'écrire un article, de générer du contenu, ou mentionne l'une de ces marques : mejba.me, ramlit.com, colorpark.io, xcybersecurity.io".

Déclencheurs négatifs -- ce qui ne devrait PAS l'activer : "Ne pas déclencher pour les revues de code, la correction de bugs ou la documentation technique".

Conditions de contexte -- quand la skill s'applique : "Pertinent uniquement quand on travaille dans des dépôts utilisant Laravel 11+ avec Livewire".

Bien calibrer cela prévient un problème qui affecte les grandes collections de skills : les conflits de déclenchement. Quand deux skills prétendent toutes les deux gérer les "tâches d'écriture", Claude doit deviner laquelle vous voulez. Des descriptions spécifiques et bien délimitées éliminent les suppositions.

Cela devient encore plus important quand vous commencez à composer les skills ensemble, et c'est là que la vraie puissance se révèle.

Composition de skills : là où l'effet multiplicateur entre en jeu

Les skills individuelles sont utiles. Les skills qui se référencent et se construisent les unes sur les autres sont transformatrices.

Mon pipeline de contenu fonctionne ainsi : la skill Aria gère la génération de contenu. Elle référence une skill SEO toolkit pour la recherche et l'optimisation de mots-clés. La skill SEO, à son tour, référence une skill d'analyse de données qui peut extraire des données de trafic et des métriques de la Search Console. Quand je demande à Claude de "créer un article pour mejba.me sur le networking Docker", ces trois skills se coordonnent automatiquement.

La composition n'est pas gérée par un système de dépendances -- Claude Code n'a pas encore de gestion native des dépendances pour les skills. À la place, je référence d'autres skills par nom dans mes fichiers SKILL.md : "Pour l'analyse SEO, invoque la skill seo-toolkit". Claude lit cette instruction et invoque la skill référencée si elle est installée.

Cela fonctionne étonnamment bien en pratique. Mais il y a un piège : les références circulaires. Si la skill A dit "vérifie avec la skill B" et la skill B dit "confirme avec la skill A", Claude entre dans une boucle. C'est arrivé une fois avec mes skills de revue de code et de tests -- la skill de revue disait "vérifie que les tests existent" et la skill de tests disait "vérifie les trouvailles de la revue de code". La solution a été de rendre la dépendance directionnelle : la revue de code peut invoquer les pratiques de test, mais pas l'inverse.

Un autre pattern de composition qui a porté ses fruits : utiliser une skill "orchestratrice" simple qui connaît toutes vos autres skills et route les tâches vers la bonne. Ma skill de workflow de développement ne fait aucun travail réel elle-même -- elle sait juste que le scaffolding de code va à la skill de scaffolding, les revues vont à la skill de revue et les déploiements vont à la skill CI/CD. C'est un dispatcher, et il m'évite d'avoir à me rappeler quelle skill gère quoi.

Le pattern orchestrateur rend aussi l'intégration de nouveaux membres d'équipe triviale. Ils installent une skill, et elle route automatiquement vers tout le reste dont ils ont besoin. Ce qui soulève la question de comment partager les skills au sein d'une équipe.

Comment je distribue les skills sans créer le chaos

Partager des skills semble simple. Vous les committez dans votre dépôt sous .claude/skills/ et tout le monde les obtient. Terminé.

Sauf que ce n'est pas terminé. Parce que chaque skill committée dans le dépôt s'ajoute au contexte que Claude charge pour chaque membre de l'équipe, qu'ils aient besoin de cette skill ou non. Une équipe de cinq avec dix skills chacun signifie cinquante skills en contexte. C'est beaucoup de bruit.

L'approche que j'ai adoptée utilise deux niveaux.

Niveau un : les skills au niveau du dépôt vont dans .claude/skills/ et sont committées dans le dépôt. Ce sont les skills dont chaque contributeur a besoin -- application du style de code, conventions de test, procédures de déploiement. Si vous touchez à ce codebase, vous avez besoin de ces skills. Point final. Je garde cette liste intentionnellement courte : trois à cinq skills par dépôt, maximum.

Niveau deux : les skills personnelles et spécifiques à un rôle sont distribuées comme plugins via un répertoire partagé. Mes skills de contenu, mes outils SEO, mes références de design system -- celles-ci sont installées par utilisateur. Les développeurs de l'équipe n'ont pas besoin de ma skill de contenu Aria. Je n'ai pas besoin de leur skill de migration de base de données. Chacun installe ce qui est pertinent pour son travail.

Pour des équipes de plus de dix personnes environ, je recommanderais de construire un marketplace interne de plugins -- un dépôt GitHub partagé où les gens peuvent parcourir les skills disponibles, lire les descriptions et installer ce dont ils ont besoin. Les équipes internes d'Anthropic font quelque chose de similaire : les skills démarrent dans un répertoire sandbox, les gens les partagent via Slack, et une fois qu'une skill gagne en traction, le propriétaire soumet une PR pour la déplacer dans le marketplace officiel.

L'étape de curation compte plus qu'on ne le pense. Sans contrôle, les collections de skills gonflent rapidement. Les gens créent des skills pour chaque petit désagrément, et en quelques mois vous avez quarante skills là où dix suffiraient. Avant d'ajouter quoi que ce soit à un marketplace partagé, je demande : "Au moins trois personnes de cette équipe utiliseraient-elles cette skill au moins une fois par semaine ?" Si la réponse est non, elle reste personnelle.

Une dernière leçon de distribution que j'ai apprise à la dure -- qui se trouve aussi être l'une des fonctionnalités les plus puissantes que la plupart des gens ignorent.

Les hooks à la demande ont changé ma façon de penser la sécurité

Les skills peuvent enregistrer des hooks qui ne s'activent que lorsque la skill est invoquée, pour la durée de la session. C'est différent des hooks globaux qui tournent en permanence. Les hooks à la demande sont des garde-fous contextuels.

Ma skill /careful est le meilleur exemple. Quand je m'apprête à travailler sur de l'infrastructure de production, je l'invoque. La skill enregistre des hooks PreToolUse qui bloquent rm -rf, DROP TABLE, force-push et kubectl delete. Ces hooks interceptent chaque commande Bash que Claude essaie d'exécuter et rejettent tout ce qui correspond aux patterns dangereux.

Je ne veux pas que ces hooks tournent en permanence -- ils seraient insupportables pendant le développement normal. Mais quand je touche à des bases de données de production ou à des clusters Kubernetes en live, ils sont non négociables. La skill me donne un interrupteur : sécurité maximale quand j'en ai besoin, zéro surcharge quand je n'en ai pas besoin.

Un autre hook à la demande que j'utilise : /freeze, qui bloque toute opération Edit ou Write en dehors d'un répertoire spécifique. Quand je débugue un problème de production, je veux que Claude lise et analyse librement mais ne modifie rien accidentellement. La skill freeze verrouille le système de fichiers tout en gardant l'accès en lecture ouvert.

Le système de hooks permet aussi la mesure. J'exécute un hook PreToolUse qui enregistre chaque invocation de skill -- quelle skill, quand elle s'est déclenchée, dans quel contexte elle a tourné. Au bout d'un mois de données, je peux voir quelles skills sont populaires, lesquelles se déclenchent insuffisamment (ce qui signifie que leurs descriptions ont besoin d'être retravaillées) et lesquelles se déclenchent trop (ce qui signifie que leur portée est trop large).

Ce type d'instrumentation semble excessif jusqu'à ce que vous gériez trente skills et essayiez de comprendre pourquoi votre session Claude Code est plus lente qu'elle ne devrait l'être. Les données de logs vous disent exactement où va le budget de contexte.

En parlant de budgets de contexte -- il y a un pattern de mémoire que j'aurais aimé commencer à utiliser dès le premier jour.

Apprendre à vos skills à se souvenir

Certaines de mes skills les plus efficaces maintiennent un état entre les sessions. Pas via une base de données sophistiquée -- via de simples fichiers texte.

Ma skill standup-post conserve un fichier standups.log. Chaque fois qu'elle génère un standup, elle ajoute la sortie à la suite. Le lendemain matin, Claude lit son propre historique et sait exactement ce qui a changé depuis la veille. Les standups sont passés de résumés génériques à des rapports de delta précis : "Mergé la PR de refactoring d'auth qui bloquait depuis mardi. Trois nouveaux tickets ouverts, tous triés dans le sprint en cours".

Ma skill de pipeline de contenu suit quels sujets j'ai couverts, quels mots-clés j'ai ciblés et quels liens internes j'ai placés. Quand je demande un nouvel article, Claude vérifie le log et évite de dupliquer des angles que j'ai déjà publiés. Il peut aussi suggérer des liens internes vers du contenu existant parce qu'il sait ce qui est déjà en ligne.

L'implémentation est d'une simplicité redoutable. Un fichier JSON ou un log en ajout seul dans un répertoire stable. Claude Code fournit ${CLAUDE_PLUGIN_DATA} comme dossier stable par plugin spécifiquement pour cet usage -- les données stockées ici persistent même quand vous mettez à jour la skill.

// ${CLAUDE_PLUGIN_DATA}/content-history.json
{
  "posts": [
    {
      "date": "2026-03-10",
      "brand": "mejba.me",
      "slug": "opus-4-6-hands-on-review",
      "primary_keyword": "Claude Opus 4.6 review",
      "internal_links": ["claude-sonnet-5-agentic-coding", "claude-agent-teams-guide"]
    }
  ],
  "keywords_used": ["Claude Opus 4.6", "agentic coding", "agent teams"],
  "next_suggested": ["Claude Code skills deep dive", "hook development patterns"]
}

Un avertissement : ne stockez pas les données de mémoire dans le répertoire de la skill elle-même. Quand vous mettez à jour une skill, le répertoire peut être écrasé. J'ai perdu deux mois d'historique de standups en apprenant cette leçon. Utilisez toujours un chemin externe stable.

Le pattern de mémoire ouvre aussi quelque chose de puissant -- des skills qui s'améliorent d'elles-mêmes au fil du temps. Chaque fois que Claude rencontre un nouveau edge case et que je l'ajoute à la section gotchas, c'est de l'amélioration manuelle. Mais une skill qui enregistre ses propres échecs et les présente pour révision ? Ça se rapproche de l'auto-amélioration. Je n'ai pas encore entièrement automatisé cette boucle, mais l'infrastructure de logging rend cela possible.

Bien -- cela couvre les principes. À quoi cela ressemble-t-il concrètement quand on assemble le tout ?

À quoi ressemble mon workflow réel en mars 2026

Voici un lundi matin typique. J'ouvre Claude Code et démarre une session. Trois skills au niveau du dépôt se chargent automatiquement depuis .claude/skills/ : application du style de code, conventions de test et notre checklist de déploiement. Mes plugins personnels se chargent aussi : Aria (contenu), SEO toolkit, conventions de commit, revue de code, workflow TDD et quelques skills utilitaires.

Surcharge totale de contexte au démarrage de session : environ 600 tokens pour toutes les descriptions de skills. Les corps réels des skills ne se sont pas encore chargés -- ils attendent d'être pertinents.

Je tape : "Crée un article pour mejba.me sur les bonnes pratiques de networking Docker".

Claude scanne les descriptions de skills, identifie Aria comme pertinente, charge le corps du SKILL.md. Les instructions d'Aria disent à Claude de vérifier le log d'historique de contenu, qui réside dans ${CLAUDE_PLUGIN_DATA}. Claude lit l'historique, confirme que je n'ai pas encore couvert cet angle spécifique et identifie deux articles existants qui devraient être liés en interne.

La skill Aria référence le SEO toolkit. Claude charge cette skill aussi, lance l'analyse de mots-clés et détermine les mots-clés primaires et secondaires. Les deux skills sont maintenant actives, travaillant ensemble.

Claude génère le package de contenu complet -- métadonnées, article de 3 500 mots, footer approprié à la marque. Le script de comptage de mots dans aria/scripts/ valide la longueur. Si c'est en dessous de 3 000 ou au-dessus de 5 000 mots, Claude ajuste. Le log d'historique de contenu est mis à jour avec les détails du nouvel article.

Temps total : environ huit minutes. Le même travail sans skills -- expliquer les directives de marque, les exigences SEO, l'architecture de contenu, les phrases interdites, le format du footer, la stratégie de liens internes -- prendrait quarante minutes d'ingénierie de prompt avant même que Claude ne commence à écrire.

Ce n'est pas un hack de productivité. C'est un changement fondamental dans ma façon de travailler avec l'IA.

Les trois erreurs que je continue de voir (et que je fais encore parfois)

Après avoir aidé une douzaine de développeurs à mettre en place leurs propres systèmes de skills, les mêmes trois erreurs reviennent sans cesse.

Erreur une : construire des skills pour des choses que Claude fait déjà bien. Si vous écrivez une skill qui dit à Claude comment écrire une boucle for ou structurer une réponse JSON, vous gaspillez de l'effort. Les skills devraient encoder des connaissances que Claude n'a pas -- vos conventions spécifiques, vos APIs internes, les modes de défaillance de votre équipe. Testez cela en exécutant la tâche sans la skill d'abord. Si la sortie est déjà à 80 % de ce que vous voulez, vous n'avez probablement pas besoin d'une skill. Vous avez besoin d'une phrase dans votre fichier CLAUDE.md.

Erreur deux : ne jamais mettre à jour les skills après leur création. Les skills ne sont pas des artefacts qu'on écrit une fois. Claude s'améliore à chaque mise à jour du modèle. Votre codebase évolue. Les conventions de votre équipe changent. Une skill qui était parfaite il y a trois mois pourrait être activement nuisible aujourd'hui. Je programme un "audit de skills" mensuel -- trente minutes où je révise chaque skill, élague les gotchas obsolètes et teste si la skill améliore encore la sortie par rapport à une exécution sans elle.

Erreur trois : rendre les skills trop larges. Une skill "assistant de développement" qui couvre le style de code, les tests, le déploiement et la documentation, c'est quatre skills dans un trench coat qui font semblant d'en être une seule. Divisez-la. Chaque skill devrait avoir un objectif unique et clair que vous pouvez énoncer en une phrase. Si vous avez besoin du mot "et" pour décrire ce que fait une skill, c'est probablement deux skills.

Il y a une quatrième erreur plus subtile et plus difficile à détecter : ne pas investir dans les skills de vérification. J'ai passé des mois à construire des skills de génération -- des skills qui aident Claude à créer des choses. Mais j'ai à peine investi dans des skills qui aident Claude à vérifier sa propre sortie. Les skills de vérification sont ennuyeuses à construire mais elles attrapent les erreurs avant qu'elles n'atteignent la production. Un driver de flux d'inscription qui teste le parcours utilisateur complet. Un vérificateur de checkout qui exerce les cartes de test Stripe. Un smoke test de déploiement qui confirme que les health checks passent. Ces skills ne produisent pas de sorties impressionnantes. Elles préviennent les échecs embarrassants. Si je pouvais revenir en arrière et redistribuer mon temps de construction de skills, la vérification recevrait 40 % du budget au lieu des 10 % qu'elle a réellement reçus.

Ce qui arrive ensuite pour les skills (et vers quoi je construis)

L'écosystème des skills en mars 2026 mûrit rapidement. Le marketplace officiel de skills d'Anthropic a connu une croissance explosive -- rien que la skill frontend-design compte plus de 277 000 installations. Les plateformes communautaires comme skills.sh fournissent des répertoires consultables organisés par catégorie, auteur et nombre d'installations. La commande npx skills add a rendu l'installation d'une facilité triviale.

Mais la vraie évolution réside dans la façon dont les skills composent et communiquent. En ce moment, la composition des skills se fait par des références par nom en markdown -- "invoque la skill X". Ça fonctionne, mais c'est manuel et fragile. J'attends une gestion native des dépendances dans l'année qui vient, où le frontmatter d'une skill pourra déclarer des prérequis qui se chargent automatiquement.

Je surveille aussi de près l'intersection des skills et des hooks. Les hooks à la demande qui s'activent par skill sont déjà puissants. La prochaine étape, ce sont des hooks qui se coordonnent entre skills -- une skill de revue de code qui déclenche automatiquement une skill de test, qui déclenche une vérification de préparation au déploiement, le tout dans un pipeline vérifié. Actuellement, je câble cela manuellement. Bientôt, ce sera déclaratif.

La frontière la plus intéressante, ce sont les skills qui apprennent -- non pas par l'entraînement, mais par le logging structuré et l'auto-réflexion. J'ai un prototype qui tourne avec mon pipeline de contenu où Claude révise son log d'historique chaque semaine, identifie des patterns dans les modifications que j'ai faites et propose des ajouts à la liste de phrases interdites. Nous n'en sommes pas encore à l'auto-amélioration autonome. Mais tous les éléments constitutifs sont là.

Les skills qui compteront le plus dans un an ne sont pas les plus tape-à-l'oeil. Ce sont celles qui améliorent discrètement votre travail quotidien et deviennent un peu plus affûtées chaque mois parce que quelqu'un a pris trente minutes pour réviser les gotchas.

Commencez par là. Construisez une skill cette semaine pour la tâche que vous faites le plus souvent. Gardez les instructions minimales et la section gotchas vide. Utilisez-la pendant un mois. Ajoutez chaque échec aux gotchas. À la fin du mois, vous aurez quelque chose de véritablement utile. Et vous comprendrez, d'une manière qu'aucune documentation ne peut enseigner, pourquoi les skills sont le point d'extension le plus puissant de Claude Code.

Quel est ce workflow que vous répétez chaque jour et qui nécessite encore du prompting manuel ? C'est votre première skill. Allez la construire.

Foire aux questions

Combien de skills Claude Code devrais-je avoir installées en même temps ?

Gardez les skills au niveau du dépôt entre trois et cinq par dépôt et les skills personnelles en dessous de quinze au total. Au-delà, les descriptions de skills consomment un contexte significatif et les conflits de déclenchement deviennent plus difficiles à gérer. La qualité et la spécificité l'emportent sur la quantité -- toujours.

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

Le CLAUDE.md se charge pour chaque conversation dans un projet et couvre le contexte général du codebase. Les skills ne se chargent que lorsqu'elles sont déclenchées par des requêtes pertinentes, peuvent inclure des scripts et des fichiers de référence, et supportent les hooks. Utilisez CLAUDE.md pour les faits universels du projet ; utilisez les skills pour des workflows spécifiques.

À quelle fréquence devrais-je mettre à jour mes skills Claude Code ?

Les révisions mensuelles fonctionnent bien pour la plupart des équipes. Vérifiez chaque skill par rapport aux capacités natives actuelles de Claude, élaguez les gotchas obsolètes et testez si la skill améliore encore la sortie de manière mesurable par rapport à une exécution sans elle. Les mises à jour du modèle peuvent rendre les skills d'amélioration de capacités obsolètes rapidement.

Les skills Claude Code peuvent-elles appeler d'autres skills ?

Oui, par des références par nom dans les instructions de votre SKILL.md. Écrivez "invoque la skill [nom-de-la-skill] pour cette étape" et Claude la déclenchera si elle est installée. La gestion native des dépendances n'est pas encore intégrée, donc gardez les références directionnelles pour éviter les boucles circulaires.

Où devrais-je stocker les données que mes skills génèrent entre les sessions ?

Utilisez la variable d'environnement ${CLAUDE_PLUGIN_DATA}, qui fournit un répertoire stable par plugin qui persiste à travers les mises à jour de skills. Ne stockez jamais de données persistantes dans le dossier de la skill lui-même -- il peut être écrasé lors des mises à jour.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io