Créateur de Skill

Ce skill fournit des conseils pour créer des skills efficaces.

À propos des Skills

Les skills sont des packages modulaires et autonomes qui étendent les capacités de Claude en fournissant des connaissances spécialisées, des workflows et des outils. Considérez-les comme des « guides d'intégration » pour des domaines ou tâches spécifiques—ils transforment Claude d'un agent généraliste en agent spécialisé équipé de connaissances procédurales qu'aucun modèle ne peut complètement posséder.

Ce que les Skills Fournissent

1. Workflows spécialisés - Procédures multi-étapes pour des domaines spécifiques
2. Intégrations d'outils - Instructions pour travailler avec des formats de fichiers ou APIs spécifiques
3. Expertise métier - Connaissances spécifiques à l'entreprise, schémas, logique métier
4. Ressources groupées - Scripts, références et assets pour les tâches complexes et répétitives

Principes Fondamentaux

La Concision est Clé

La context window est un bien public. Les skills partagent la context window avec tout ce dont Claude a besoin : prompt système, historique de conversation, métadonnées d'autres Skills, et la requête utilisateur réelle.

Hypothèse par défaut : Claude est déjà très intelligent. N'ajoutez que le contexte que Claude ne possède pas déjà. Remettez en question chaque information : « Claude a-t-il vraiment besoin de cette explication ? » et « Ce paragraphe justifie-t-il son coût en tokens ? »

Privilégiez les exemples concis aux explications verbeux.

Définir des Degrés de Liberté Appropriés

Adaptez le niveau de spécificité à la fragilité et à la variabilité de la tâche :

Liberté élevée (instructions textuelles) : À utiliser quand plusieurs approches sont valides, les décisions dépendent du contexte, ou des heuristiques guident l'approche.

Liberté moyenne (pseudocode ou scripts avec paramètres) : À utiliser quand un pattern préféré existe, une certaine variation est acceptable, ou la configuration affecte le comportement.

Liberté faible (scripts spécifiques, peu de paramètres) : À utiliser quand les opérations sont fragiles et sujettes à erreur, la cohérence est critique, ou une séquence spécifique doit être suivie.

Pensez à Claude en explorant un chemin : un pont étroit avec des falaises a besoin de garde-fous spécifiques (liberté faible), tandis qu'un champ ouvert permet beaucoup de routes (liberté élevée).

Anatomie d'un Skill

Chaque skill se compose d'un fichier SKILL.md requis et de ressources groupées optionnelles :

skill-name/
├── SKILL.md (requis)
│   ├── Métadonnées frontmatter YAML (requises)
│   │   ├── name: (requise)
│   │   ├── description: (requise)
│   │   └── compatibility: (optionnel, rarement nécessaire)
│   └── Instructions Markdown (requises)
└── Ressources Groupées (optionnel)
    ├── scripts/          - Code exécutable (Python/Bash/etc.)
    ├── references/       - Documentation destinée à être chargée en contexte au besoin
    └── assets/           - Fichiers utilisés en sortie (templates, icônes, polices, etc.)

SKILL.md (requis)

Chaque SKILL.md se compose de :

• Frontmatter (YAML) : Contient les champs name et description (requis), ainsi que des champs optionnels comme license, metadata, et compatibility. Seuls name et description sont lus par Claude pour déterminer quand le skill se déclenche, donc soyez clair et complet sur ce qu'est le skill et quand il doit être utilisé. Le champ compatibility sert à noter les exigences d'environnement (produit cible, packages système, etc.) mais la plupart des skills n'en ont pas besoin.
• Corps (Markdown) : Instructions et conseils pour utiliser le skill. Chargé uniquement APRÈS le déclenchement du skill (le cas échéant).

Ressources Groupées (optionnel)

Scripts (scripts/)

Code exécutable (Python/Bash/etc.) pour les tâches qui nécessitent une fiabilité déterministe ou sont régulièrement réécrites.

