Claude Skills : Le guide de 32 pages d'Anthropic, décrypté
Cela fait huit mois que j'écris les mêmes instructions pour Claude. Chaque lundi matin, le même prompt de planification de sprint. Chaque appel client, le même modèle de notes de réunion. Chaque déploiement, la même checklist collée dans la fenêtre de chat comme une sorte de Jour de la marmotte numérique.
Puis Anthropic a publié un guide de 32 pages sur quelque chose appelé Claude Skills — et en un seul après-midi, j'ai supprimé tous les prompts que j'avais sauvegardés.
Pas archivés. Supprimés. Parce qu'une fois que vous comprenez ce que sont réellement les Skills, revenir au copier-coller de prompts, c'est comme revenir à écrire des lettres après avoir découvert l'e-mail. Le concept est d'une simplicité trompeuse : vous enseignez quelque chose à Claude une fois, dans un dossier avec un fichier markdown et quelques scripts optionnels, et il sait simplement comment faire cette chose à partir de ce moment. Sans réexpliquer. Sans "voici mon guide de style à nouveau." Sans "rappelle-toi, nous utilisons Tailwind, pas Bootstrap."
Un fichier SKILL.md. Un peu de YAML en haut. C'est fait.
Mais — et c'est ce que je veux approfondir — le guide lui-même est à la fois brillant et frustrant. Brillant parce que le framework qu'il présente est véritablement puissant. Frustrant parce que les détails d'implémentation les plus importants sont enfouis sous des couches de documentation soignée, et certaines des leçons les plus durement acquises sur la façon de faire fonctionner les Skills sont mentionnées en passant ou pas du tout.
J'ai passé trois jours à lire le guide, construire des Skills, casser des Skills et les reconstruire. Ce qui suit est tout ce que j'aurais aimé que quelqu'un me dise avant de commencer — les parties qu'Anthropic a réussies, celles qu'ils ont survolées, et les cinq patterns qui comptent vraiment une fois que vous retirez le langage marketing.
Le concept qui fait tout comprendre
Voici le modèle mental qui a finalement donné du sens à Claude Skills pour moi, et ce n'est pas celui qu'Anthropic met en avant.
Vous connaissez probablement déjà MCP — le Model Context Protocol qui permet à Claude de se connecter à des outils externes comme Notion, Linear, Figma, GitHub, Slack, et essentiellement tout ce qui a une API. MCP concerne l'accès. Il donne à Claude les clés de vos outils. Ouvrir la porte, entrer, regarder autour.
Les Skills sont différents. Les Skills concernent le jugement.
Pensez-y de cette façon. Vous embauchez un nouveau développeur et lui donnez un accès administrateur à tout votre stack — votre outil de gestion de projet, votre pipeline CI/CD, votre système de design, vos canaux de communication. Il peut techniquement toucher à tout. Mais il ne connaît pas les conventions de votre équipe. Il ne sait pas que le calcul de vélocité du sprint exclut les bugs de moins de deux story points. Il ne sait pas que les livraisons de design passent toujours par un workflow spécifique Figma-vers-Linear avec des annotations d'accessibilité obligatoires. Il ne sait pas que les annonces de déploiement suivent un format particulier dans un canal Slack spécifique.
L'accès sans le jugement crée le chaos. MCP donne l'accès à Claude. Les Skills donnent le jugement à Claude.
Cette distinction résume l'intégralité du guide en une seule phrase. Tout le reste — le frontmatter YAML, la structure des dossiers, les cinq patterns, les conseils de débogage — sont des détails d'implémentation qui découlent de cette idée centrale.
Une fois que cela a fait tilt pour moi, j'ai arrêté de penser aux Skills comme des "prompts sophistiqués" et j'ai commencé à les voir comme du savoir institutionnel capturé dans du code. Et ce changement de perspective a transformé la façon dont j'ai construit chacun d'entre eux.
La question pratique, bien sûr, est comment capturer ce savoir dans un format que Claude peut utiliser. Le guide y consacre beaucoup de pages, et une partie est vraiment utile. Mais il y a un raccourci que personne ne vous dit, et j'y viendrai après avoir passé en revue la mécanique.
Ce qu'il y a vraiment dans le dossier — Et ce que chaque élément fait
Un Claude Skill vit dans un dossier. Au minimum, ce dossier contient un fichier : SKILL.md. C'est tout. Un fichier markdown, et vous avez un Skill fonctionnel.
En haut de ce fichier markdown se trouve le frontmatter YAML — le bloc de métadonnées entre les tirets triples qui indique à Claude ce qu'est ce Skill, ce qu'il fait et, de manière cruciale, quand l'activer. Le reste du fichier contient les instructions proprement dites : comment exécuter la tâche, quels standards suivre, quels outils utiliser et quels pièges éviter.
Optionnellement, vous pouvez ajouter des scripts, des documents de référence et des modèles au dossier. Un PDF de guide de style. Un script bash qui exécute du linting. Un schéma JSON pour les réponses de votre API. Claude les consultera lors de l'exécution du Skill.
Voici un exemple minimal — un Skill qui génère des rapports d'état hebdomadaires pour mes projets :
---
name: weekly-status-report
description: >
Generates a formatted weekly status report by pulling data
from Linear and GitHub. Trigger when user asks for a status
report, weekly update, or progress summary.
---
## Générateur de rapports d'état hebdomadaires
### Ce que fait ce Skill
Produit un rapport d'état hebdomadaire concis couvrant le travail accompli,
les éléments en cours, les blocages et les priorités de la semaine suivante.
### Sources de données
1. Récupérer les issues terminées dans Linear pour le sprint en cours
2. Récupérer les PRs fusionnés dans GitHub des 7 derniers jours
3. Récupérer les blocages ouverts étiquetés "blocked" dans Linear
### Format du rapport
- **Résumé** (2-3 phrases, plus grandes réussites et risques)
- **Terminé** (liste à puces avec références de tickets)
- **En cours** (liste à puces avec estimations de pourcentage)
- **Blocages** (liste à puces avec responsable et ancienneté en jours)
- **Semaine prochaine** (top 3 des priorités)
### Règles de style
- Pas de jargon — c'est destiné aux stakeholders, pas aux ingénieurs
- Commencer chaque section par l'élément le plus impactant
- Les blocages doivent inclure qui est responsable de la résolution
- Garder la longueur totale sous 500 mots
C'est un Skill complet. Quand je demande à Claude "donne-moi la mise à jour de cette semaine", il reconnaît le déclencheur dans le champ de description, charge le Skill, se connecte à Linear et GitHub via MCP, et produit un rapport suivant mon format et mes règles de style exactement.
Pas d'ingénierie de prompts. Pas besoin de se rappeler où j'ai sauvegardé le modèle. Le savoir vit dans le Skill, et Claude sait quand y recourir.
Mais voici la partie que le guide enfouit dans un encadré alors qu'elle mérite d'être en page un : le champ de description dans votre frontmatter YAML est la ligne la plus importante que vous écrirez. Si vous la ratez, rien d'autre n'a d'importance.
Les deux lignes qui font ou défont votre Skill
J'ai perdu quatre heures là-dessus. Quatre heures à construire un Skill parfaitement détaillé que Claude n'a jamais déclenché. Les instructions étaient claires. Le format était précis. Les documents de référence étaient complets. Et chaque fois que je demandais à Claude de faire ce pour quoi le Skill avait été conçu, il... utilisait simplement ses connaissances générales. Ignorait le Skill complètement.
Le problème était mon champ de description.
Ma description originale disait : "Helps with code review processes." Six mots. Vagues. Passifs. Claude n'avait aucune idée de quand l'activer parce que "helps with code review processes" pouvait signifier littéralement n'importe quoi.
Je l'ai réécrite : "Performs structured code review on pull requests. Trigger when user shares a PR link, asks for code review, requests a PR review, or pastes a diff. Checks for security vulnerabilities, performance issues, naming conventions per team standards, and test coverage gaps."
A commencé à fonctionner immédiatement. À chaque fois.
Le pattern que j'ai découvert par essais et erreurs — et le guide le suggère mais ne le dit pas assez clairement — est que votre description a besoin de trois choses :
1. Ce qu'il fait (verbe actif, résultat spécifique) : "Generates weekly reports" pas "Helps with reporting."
2. Quand déclencher (phrases de déclenchement explicites) : "Trigger when user asks for X, Y, or Z." Listez les mots et phrases réels qu'un humain utiliserait. Ne soyez pas malin. Soyez littéral.
3. Ce qu'il couvre (limites du périmètre) : "Checks for A, B, C, and D." Cela indique à Claude ce qui est dans le domaine du Skill et, par implication, ce qui ne l'est pas.
Le champ name compte aussi — utilisez le kebab-case, sans espaces, et rendez-le descriptif. weekly-status-report bat report-v2 bat wsr. Claude utilise le nom comme un signal supplémentaire pour la correspondance, donc les noms descriptifs améliorent la précision du déclenchement.
Je suis revenu réécrire les descriptions de mes sept Skills. Six d'entre eux ont commencé à se déclencher correctement immédiatement. Le septième a nécessité une ronde supplémentaire d'affinage — il s'est avéré que mes phrases de déclenchement chevauchaient celles d'un autre Skill, et Claude se retrouvait confus sur lequel charger.
Ce qui m'amène à un problème que le guide n'aborde pas du tout : que se passe-t-il quand les Skills entrent en conflit. Plus à ce sujet dans un moment. D'abord, les trois cas d'usage pour lesquels Anthropic a conçu ce système — car comprendre les cas d'usage prévus change votre façon de penser la construction de Skills.
Trois cas d'usage — Et celui qu'Anthropic sous-estime
Le guide divise Claude Skills en trois applications principales. Chacune résout un problème véritablement différent, et les confondre est une erreur que j'ai commise au début.
Cas d'usage 1 : Création de documents
C'est l'application la plus directe. Vous avez un type spécifique de document — une présentation, une spécification technique, une proposition client, un brief de design — qui doit suivre des standards cohérents à chaque fois. Polices, structure, ton, sections obligatoires, expressions interdites. Au lieu de coller un guide de style dans chaque conversation, vous l'encodez une fois dans un Skill.
J'en ai construit un pour les propositions clients qui inclut nos niveaux de tarification, notre langage standard de périmètre, les mentions légales obligatoires et les règles de mise en forme. Ce qui me prenait auparavant 20 minutes de conception de prompts par proposition prend maintenant une phrase : "Rédige une proposition pour [client] couvrant [périmètre]." Le Skill s'occupe de tout le reste.
Cas d'usage 2 : Automatisation des workflows
C'est ici que les Skills commencent à faire gagner un temps sérieux. Des processus en plusieurs étapes qui doivent se dérouler de la même manière à chaque fois — planification de sprint, checklists de déploiement, séquences d'onboarding, procédures de réponse aux incidents.
Mon Skill de planification de sprint est celui dont je suis le plus fier. Il se connecte à Linear pour récupérer l'état actuel du projet, analyse notre vélocité sur les trois derniers sprints, identifie les éléments reportés qui continuent de glisser, suggère des priorités en fonction de la proximité des échéances et des chaînes de dépendances, et crée les tickets de sprint réels avec les points estimés. Un processus qui consommait 90 minutes de mon lundi matin se déroule maintenant en environ quatre minutes, avec moi qui révise et approuve le résultat plutôt que de le générer de zéro.
L'insight clé pour les Skills de workflow : vous devez être explicite sur l'ordre des opérations et la logique de décision à chaque étape. "Analyser la vélocité" est trop vague. "Calculer la moyenne des story points complétés par sprint sur les 3 derniers sprints, en excluant les sprints de moins de 8 jours. Si la vélocité est en baisse pendant 2+ sprints consécutifs, signaler cela dans le résultat de planification avec le pourcentage de baisse" — c'est ce dont Claude a besoin.
Cas d'usage 3 : Amélioration MCP
C'est le cas d'usage qui enthousiasme le plus Anthropic, et honnêtement, c'est celui dont je pense qu'ils sous-estiment le potentiel. L'amélioration MCP signifie superposer une expertise métier à l'accès aux outils. Votre Skill n'utilise pas seulement Figma — il connaît votre système de design, vos conventions de nommage de composants, vos exigences d'accessibilité et le workflow spécifique de livraison des designs à l'ingénierie.
J'ai construit un Skill de livraison design-vers-développement qui récupère les derniers designs de Figma, extrait les spécifications des composants, les mappe à notre bibliothèque existante de composants React, identifie les manques où de nouveaux composants sont nécessaires, crée des tickets Linear pour le travail d'ingénierie avec des critères d'acceptation tirés des spécifications de design, et publie un résumé dans notre canal de développement Slack.
Six outils différents. Un Skill. Une phrase de déclenchement : "Traite les nouveaux designs."
Voici ce qu'Anthropic sous-estime dans ce cas d'usage : la valeur composée. Chaque fois qu'un expert métier de votre équipe examine le résultat du Skill et dit "en fait, on doit aussi vérifier X avant la livraison", vous ajoutez cette vérification au fichier SKILL.md. Au fil des semaines et des mois, le Skill accumule du savoir institutionnel qui autrement ne vivrait que dans la tête des gens. Il devient un document vivant de comment votre équipe travaille réellement — pas comment les outils ont été conçus pour fonctionner, mais comment vos gens utilisent ces outils dans votre contexte spécifique.
Ce n'est pas de l'automatisation. C'est de la mémoire organisationnelle avec une capacité d'exécution. Et je ne pense pas que la plupart des équipes aient saisi à quel point c'est puissant.
Maintenant — les cinq patterns qui structurent réellement la façon dont vous construisez ces choses.
Cinq patterns qui couvrent 90% des Skills du monde réel
Le guide présente cinq "patterns éprouvés" pour structurer les Skills. Après avoir construit onze Skills sur trois projets, je dirais que ces patterns sont authentiques — ce ne sont pas des catégories marketing. Chacun résout un problème structurellement différent, et essayer de forcer un Skill dans le mauvais pattern crée des bugs subtils difficiles à diagnostiquer.
Pattern 1 : Workflow séquentiel
Les étapes se déroulent dans un ordre fixe. L'étape 2 dépend du résultat de l'étape 1. L'étape 3 dépend de l'étape 2. Pas de ramification, pas de conditions — juste un pipeline fiable.
Idéal pour : procédures de déploiement, checklists de conformité, séquences d'onboarding, scripts de migration de données.
Le détail clé que le guide réussit : numérotez vos étapes explicitement et incluez des critères de validation entre les étapes. "Avant de passer à l'étape 3, vérifier que l'étape 2 a produit [résultat spécifique]. Si non, réessayer l'étape 2 avec [approche alternative]."
Pattern 2 : Coordination Multi-MCP
Le workflow s'étend sur plusieurs services externes. Figma vers Linear vers Slack. GitHub vers Jira vers Confluence. Le Skill orchestre le flux de données entre des outils qui ne communiquent pas nativement entre eux.
Idéal pour : workflows inter-outils, livraisons de design, gestion des releases, notifications inter-équipes.
Mon plus grand apprentissage ici : incluez des instructions explicites de transformation de données entre les appels d'outils. Le format dans lequel Figma exporte les spécifications de composants n'est pas le format que Linear accepte pour les descriptions de tickets. Votre Skill doit spécifier exactement comment reformater les données lorsqu'elles circulent entre les outils.
Pattern 3 : Raffinement itératif
Générer un résultat, le valider contre des critères, l'améliorer, valider à nouveau. Le Skill inclut sa propre boucle qualité au lieu de produire un résultat en une seule passe.
Idéal pour : génération de rapports, création de contenu, revue de code quand vous voulez une couverture complète, tout résultat qui bénéficie de l'autocritique.
J'utilise ce pattern pour mon Skill de propositions clients. Premier brouillon, puis une passe de relecture vérifiant le jargon et l'ambiguïté, puis une passe finale de mise en forme. La différence de qualité entre une passe unique et le processus itératif est substantielle — facilement worth les 30 secondes supplémentaires de temps de traitement.
Pattern 4 : Sélection contextuelle
Même objectif, différents chemins d'exécution selon le contexte. Téléchargez un PNG et il utilise un workflow. Téléchargez un SVG et il en utilise un autre. Les petits fichiers sont traités en ligne ; les gros fichiers sont fragmentés.
Idéal pour : traitement de fichiers, génération de contenu dans différents formats, scripts de déploiement qui varient selon l'environnement.
Ce pattern est plus délicat qu'il n'y paraît. Votre SKILL.md a besoin d'une logique de branchement claire : "Si l'entrée est [type A], suivre les étapes 1-4. Si l'entrée est [type B], suivre les étapes 5-8." Des conditions de branchement ambiguës amènent Claude à choisir le mauvais chemin et produire un résultat correct pour le mauvais scénario — ce qui est plus difficile à repérer qu'une erreur évidente.
Pattern 5 : Intelligence de domaine
Le Skill incarne une expertise approfondie dans un domaine spécifique — règles de conformité financière, protocoles de sécurité, normes de codification médicale, critères de revue juridique. La valeur n'est pas dans le workflow ; elle est dans la connaissance elle-même.
Idéal pour : vérification de conformité, audits de sécurité, processus de revue spécialisés, toute tâche où "connaître les règles" est la partie difficile.
C'est le pattern où les documents de référence dans votre dossier de Skill prennent toute leur valeur. Un fichier SKILL.md pointant vers une checklist de conformité sécurité de 50 pages peut faire de Claude un auditeur de premier passage véritablement utile. Pas un remplacement de l'expertise humaine — mais un premier réviseur infatigable qui n'oublie jamais de vérifier le point 47 de la page 12.
Bien, voilà le framework. Maintenant, laissez-moi vous épargner les heures que j'ai perdues sur des erreurs dont le guide ne vous prévient pas.
Quatre erreurs que j'ai commises pour que vous n'ayez pas à les faire
Erreur 1 : Des descriptions vagues qui ne se déclenchent jamais.
Déjà couvert, mais ça mérite d'être répété car c'est le mode de défaillance numéro un. Si votre Skill ne s'active jamais, la description est presque toujours le problème. Écrivez des phrases de déclenchement qui correspondent aux mots exacts qu'un humain utiliserait. "Run my deployment checklist" pas "assist with deployment processes."
Erreur 2 : Des instructions noyées dans des murs de texte.
Mes premiers Skills étaient des romans. Des pages de contexte, d'informations de fond, de cas limites, de philosophie sur pourquoi nous faisons les choses d'une certaine manière. Claude les analysait, mais le rapport signal/bruit était terrible. Les instructions importantes se diluaient dans le texte explicatif.
Ce qui marche mieux : mettez les instructions critiques en premier. Placez les règles non négociables dans les 20 premières lignes. Utilisez les en-têtes agressivement. Réservez le contexte de fond pour un document de référence séparé dans le dossier que Claude peut consulter au besoin mais n'a pas à traiter à chaque invocation.
Erreur 3 : Absence de gestion d'erreurs pour les appels MCP.
Celle-ci m'a frappé fort. Mon Skill de planification de sprint fonctionnait parfaitement — jusqu'à ce que l'API de Linear renvoie une erreur de rate limit un lundi matin, et le Skill s'est simplement... arrêté. Pas de fallback. Pas de retry. Pas de dégradation gracieuse. Juste un Claude confus disant qu'il ne pouvait pas compléter la requête.
Votre Skill doit anticiper les défaillances d'outils. Ajoutez des instructions explicites : "Si l'appel à l'API Linear échoue, attendre 10 secondes et réessayer une fois. S'il échoue à nouveau, poursuivre avec les données en cache de la dernière exécution réussie et noter que les données peuvent être obsolètes." C'est de l'ingénierie de résilience basique, mais c'est facile à oublier quand on se concentre sur le chemin nominal.
Erreur 4 : Essayer d'en faire trop dans un seul Skill.
J'ai construit un Skill appelé "project-manager" qui essayait de gérer la planification de sprint, les rapports d'état, la génération de rétrospectives, le raffinement du backlog et les mises à jour aux stakeholders. C'était 400 lignes d'instructions couvrant cinq workflows distincts.
C'était terrible. Claude activait le bon Skill mais suivait le mauvais workflow à l'intérieur. Les phrases de déclenchement pour différentes sous-tâches se chevauchaient. Les instructions pour la planification de sprint contredisaient certaines des conventions utilisées dans la génération des rétrospectives.
Je l'ai divisé en cinq Skills séparés. Chacun est devenu plus simple, plus fiable et plus facile à maintenir. La surcharge d'avoir cinq dossiers au lieu d'un est négligeable. L'amélioration en précision et en cohérence a été spectaculaire.
Le principe sous-jacent : un Skill, un travail. Si vous écrivez "aussi" ou "en plus" dans votre SKILL.md, vous avez probablement besoin d'un second Skill.
L'insight qui change votre vision de l'IA au travail
Le guide se termine par une réflexion que j'ai failli survoler, mais c'est en réalité l'idée la plus importante des 32 pages.
La plupart des gens utilisent l'IA comme un assistant à usage général. Chaque conversation repart de zéro. Vous expliquez votre contexte, vos préférences, vos standards, vos outils, vos workflows — puis vous obtenez une réponse façonnée par toute cette explication. Demain, vous le refaites. Et encore. Et encore.
Claude Skills inverse ce modèle. Au lieu d'apporter le contexte à l'IA dans chaque conversation, vous intégrez le contexte dans l'environnement de l'IA de façon permanente. L'IA commence chaque conversation pertinente en connaissant déjà vos standards, déjà connectée à vos outils, comprenant déjà vos workflows.
Ce n'est pas une astuce de productivité. C'est un changement architectural dans la façon dont les humains et l'IA collaborent.
Quand je regarde les onze Skills que j'ai construits ces trois derniers jours, je regarde une version condensée de la façon dont mon équipe travaille. Nos standards de revue de code. Notre processus de déploiement. Notre style de communication client. Notre méthodologie de planification de sprint. Notre workflow de livraison de design. Le tout encodé, exécutable et s'améliorant chaque fois que quelqu'un dans l'équipe ajoute une ligne à un fichier SKILL.md.
Les organisations qui comprendront cela tôt — qui commenceront à construire des bibliothèques de Skills capturant leurs meilleures pratiques et leur savoir institutionnel — auront un avantage composé qui grandit chaque mois. Pas parce que l'IA est plus intelligente. Parce que l'IA les connaît mieux.
J'ai commencé cet article en parlant de la suppression de mes prompts sauvegardés. C'était le symptôme. Le vrai changement est plus profond. J'ai arrêté de penser à Claude comme un outil que j'instruis et j'ai commencé à penser à lui comme un membre de l'équipe que j'intègre. Le dossier Skills est le manuel d'intégration. Et tout comme l'intégration d'un humain, l'investissement initial d'écrire des instructions claires se rembourse chaque jour que cette personne — ou ce Skill — se présente et fait le travail sans qu'on le lui dise deux fois.
Anthropic a construit le framework. Les 32 pages présentent la mécanique. Mais la valeur n'est pas dans le framework — elle est dans ce que vous y mettez.
Alors voici ma question : quel est le workflow que vous répétez chaque semaine et que vous pourriez enseigner à Claude une fois pour ne plus jamais l'expliquer ? Commencez par là. Un dossier. Un SKILL.md. Une description qui se déclenche vraiment.
Tout le reste se construit à partir de ce premier Skill qui fonctionne.
Travaillons ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? J'adorerais vous aider.
- Fiverr (constructions personnalisées et intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
