Maîtriser
les Skills Office

Chaque Skill repose sur un fichier SKILL.md structuré en deux parties :
Le frontmatter (en-tête YAML entre ---) : contient les métadonnées — name, description, trigger (quand la Skill se déclenche automatiquement) et allowed-tools (outils accessibles).
Le corps : les instructions en langage naturel que Claude exécutera.
Exemple de frontmatter :
---
name: audit-budget
description: Audits Excel budget files for hardcodes and formula errors. Use when working with .xlsx budget files.
trigger: when the user asks to audit a budget or mentions budget review
---

Le champ trigger du frontmatter permet à Claude de déclencher automatiquement la Skill quand certaines conditions sont remplies — sans que l'utilisateur tape /.
Exemples : "when the user mentions cleaning data", "when an Excel file with sales data is opened".
Un trigger bien rédigé réduit les frictions : les utilisateurs n'ont même pas besoin de connaître le nom de la Skill.

La technique de progressive disclosure consiste à structurer les instructions de la Skill en couches : les instructions essentielles en premier, les détails avancés ensuite. Claude ne lit les couches profondes que lorsqu'elles deviennent pertinentes. Cela réduit le coût en tokens et évite de surcharger le contexte pour les cas simples.

Le contexte est une ressource partagée. Anthropic recommande de garder le corps du fichier SKILL.md sous 500 lignes et de déporter les contenus longs (API, exemples, données de référence) dans des fichiers séparés chargés à la demande. Claude ne les lit que lorsqu'ils deviennent pertinents — zéro coût en tokens jusqu'à ce moment-là.

La documentation distingue trois niveaux selon le risque d'erreur :
Haute liberté → instructions textuelles générales (plusieurs approches valides)
Liberté moyenne → pseudo-code ou scripts paramétrés (préférence sans rigidité)
Faible liberté → script exact à exécuter tel quel (opération fragile, séquence critique)
Analogie : pont étroit avec falaises = instructions précises ; champ ouvert = direction générale.

Une Skill efficace sur un modèle puissant (Claude Opus ou Sonnet) peut être insuffisante sur un modèle plus léger (Haiku) qui a besoin de plus de contexte, et sur-explicative sur Opus qui sait déjà. Tester systématiquement avec chaque modèle prévu en production avant de déployer. Les derniers modèles sont la famille Claude 5 (Opus 5, Sonnet 5) et Haiku 4.5.

Anthropic recommande la forme gérondive pour les noms de Skills : analyzing-spreadsheets, processing-pdfs, generating-reports.
Règles techniques : minuscules, chiffres et tirets uniquement · max 64 caractères · pas de mots réservés (anthropic, claude) · pas de balises XML.
Éviter les noms vagues : helper, utils, data.

La description est injectée dans le system prompt de Claude. Elle doit décrire ce que fait la Skill et quand l'utiliser, toujours à la 3e personne.
✓ "Analyzes Excel spreadsheets and generates pivot reports. Use when working with .xlsx files."
✗ "Je peux vous aider à analyser vos fichiers Excel."
Une description vague ("Helps with documents") empêche Claude de sélectionner la bonne Skill parmi 100+ disponibles.

Au-delà du partage manuel (copier-coller du prompt), Anthropic propose un mécanisme de plugins pour distribuer des Skills à grande échelle. Un plugin regroupe plusieurs Skills et peut être installé en un clic par les membres de l'équipe. En contexte Enterprise, les plugins sont déployables de façon centralisée via la console d'administration.

Pour les opérations critiques ou en lot (remplir un formulaire, migrer des données, modifier en masse), prévoir un cycle faire → valider → corriger → répéter. Exemple : générer un plan JSON → le valider avec un script → appliquer les changements → vérifier le résultat. Ce pattern intercepte les erreurs avant qu'elles ne se propagent.

La documentation recommande un double rôle :
Claude A (expert) → aide à rédiger et améliorer la Skill
Claude B (agent) → instance fraîche qui utilise la Skill sur de vraies tâches
Observer comment Claude B navigue dans la Skill révèle les angles morts que l'auteur ne voit pas. Répéter le cycle observer → affiner → tester jusqu'à stabilisation.