• Quand inclure : Quand le même code est régulièrement réécrit ou qu'une fiabilité déterministe est nécessaire
• Exemple : scripts/rotate_pdf.py pour les tâches de rotation PDF
• Avantages : Efficace en tokens, déterministe, peut être exécuté sans charger en contexte
• Remarque : Les scripts peuvent toujours avoir besoin d'être lus par Claude pour des correctifs ou des ajustements spécifiques à l'environnement

Références (references/)

Documentation et matériel de référence destinés à être chargés au besoin en contexte pour informer le processus et la réflexion de Claude.

• Quand inclure : Pour la documentation que Claude doit consulter pendant le travail
• Exemples : references/finance.md pour les schémas financiers, references/mnda.md pour le template NDA de l'entreprise, references/policies.md pour les politiques de l'entreprise, references/api_docs.md pour les spécifications API
• Cas d'usage : Schémas de base de données, documentation API, connaissances de domaine, politiques d'entreprise, guides de workflow détaillés
• Avantages : Garde SKILL.md léger, chargé uniquement quand Claude le juge nécessaire
• Bonne pratique : Si les fichiers sont volumineux (>10 000 mots), incluez des patterns de recherche grep dans SKILL.md
• Éviter la duplication : L'information doit résider soit dans SKILL.md, soit dans les fichiers de références, pas les deux. Privilégiez les fichiers de références pour les informations détaillées sauf si c'est vraiment essentiel au skill—cela garde SKILL.md léger tout en rendant l'information découvrable sans monopoliser la context window. Gardez uniquement les instructions procédurales essentielles et les conseils de workflow dans SKILL.md ; déplacez le matériel de référence détaillé, les schémas et les exemples vers les fichiers de références.

Assets (assets/)

Fichiers non destinés à être chargés en contexte, mais plutôt utilisés dans la sortie que Claude produit.

• Quand inclure : Quand le skill a besoin de fichiers qui seront utilisés dans la sortie finale
• Exemples : assets/logo.png pour les assets de marque, assets/slides.pptx pour les templates PowerPoint, assets/frontend-template/ pour les boilerplates HTML/React, assets/font.ttf pour la typographie
• Cas d'usage : Templates, images, icônes, code boilerplate, polices, documents d'exemple qui sont copiés ou modifiés
• Avantages : Sépare les ressources de sortie de la documentation, permet à Claude d'utiliser des fichiers sans les charger en contexte

Ce qu'il ne faut PAS Inclure dans un Skill

Un skill ne doit contenir que les fichiers essentiels qui soutiennent directement sa fonctionnalité. NE CRÉEZ PAS de documentation extraneous ou de fichiers auxiliaires, y compris :

• README.md
• INSTALLATION_GUIDE.md
• QUICK_REFERENCE.md
• CHANGELOG.md
• etc.

Le skill ne doit contenir que l'information nécessaire pour qu'une instance IA fasse le travail en question. Il ne doit pas contenir de contexte auxiliaire sur le processus de création, les procédures de configuration et test, la documentation destinée aux utilisateurs, etc. Créer des fichiers de documentation supplémentaires ajoute seulement du désordre et de la confusion.

Principe de Progressive Disclosure Design

Les skills utilisent un système de chargement à trois niveaux pour gérer le contexte efficacement :

1. Métadonnées (name + description) - Toujours en contexte (~100 mots)
2. Corps SKILL.md - Quand le skill se déclenche (<5 000 mots)
3. Ressources groupées - Au besoin par Claude (Illimité car les scripts peuvent être exécutés sans être lus en contexte)

Patterns de Progressive Disclosure

Gardez le corps SKILL.md à l'essentiel et moins de 500 lignes pour minimiser le bloat de contexte. Divisez le contenu en fichiers séparés quand vous vous rapprochez de cette limite. Quand vous divisez le contenu en d'autres fichiers, il est très important de les référencer à partir de SKILL.md et de décrire clairement quand les lire, pour assurer que le lecteur du skill sait qu'ils existent et quand les utiliser.

