Configuration et skills multi-fichiers

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Configurer les champs avancés du frontmatter : allowed-tools et model
• Écrire des descriptions efficaces qui se déclenchent sur les bonnes requêtes
• Utiliser allowed-tools pour restreindre les outils accessibles à Claude
• Organiser des skills complexes via le chargement progressif et les structures multi-fichiers

Les champs du frontmatter

Le standard ouvert des skills d’agent accepte plusieurs champs dans le frontmatter de SKILL.md. Deux sont obligatoires et vous les connaissez déjà, deux autres sont facultatifs et ouvrent des usages plus fins.

Écrire une description qui déclenche

Imaginez qu’on vous embauche en vous disant simplement « votre rôle est d’aider avec la doc ». Vous ne sauriez pas par où commencer, ni ce qui relève de vous. Claude réagit exactement de la même manière face à une description vague : il n’a aucun moyen de savoir dans quelles situations vous attendez son intervention.

Une description utile répond à deux questions, dans cet ordre : que fait le skill, et quand Claude doit-il l’utiliser ? Le second point est celui qu’on néglige. Si votre skill de profilage de performance reste muet alors que vous l’attendiez, relisez sa description en la comparant à la façon dont vous formulez réellement vos demandes, puis intégrez ces tournures. Un skill décrit uniquement comme « analyse les performances » ne reconnaîtra pas « pourquoi c’est lent ? » ; le même, enrichi de ces mots-clés, se déclenchera.

Restreindre les outils avec allowed-tools

Certains skills n’ont aucune raison de modifier votre code. Un skill d’accueil qui explique l’architecture d’une base de code à un nouveau développeur doit lire, chercher et parcourir — jamais écrire. Le champ allowed-tools transforme cette intention en garantie technique.

---
name: codebase-onboarding
description: Helps new developers understand how the system works.
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

Tant que ce skill est actif, Claude n’utilise sans demander la permission que les outils listés : ni édition, ni écriture. C’est précieux pour les workflows sensibles et les tâches en lecture seule, où une modification accidentelle coûterait cher. À l’inverse, si vous omettez allowed-tools, le skill ne restreint rien du tout et Claude conserve son modèle de permissions normal — l’absence du champ n’est donc pas une permission implicite, c’est le comportement par défaut.

Le chargement progressif

Les skills partagent la fenêtre de contexte avec votre conversation. Un skill de 2 000 lignes qui rassemble tout ce que vous savez d’un domaine pose deux problèmes simultanés : il occupe une part considérable de cette fenêtre dès qu’il s’active, et il devient pénible à maintenir. Le chargement progressif consiste à ne garder dans SKILL.md que les instructions essentielles, et à déporter le matériel de référence détaillé dans des fichiers séparés que Claude ne lira qu’en cas de besoin.

mon-skill/
  SKILL.md
  scripts/       # Code executable
  references/    # Documentation supplementaire
  assets/        # Images, templates, fichiers de données

Le lien entre les deux niveaux se fait par une instruction explicite dans SKILL.md, du type :

« Si l’utilisateur demande des détails sur l’architecture, lire references/architecture-guide.md. »

Claude ouvrira ce fichier le jour où la question sur l’architecture sera posée, et seulement ce jour-là. Vous avez ainsi une table des matières en permanence dans le contexte, plutôt que l’ouvrage complet. La règle pratique qui découle de ce raisonnement : gardez SKILL.md sous 500 lignes, et au-delà déplacez le contenu vers des fichiers de référence.

Faire travailler des scripts

Le répertoire scripts/ obéit à une économie encore plus favorable. Un script s’exécute sans que son contenu entre en contexte : seule sa sortie consomme des tokens. Tout repose alors sur une formulation précise dans votre SKILL.md, où vous devez dire à Claude d’exécuter le script et non de le lire — la nuance change tout au budget de contexte.

Ce mécanisme sert particulièrement trois familles de besoins : la validation d’environnement, les transformations de données qui doivent produire un résultat rigoureusement cohérent d’une exécution à l’autre, et plus généralement toute opération plus fiable sous forme de code testé que de code généré à la volée. Pensez à un skill que vous aimeriez construire et demandez-vous ce qui relève du SKILL.md, des références et des scripts. Puis repérez, dans les workflows de votre équipe, ceux où allowed-tools ajouterait une couche de sécurité qui vous manque aujourd’hui.