Principes fondamentaux
La concision est essentielle
La fenêtre de contexte est un bien public. Votre Skill partage la fenêtre de contexte avec tout ce que Claude doit savoir, notamment :- L’invite système
- L’historique de la conversation
- Les métadonnées d’autres Skills
- Votre demande réelle
- « Claude a-t-il vraiment besoin de cette explication ? »
- « Puis-je supposer que Claude le sait ? »
- « Ce paragraphe justifie-t-il son coût en tokens ? »
Définir des degrés de liberté appropriés
Adaptez le niveau de spécificité à la fragilité et à la variabilité de la tâche. Haute liberté (instructions basées sur du texte) : À utiliser quand :- Plusieurs approches sont valides
- Les décisions dépendent du contexte
- Les heuristiques guident l’approche
- Un modèle préféré existe
- Une certaine variation est acceptable
- La configuration affecte le comportement
- Les opérations sont fragiles et sujettes aux erreurs
- La cohérence est critique
- Une séquence spécifique doit être suivie
- Pont étroit avec des falaises de chaque côté : Il n’y a qu’une seule voie sûre. Fournissez des garde-fous spécifiques et des instructions exactes (basse liberté). Exemple : les migrations de base de données qui doivent s’exécuter dans une séquence exacte.
- Champ ouvert sans dangers : De nombreux chemins mènent au succès. Donnez une direction générale et faites confiance à Claude pour trouver la meilleure route (haute liberté). Exemple : les examens de code où le contexte détermine la meilleure approche.
Tester avec tous les modèles que vous prévoyez d’utiliser
Les Skills agissent comme des additions aux modèles, donc l’efficacité dépend du modèle sous-jacent. Testez votre Skill avec tous les modèles que vous prévoyez d’utiliser. Considérations de test par modèle :- Claude Haiku (rapide, économique) : Le Skill fournit-il suffisamment de conseils ?
- Claude Sonnet (équilibré) : Le Skill est-il clair et efficace ?
- Claude Opus (raisonnement puissant) : Le Skill évite-t-il les sur-explications ?
Structure du Skill
Frontmatter YAML : Le frontmatter SKILL.md nécessite deux champs :
name :- Maximum 64 caractères
- Doit contenir uniquement des lettres minuscules, des chiffres et des tirets
- Ne peut pas contenir de balises XML
- Ne peut pas contenir de mots réservés : « anthropic », « claude »
description :- Doit être non vide
- Maximum 1024 caractères
- Ne peut pas contenir de balises XML
- Doit décrire ce que fait le Skill et quand l’utiliser
Conventions de nommage
Utilisez des modèles de nommage cohérents pour faciliter la référence et la discussion des Skills. Nous recommandons d’utiliser la forme gérondive (verbe + -ing) pour les noms de Skills, car cela décrit clairement l’activité ou la capacité que le Skill fournit. N’oubliez pas que le champname doit utiliser uniquement des lettres minuscules, des chiffres et des tirets.
Bons exemples de nommage (forme gérondive) :
processing-pdfsanalyzing-spreadsheetsmanaging-databasestesting-codewriting-documentation
- Syntagmes nominaux :
pdf-processing,spreadsheet-analysis - Orientés vers l’action :
process-pdfs,analyze-spreadsheets
- Noms vagues :
helper,utils,tools - Trop génériques :
documents,data,files - Mots réservés :
anthropic-helper,claude-tools - Modèles incohérents dans votre collection de skills
- La référence aux Skills dans la documentation et les conversations
- La compréhension de ce qu’un Skill fait en un coup d’œil
- L’organisation et la recherche dans plusieurs Skills
- La maintenance d’une bibliothèque de skills professionnelle et cohésive
Rédiger des descriptions efficaces
Le champdescription permet la découverte du Skill et doit inclure à la fois ce que fait le Skill et quand l’utiliser.
Écrivez toujours à la troisième personne. La description est injectée dans l’invite système, et une perspective incohérente peut causer des problèmes de découverte.
- Bon : « Traite les fichiers Excel et génère des rapports »
- À éviter : « Je peux vous aider à traiter les fichiers Excel »
- À éviter : « Vous pouvez utiliser ceci pour traiter les fichiers Excel »
Modèles de divulgation progressive
SKILL.md sert de présentation qui pointe Claude vers des matériaux détaillés selon les besoins, comme une table des matières dans un guide d’intégration. Pour une explication du fonctionnement de la divulgation progressive, consultez Comment fonctionnent les Skills dans la présentation. Conseils pratiques :- Gardez le corps de SKILL.md sous 500 lignes pour des performances optimales
- Divisez le contenu en fichiers séparés lorsque vous approchez cette limite
- Utilisez les modèles ci-dessous pour organiser efficacement les instructions, le code et les ressources
Aperçu visuel : Du simple au complexe
Un Skill basique commence par un seul fichier SKILL.md contenant les métadonnées et les instructions :