Principe clé : Quand un skill supporte plusieurs variantes, frameworks ou options, gardez uniquement le workflow core et les conseils de sélection dans SKILL.md. Déplacez les détails spécifiques à la variante (patterns, exemples, configuration) dans des fichiers de référence séparés.

Pattern 1 : Guide haut niveau avec références

# PDF Processing

## Quick start

Extract text with pdfplumber:
[code example]

## Advanced features

- **Form filling**: See [FORMS.md](FORMS.md) for complete guide
- **API reference**: See [REFERENCE.md](REFERENCE.md) for all methods
- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns

Claude charge FORMS.md, REFERENCE.md, ou EXAMPLES.md uniquement au besoin.

Pattern 2 : Organisation spécifique au domaine

Pour les Skills avec plusieurs domaines, organisez le contenu par domaine pour éviter de charger du contexte non pertinent :

bigquery-skill/
├── SKILL.md (overview and navigation)
└── reference/
    ├── finance.md (revenue, billing metrics)
    ├── sales.md (opportunities, pipeline)
    ├── product.md (API usage, features)
    └── marketing.md (campaigns, attribution)

Quand un utilisateur demande des métriques de ventes, Claude ne lit que sales.md.

De même, pour les skills supportant plusieurs frameworks ou variantes, organisez par variante :

cloud-deploy/
├── SKILL.md (workflow + provider selection)
└── references/
    ├── aws.md (AWS deployment patterns)
    ├── gcp.md (GCP deployment patterns)
    └── azure.md (Azure deployment patterns)

Quand l'utilisateur choisit AWS, Claude ne lit que aws.md.

Pattern 3 : Détails conditionnels

Montrez le contenu de base, liez vers le contenu avancé :

# DOCX Processing

## Creating documents

Use docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).

## Editing documents

For simple edits, modify the XML directly.

**For tracked changes**: See [REDLINING.md](REDLINING.md)
**For OOXML details**: See [OOXML.md](OOXML.md)

Claude lit REDLINING.md ou OOXML.md uniquement quand l'utilisateur a besoin de ces fonctionnalités.

Lignes directrices importantes :

• Éviter les références profondément imbriquées - Gardez les références à un niveau de profondeur de SKILL.md. Tous les fichiers de références doivent se lier directement depuis SKILL.md.
• Structurer les fichiers de référence plus longs - Pour les fichiers plus longs que 100 lignes, incluez une table des matières en haut pour que Claude puisse voir la portée complète quand il prévisualise.

Processus de Création de Skill

La création de skill implique ces étapes :

1. Comprendre le skill avec des exemples concrets
2. Planifier les contenus réutilisables du skill (scripts, références, assets)
3. Initialiser le skill (exécuter init_skill.py)
4. Éditer le skill (implémenter les ressources et écrire SKILL.md)
5. Empaqueter le skill (exécuter package_skill.py)
6. Itérer en fonction de l'utilisation réelle

Suivez ces étapes dans l'ordre, en les sautant uniquement s'il y a une raison claire pour laquelle elles ne sont pas applicables.

Étape 1 : Comprendre le Skill avec des Exemples Concrets

Ne sautez cette étape que si les patterns d'utilisation du skill sont déjà clairement compris. Elle reste utile même quand on travaille avec un skill existant.

Pour créer un skill efficace, comprenez clairement les exemples concrets de comment le skill sera utilisé. Cette compréhension peut venir soit d'exemples utilisateur directs, soit d'exemples générés qui sont validés avec les retours utilisateur.

Par exemple, quand on construit un skill d'image-editor, les questions pertinentes incluent :

• « Quelles fonctionnalités le skill image-editor devrait-il supporter ? Édition, rotation, autre chose ? »
• « Pouvez-vous donner des exemples de comment ce skill serait utilisé ? »
• « J'imagine que les utilisateurs pourraient demander des choses comme 'Supprime les yeux rouges de cette image' ou 'Fais pivoter cette image'. Y a-t-il d'autres façons dont vous imaginez que ce skill serait utilisé ? »
• « Que dirait un utilisateur qui devrait déclencher ce skill ? »