Modèle 1 : Guide de haut niveau avec références
Modèle 2 : Organisation spécifique au domaine
Pour les Skills avec plusieurs domaines, organisez le contenu par domaine pour éviter de charger un contexte non pertinent. Lorsqu’un utilisateur demande des métriques de ventes, Claude n’a besoin de lire que les schémas liés aux ventes, pas les données financières ou marketing. Cela maintient l’utilisation des tokens faible et le contexte concentré.SKILL.md
Modèle 3 : Détails conditionnels
Montrez le contenu de base, liez au contenu avancé :Éviter les références profondément imbriquées
Claude peut lire partiellement les fichiers lorsqu’ils sont référencés à partir d’autres fichiers référencés. Lorsqu’il rencontre des références imbriquées, Claude pourrait utiliser des commandes commehead -100 pour prévisualiser le contenu plutôt que de lire des fichiers entiers, ce qui entraîne des informations incomplètes.
Gardez les références à un niveau de profondeur à partir de SKILL.md. Tous les fichiers de référence doivent être liés directement à partir de SKILL.md pour assurer que Claude lit les fichiers complets si nécessaire.
Mauvais exemple : Trop profond :
Structurer les fichiers de référence plus longs avec une table des matières
Pour les fichiers de référence de plus de 100 lignes, incluez une table des matières en haut. Cela assure que Claude peut voir l’étendue complète des informations disponibles même lors de la prévisualisation avec des lectures partielles. Exemple :Flux de travail et boucles de rétroaction
Utiliser les flux de travail pour les tâches complexes
Divisez les opérations complexes en étapes claires et séquentielles. Pour les flux de travail particulièrement complexes, fournissez une liste de contrôle que Claude peut copier dans sa réponse et cocher au fur et à mesure de sa progression. Exemple 1 : Flux de travail de synthèse de recherche (pour les Skills sans code) :Implémenter des boucles de rétroaction
Modèle courant : Exécuter le validateur → corriger les erreurs → répéter Ce modèle améliore considérablement la qualité de la sortie. Exemple 1 : Conformité au guide de style (pour les Skills sans code) :Directives de contenu
Éviter les informations sensibles au temps
N’incluez pas d’informations qui deviendront obsolètes : Mauvais exemple : Sensible au temps (deviendra incorrect) :Utiliser une terminologie cohérente
Choisissez un terme et utilisez-le dans tout le Skill : Bon - Cohérent :- Toujours « point de terminaison API »
- Toujours « champ »
- Toujours « extraire »
- Mélanger « point de terminaison API », « URL », « route API », « chemin »
- Mélanger « champ », « boîte », « élément », « contrôle »
- Mélanger « extraire », « tirer », « obtenir », « récupérer »
Modèles courants
Modèle de modèle
Fournissez des modèles pour le format de sortie. Adaptez le niveau de rigueur à vos besoins. Pour les exigences strictes (comme les réponses API ou les formats de données) :Modèle d’exemples
Pour les Skills où la qualité de la sortie dépend de la visualisation d’exemples, fournissez des paires entrée/sortie tout comme dans les invites régulières :Modèle de flux de travail conditionnel
Guidez Claude à travers les points de décision :Si les flux de travail deviennent volumineux ou compliqués avec de nombreuses étapes, envisagez de les placer dans des fichiers séparés et dites à Claude de lire le fichier approprié en fonction de la tâche à accomplir.
Évaluation et itération
Construire les évaluations en premier
Créez les évaluations AVANT de rédiger une documentation extensive. Cela assure que votre Skill résout des problèmes réels plutôt que de documenter des problèmes imaginaires. Développement piloté par l’évaluation :- Identifier les lacunes : Exécutez Claude sur des tâches représentatives sans Skill. Documentez les défaillances spécifiques ou le contexte manquant
- Créer des évaluations : Construisez trois scénarios qui testent ces lacunes
- Établir une ligne de base : Mesurez les performances de Claude sans le Skill
- Rédiger des instructions minimales : Créez juste assez de contenu pour combler les lacunes et réussir les évaluations
- Itérer : Exécutez les évaluations, comparez par rapport à la ligne de base et affinez
Cet exemple démontre une évaluation pilotée par les données avec une rubrique de test simple. Nous ne fournissons actuellement pas de moyen intégré d’exécuter ces évaluations. Les utilisateurs peuvent créer leur propre système d’évaluation. Les évaluations sont votre source de vérité pour mesurer l’efficacité du Skill.
Développer les Skills de manière itérative avec Claude
Le processus de développement de Skill le plus efficace implique Claude lui-même. Travaillez avec une instance de Claude (« Claude A ») pour créer un Skill qui sera utilisé par d’autres instances (« Claude B »). Claude A vous aide à concevoir et affiner les instructions, tandis que Claude B les teste dans des tâches réelles. Cela fonctionne parce que les modèles Claude comprennent à la fois comment rédiger des instructions d’agent efficaces et quelles informations les agents ont besoin. Créer un nouveau Skill :- Complétez une tâche sans Skill : Travaillez sur un problème avec Claude A en utilisant des invites normales. Au fur et à mesure, vous fournirez naturellement du contexte, expliquerez les préférences et partagerez des connaissances procédurales. Remarquez quelles informations vous fournissez à plusieurs reprises.
- Identifiez le modèle réutilisable : Après avoir complété la tâche, identifiez le contexte que vous avez fourni qui serait utile pour des tâches futures similaires. Exemple : Si vous avez travaillé sur une analyse BigQuery, vous auriez pu fournir les noms de tables, les définitions de champs, les règles de filtrage (comme « toujours exclure les comptes de test ») et les modèles de requête courants.
-
Demandez à Claude A de créer un Skill : « Créez un Skill qui capture ce modèle d’analyse BigQuery que nous venons d’utiliser. Incluez les schémas de table, les conventions de nommage et la règle concernant le filtrage des comptes de test. »
Les modèles Claude comprennent le format et la structure du Skill de manière native. Vous n’avez pas besoin d’invites système spéciales ou d’un « skill de rédaction de skills » pour que Claude crée des Skills. Demandez simplement à Claude de créer un Skill et il générera un contenu SKILL.md correctement structuré avec un frontmatter et un contenu appropriés.
- Examinez la concision : Vérifiez que Claude A n’a pas ajouté d’explications inutiles. Demandez : « Supprimez l’explication sur ce que signifie le taux de victoire - Claude le sait déjà. »
- Améliorez l’architecture de l’information : Demandez à Claude A d’organiser le contenu plus efficacement. Par exemple : « Organisez ceci pour que le schéma de table soit dans un fichier de référence séparé. Nous pourrions ajouter plus de tables plus tard. »
- Testez sur des tâches similaires : Utilisez le Skill avec Claude B (une nouvelle instance avec le Skill chargé) sur des cas d’utilisation connexes. Observez si Claude B trouve les bonnes informations, applique les règles correctement et gère la tâche avec succès.
- Itérez en fonction de l’observation : Si Claude B a du mal ou omet quelque chose, retournez à Claude A avec des détails : « Lorsque Claude a utilisé ce Skill, il a oublié de filtrer par date pour le Q4. Devrions-nous ajouter une section sur les modèles de filtrage par date ? »
- Travailler avec Claude A (l’expert qui aide à affiner le Skill)
- Tester avec Claude B (l’agent utilisant le Skill pour effectuer un travail réel)
- Observer le comportement de Claude B et apporter des insights à Claude A
- Utilisez le Skill dans les flux de travail réels : Donnez à Claude B (avec le Skill chargé) des tâches réelles, pas des scénarios de test
- Observez le comportement de Claude B : Notez où il a du mal, réussit ou fait des choix inattendus Exemple d’observation : « Lorsque j’ai demandé à Claude B un rapport de ventes régional, il a écrit la requête mais a oublié de filtrer les comptes de test, même si le Skill mentionne cette règle. »
- Retournez à Claude A pour les améliorations : Partagez le SKILL.md actuel et décrivez ce que vous avez observé. Demandez : « J’ai remarqué que Claude B a oublié de filtrer les comptes de test lorsque j’ai demandé un rapport régional. Le Skill mentionne le filtrage, mais peut-être que ce n’est pas assez en évidence ? »
- Examinez les suggestions de Claude A : Claude A pourrait suggérer de réorganiser pour rendre les règles plus évidentes, d’utiliser un langage plus fort comme « DOIT filtrer » au lieu de « toujours filtrer », ou de restructurer la section du flux de travail.
- Appliquez et testez les modifications : Mettez à jour le Skill avec les raffinements de Claude A, puis testez à nouveau avec Claude B sur des demandes similaires
- Répétez en fonction de l’utilisation : Continuez ce cycle d’observation-raffinement-test à mesure que vous rencontrez de nouveaux scénarios. Chaque itération améliore le Skill en fonction du comportement réel de l’agent, pas des hypothèses.
- Partagez les Skills avec les coéquipiers et observez leur utilisation
- Demandez : Le Skill s’active-t-il comme prévu ? Les instructions sont-elles claires ? Qu’est-ce qui manque ?
- Incorporez les commentaires pour résoudre les points aveugles dans vos propres modèles d’utilisation
Observez comment Claude navigue dans les Skills
À mesure que vous itérez sur les Skills, prêtez attention à la façon dont Claude les utilise réellement en pratique. Observez :- Chemins d’exploration inattendus : Claude lit-il les fichiers dans un ordre que vous n’aviez pas anticipé ? Cela pourrait indiquer que votre structure n’est pas aussi intuitive que vous le pensiez
- Connexions manquées : Claude échoue-t-il à suivre les références vers des fichiers importants ? Vos liens pourraient avoir besoin d’être plus explicites ou en évidence
- Surreliance sur certaines sections : Si Claude lit à plusieurs reprises le même fichier, envisagez si ce contenu devrait être dans le SKILL.md principal à la place
- Contenu ignoré : Si Claude n’accède jamais à un fichier regroupé, il pourrait être inutile ou mal signalé dans les instructions principales
Anti-modèles à éviter
Éviter les chemins de style Windows
Utilisez toujours des barres obliques dans les chemins de fichiers, même sous Windows :- ✓ Bon :
scripts/helper.py,reference/guide.md - ✗ À éviter :
scripts\helper.py,reference\guide.md
Éviter d’offrir trop d’options
Ne présentez plusieurs approches que si nécessaire :Avancé : Skills avec code exécutable
Les sections ci-dessous se concentrent sur les Skills qui incluent des scripts exécutables. Si votre Skill utilise uniquement des instructions markdown, passez à Liste de contrôle pour les Skills efficaces.Résoudre, ne pas esquiver
Lors de la rédaction de scripts pour les Skills, gérez les conditions d’erreur plutôt que de les esquiver vers Claude. Bon exemple : Gérer les erreurs explicitement :Fournir des scripts utilitaires
Même si Claude pourrait écrire un script, les scripts pré-faits offrent des avantages : Avantages des scripts utilitaires :- Plus fiables que le code généré
- Économiser les tokens (pas besoin d’inclure le code dans le contexte)
- Économiser du temps (pas de génération de code requise)
- Assurer la cohérence entre les utilisations