Pour ne pas surcharger les utilisateurs, évitez de poser trop de questions dans un seul message. Commencez par les questions les plus importantes et faites un suivi au besoin pour une meilleure efficacité.

Concluez cette étape quand vous avez une vision claire de la fonctionnalité que le skill devrait supporter.

Étape 2 : Planifier les Contenus Réutilisables du Skill

Pour transformer les exemples concrets en un skill efficace, analysez chaque exemple en :

1. Considérant comment exécuter l'exemple à partir de zéro
2. Identifiant quels scripts, références et assets seraient utiles quand on exécute ces workflows régulièrement

Exemple : Quand on construit un skill pdf-editor pour gérer des requêtes comme « Aide-moi à faire pivoter ce PDF », l'analyse montre :

1. Faire pivoter un PDF nécessite de réécrire le même code à chaque fois
2. Un script scripts/rotate_pdf.py serait utile à stocker dans le skill

Exemple : Quand on design un skill frontend-webapp-builder pour des requêtes comme « Construis-moi une app todo » ou « Construis-moi un dashboard pour tracker mes pas », l'analyse montre :

1. Écrire une webapp frontend nécessite le même boilerplate HTML/React à chaque fois
2. Un template assets/hello-world/ contenant les fichiers de projet boilerplate HTML/React serait utile à stocker dans le skill

Exemple : Quand on construit un skill big-query pour gérer des requêtes comme « Combien d'utilisateurs se sont connectés aujourd'hui ? », l'analyse montre :

1. Interroger BigQuery nécessite de redécouvrir les schémas de table et les relations à chaque fois
2. Un fichier references/schema.md documentant les schémas de table serait utile à stocker dans le skill

Pour établir les contenus du skill, analysez chaque exemple concret pour créer une liste des ressources réutilisables à inclure : scripts, références, et assets.

Étape 3 : Initialiser le Skill

À ce stade, il est temps de réellement créer le skill.

Ne sautez cette étape que si le skill en cours de développement existe déjà, et qu'une itération ou un empaquetage est nécessaire. Dans ce cas, continuez à l'étape suivante.

Quand on crée un nouveau skill à partir de zéro, exécutez toujours le script init_skill.py. Le script génère commodément un nouveau répertoire template skill qui inclut automatiquement tout ce qu'un skill nécessite, rendant le processus de création de skill beaucoup plus efficace et fiable.

Usage :

scripts/init_skill.py <skill-name> --path <output-directory>

Le script :

• Crée le répertoire du skill au chemin spécifié
• Génère un template SKILL.md avec le frontmatter approprié et des placeholders TODO
• Crée des répertoires de ressources d'exemple : scripts/, references/, et assets/
• Ajoute des fichiers d'exemple dans chaque répertoire qui peuvent être personnalisés ou supprimés

Après l'initialisation, personnalisez ou supprimez les fichiers SKILL.md et d'exemple générés au besoin.

Étape 4 : Éditer le Skill

Quand on édite le skill (nouvellement généré ou existant), rappelez-vous que le skill est créé pour qu'une autre instance de Claude l'utilise. Incluez les informations qui seraient bénéfiques et non-évidentes pour Claude. Considérez quelles connaissances procédurales, détails spécifiques au domaine, ou assets réutilisables aideraient une autre instance de Claude à exécuter ces tâches plus efficacement.

Apprendre les Design Patterns Éprouvés

Consultez ces guides utiles en fonction des besoins de votre skill :

• Processus multi-étapes : Voir references/workflows.md pour les workflows séquentiels et la logique conditionnelle
• Formats de sortie spécifiques ou standards de qualité : Voir references/output-patterns.md pour les patterns de template et d'exemples

Ces fichiers contiennent les bonnes pratiques établies pour une conception efficace de skill.

Commencer par les Contenus Réutilisables du Skill

Pour commencer l'implémentation, commencez par les ressources réutilisables identifiées ci-dessus : fichiers scripts/, references/, et assets/. Notez que cette étape peut nécessiter une contribution de l'utilisateur. Par exemple, quand on implémente un skill brand-guidelines, l'utilisateur peut avoir besoin de fournir des assets de marque ou des templates à stocker dans assets/, ou de la documentation à stocker dans references/.

Les scripts ajoutés doivent être testés en les exécutant réellement pour s'assurer qu'il n'y a pas de bugs et que la sortie correspond à ce qui est attendu. S'il y a beaucoup de scripts similaires, seul un échantillon représentatif doit être testé pour s'assurer que tous fonctionnent tout en équilibrant le temps d'exécution.

Tout fichier et répertoire d'exemple non nécessaire au skill doit être supprimé. Le script d'initialisation crée des fichiers d'exemple dans scripts/, references/, et assets/ pour démontrer la structure, mais la plupart des skills n'en auront pas besoin de tous.

Mettre à jour SKILL.md

Directives d'écriture : Utilisez toujours la forme impérative/infinitive.

Frontmatter

Écrivez le frontmatter YAML avec name et description :

• name : Le nom du skill
• description : C'est le mécanisme de déclenchement principal pour votre skill, et aide Claude à comprendre quand utiliser le skill.
  • Incluez à la fois ce que le Skill fait et les déclencheurs/contextes spécifiques pour quand l'utiliser.
  • Incluez toutes les informations « quand utiliser » ici - Pas dans le corps. Le corps n'est chargé qu'après le déclenchement, donc les sections « Quand Utiliser Ce Skill » dans le corps ne sont pas utiles pour Claude.
  • Exemple de description pour un skill docx : « Création, édition et analyse complète de documents avec support des modifications suivies, commentaires, préservation du formatage et extraction de texte. À utiliser quand Claude doit travailler avec des documents professionnels (fichiers .docx) pour : (1) Créer de nouveaux documents, (2) Modifier ou éditer du contenu, (3) Travailler avec des modifications suivies, (4) Ajouter des commentaires, ou toute autre tâche de document »

N'incluez aucun autre champ dans le frontmatter YAML.

Corps

Écrivez les instructions pour utiliser le skill et ses ressources groupées.

Étape 5 : Empaqueter un Skill

Une fois le développement du skill terminé, il doit être empaqueté dans un fichier .skill distribuable qui est partagé avec l'utilisateur. Le processus d'empaquetage valide automatiquement le skill d'abord pour s'assurer qu'il répond à tous les exigences :

scripts/package_skill.py <path/to/skill-folder>

Spécification optionnelle du répertoire de sortie :

scripts/package_skill.py <path/to/skill-folder> ./dist

Le script d'empaquetage va :

1. Valider le skill automatiquement, en vérifiant :

   • Format frontmatter YAML et champs requis
   • Conventions de nommage et structure de répertoire du skill
   • Complétude et qualité de la description
   • Organisation des fichiers et références aux ressources

2. Empaqueter le skill si la validation réussit, créant un fichier .skill nommé d'après le skill (ex. my-skill.skill) qui inclut tous les fichiers et maintient la structure de répertoire appropriée pour la distribution. Le fichier .skill est un fichier zip avec une extension .skill.

Si la validation échoue, le script rapportera les erreurs et quittera sans créer de package. Corrigez les erreurs de validation et exécutez la commande d'empaquetage à nouveau.

Étape 6 : Itérer

Après avoir testé le skill, les utilisateurs peuvent demander des améliorations. C'est souvent le cas juste après avoir utilisé le skill, avec un contexte frais de comment le skill a performé.

Workflow d'itération :

1. Utiliser le skill sur des tâches réelles
2. Remarquer les struggles ou inefficacités
3. Identifier comment SKILL.md ou les ressources groupées doivent être mises à jour
4. Implémenter les changements et tester à nouveau