- Exécuter le script (plus courant) : « Exécutez
analyze_form.pypour extraire les champs » - Le lire comme référence (pour la logique complexe) : « Consultez
analyze_form.pypour l’algorithme d’extraction de champs »
Utiliser l’analyse visuelle
Lorsque les entrées peuvent être rendues sous forme d’images, demandez à Claude de les analyser :Dans cet exemple, vous devriez écrire le script
pdf_to_images.py.Créer des sorties intermédiaires vérifiables
Lorsque Claude effectue des tâches complexes et ouvertes, il peut faire des erreurs. Le modèle « plan-valider-exécuter » détecte les erreurs tôt en demandant à Claude de d’abord créer un plan dans un format structuré, puis de valider ce plan avec un script avant de l’exécuter. Exemple : Imaginez demander à Claude de mettre à jour 50 champs de formulaire dans un PDF en fonction d’une feuille de calcul. Sans validation, Claude pourrait référencer des champs inexistants, créer des valeurs conflictuelles, manquer les champs requis ou appliquer les mises à jour incorrectement. Solution : Utilisez le modèle de flux de travail montré ci-dessus (remplissage de formulaire PDF), mais ajoutez un fichier intermédiairechanges.json qui est validé avant d’appliquer les modifications. Le flux de travail devient : analyser → créer un fichier de plan → valider le plan → exécuter → vérifier.
Pourquoi ce modèle fonctionne :
- Détecte les erreurs tôt : La validation trouve les problèmes avant que les modifications ne soient appliquées
- Vérifiable par machine : Les scripts fournissent une vérification objective
- Planification réversible : Claude peut itérer sur le plan sans toucher aux originaux
- Débogage clair : Les messages d’erreur pointent vers des problèmes spécifiques
Dépendances de package
Les Skills s’exécutent dans l’environnement d’exécution du code avec des limitations spécifiques à la plate-forme :- claude.ai : Peut installer des packages à partir de npm et PyPI et extraire des référentiels GitHub
- API Anthropic : N’a pas d’accès réseau et pas d’installation de package d’exécution
Environnement d’exécution
Les Skills s’exécutent dans un environnement d’exécution du code avec accès au système de fichiers, commandes bash et capacités d’exécution du code. Pour l’explication conceptuelle de cette architecture, consultez L’architecture des Skills dans la présentation. Comment cela affecte votre rédaction : Comment Claude accède aux Skills :- Métadonnées pré-chargées : Au démarrage, le nom et la description du frontmatter YAML de tous les Skills sont chargés dans l’invite système
- Fichiers lus à la demande : Claude utilise les outils de lecture bash pour accéder à SKILL.md et à d’autres fichiers du système de fichiers si nécessaire
- Scripts exécutés efficacement : Les scripts utilitaires peuvent être exécutés via bash sans charger leur contenu complet dans le contexte. Seule la sortie du script consomme des tokens
- Pas de pénalité de contexte pour les fichiers volumineux : Les fichiers de référence, les données ou la documentation ne consomment pas de tokens de contexte jusqu’à ce qu’ils soient réellement lus
- Les chemins de fichiers sont importants : Claude navigue dans votre répertoire de skills comme un système de fichiers. Utilisez des barres obliques (
reference/guide.md), pas des barres obliques inverses - Nommez les fichiers de manière descriptive : Utilisez des noms qui indiquent le contenu :
form_validation_rules.md, pasdoc2.md - Organisez pour la découverte : Structurez les répertoires par domaine ou fonctionnalité
- Bon :
reference/finance.md,reference/sales.md - Mauvais :
docs/file1.md,docs/file2.md
- Bon :
- Regroupez les ressources complètes : Incluez la documentation API complète, des exemples étendus, de grands ensembles de données ; pas de pénalité de contexte jusqu’à l’accès
- Préférez les scripts pour les opérations déterministes : Écrivez
validate_form.pyplutôt que de demander à Claude de générer du code de validation - Clarifiez l’intention d’exécution :
- « Exécutez
analyze_form.pypour extraire les champs » (exécuter) - « Consultez
analyze_form.pypour l’algorithme d’extraction » (lire comme référence)
- « Exécutez
- Testez les modèles d’accès aux fichiers : Vérifiez que Claude peut naviguer dans votre structure de répertoire en testant avec des demandes réelles
reference/finance.md, et invoque bash pour lire uniquement ce fichier. Les fichiers sales.md et product.md restent sur le système de fichiers, consommant zéro tokens de contexte jusqu’à ce qu’ils soient nécessaires. Ce modèle basé sur le système de fichiers est ce qui permet la divulgation progressive. Claude peut naviguer et charger sélectivement exactement ce que chaque tâche nécessite.
Pour les détails techniques complets sur l’architecture, consultez Comment fonctionnent les Skills dans la présentation des Skills.
Références d’outils MCP
Si votre Skill utilise des outils MCP (Model Context Protocol), utilisez toujours les noms d’outils complètement qualifiés pour éviter les erreurs « outil non trouvé ». Format :ServerName:tool_name
Exemple :
BigQueryetGitHubsont les noms des serveurs MCPbigquery_schemaetcreate_issuesont les noms des outils dans ces serveurs
Éviter de supposer que les outils sont installés
Ne supposez pas que les packages sont disponibles :Notes techniques
Exigences du frontmatter YAML
Le frontmatter SKILL.md nécessite les champsname et description avec des règles de validation spécifiques :
name: Maximum 64 caractères, lettres minuscules/chiffres/tirets uniquement, pas de balises XML, pas de mots réservésdescription: Maximum 1024 caractères, non vide, pas de balises XML
Budgets de tokens
Gardez le corps de SKILL.md sous 500 lignes pour des performances optimales. Si votre contenu dépasse cela, divisez-le en fichiers séparés en utilisant les modèles de divulgation progressive décrits précédemment. Pour les détails architecturaux, consultez la présentation des Skills.Liste de contrôle pour les Skills efficaces
Avant de partager un Skill, vérifiez :Qualité de base
- La description est spécifique et inclut les termes clés
- La description inclut à la fois ce que fait le Skill et quand l’utiliser
- Le corps de SKILL.md est sous 500 lignes
- Les détails supplémentaires sont dans des fichiers séparés (si nécessaire)
- Pas d’informations sensibles au temps (ou dans la section « anciens modèles »)
- Terminologie cohérente dans tout le document
- Les exemples sont concrets, pas abstraits
- Les références de fichiers sont à un niveau de profondeur
- La divulgation progressive est utilisée de manière appropriée
- Les flux de travail ont des étapes claires
Code et scripts
- Les scripts résolvent les problèmes plutôt que de les esquiver vers Claude
- La gestion des erreurs est explicite et utile
- Pas de « constantes vaudou » (toutes les valeurs justifiées)
- Les packages requis sont listés dans les instructions et vérifiés comme disponibles
- Les scripts ont une documentation claire
- Pas de chemins de style Windows (toutes les barres obliques)
- Les étapes de validation/vérification pour les opérations critiques
- Les boucles de rétroaction incluses pour les tâches critiques pour la qualité
Test
- Au moins trois évaluations créées
- Testé avec Haiku, Sonnet et Opus
- Testé avec des scénarios d’utilisation réels
- Les commentaires de l’équipe incorporés (le cas échéant)
Prochaines étapes
Commencer avec les Agent Skills
Créez votre premier Skill
Utiliser les Skills dans Claude Code
Créer et gérer les Skills dans Claude Code
Utiliser les Skills dans l'Agent SDK
Utiliser les Skills de manière programmatique en TypeScript et Python
Utiliser les Skills avec l'API
Télécharger et utiliser les Skills de manière programmatique