Skills Claude Code : conserver les capacités sans gonfler le contexte
Audit pratique des skills Claude Code : distinguer règles permanentes et ressources à la demande, préciser les triggers et vérifier la découverte.
Sommaire
Scripts, règles de formatage et modèles s’accumulent vite. Si chaque aide devient une instruction permanente, la session consomme du contexte avant la première demande utile. Voici comment inventorier les skills, séparer les règles persistantes et tester leur découverte.
Ce qui entre dans le contexte
Avec on, Claude Code reçoit le nom et la description; name-only ne garde que le nom. user-invocable-only et disable-model-invocation: true cachent la description au modèle, tandis que off cache le skill. Le corps de SKILL.md ne se charge qu’à l’appel et reste dans la session; les références sont lues au besoin et les scripts s’exécutent comme outils. Consultez la documentation officielle.
Séparez l’annonce de la liste, le corps chargé et les ressources à la demande. Ne placez pas de longues références dans description ou CLAUDE.md.
Avec votre clé BetterToken, le Dashboard permet de comparer modèle, heure, statut, input, output et cache tokens pour des essais API; il ne mesure pas le contexte local et ne remplace pas /context. Consultez les BetterToken Docs.
Commencer avec /skill-doctor
Exécutez /skill-doctor localement. Les Stats de /plugin présentent coût de contexte et fréquence d’appel, y compris les skills chargés mais inutilisés, hors skills intégrés et entreprise. Consultez la description du rapport. Comparez la liste aux tâches habituelles : l’absence d’appels ne prouve pas qu’un skill est inutile, notamment pour une procédure de récupération rare. Pour un skill personnel ou de projet occasionnel, choisissez user-invocable-only dans /skills (affiché user-only). Réservez off aux skills devenus inutiles dans cet environnement. Gérez les skills de plugins via /plugin. Ouvrez une nouvelle session et comparez /context, une tâche habituelle et un appel explicite au skill conservé. Les notes de version v2.1.261 mentionnent cette commande ; la documentation actuelle indique v2.1.252 au minimum. Vérifiez claude --version et les feature flags; Remote Control ne fournit pas ce rapport : utilisez le terminal de la machine qui héberge la session. Si la commande manque, poursuivez l’inventaire manuel.
Comparez .claude/skills/ et ~/.claude/skills/ avec /skills dans chaque environnement. Un skill imbriqué peut apparaître après lecture ou modification de son dossier; un plugin utilise un namespace, non skillOverrides; un skill synchronisé peut différer entre local, Cowork et cloud. Gardez les règles fréquentes brèves dans CLAUDE.md, les procédures dans un skill à description précise et les procédures rares de sécurité, reprise ou release explicitement appelables.
Choisir le mécanisme qui applique la règle
| Besoin | Emplacement |
|---|---|
| Rappel récurrent | Règle courte dans CLAUDE.md |
| Régénération documentaire | Skill dédié |
| Refus avant écriture | Hook PreToolUse |
| Vérification indépendante | Subagent aux droits minimaux |
| Lecture externe autorisée | MCP |
Une instruction ne bloque pas une écriture. Testez événement, matcher et refus réel : Write ne bloque pas Bash, et un subagent séparé n’est pas read-only par défaut. Voir mécanismes, Hooks, règles CLAUDE.md, Stop Hook et MCP ou commande.
Stop Hook vérifie la fin du travail ; il ne remplace pas PreToolUse avant une écriture. Gardez une règle courte et un lien vers le skill dans CLAUDE.md, sans copier toute la procédure dans chaque mécanisme.
Entrée compacte et script déterministe
---
name: db-migrator
description: >-
Utilisez ce skill pour vérifier et appliquer les migrations Prisma après une modification de schéma.
---
Placez la logique répétable dans scripts/ :
<!-- Dans SKILL.md -->
```bash
python3 "${CLAUDE_SKILL_DIR}/scripts/validate_schema.py" --strict
```
Ne désactivez pas les contrôles de sécurité, linters ou vérifications de types pour économiser des tokens.
Vérifier découverte et appel
Vérifiez séparément que SKILL.md existe, que son frontmatter est du YAML avec une description non vide, que references/, examples/ et scripts/ se résolvent depuis le dossier du skill, puis que le script retourne le code attendu sur une entrée sûre. Un Python appelé par python3 n’a pas besoin du bit exécutable; test -f ne valide pas du YAML. Dans des sessions neuves, contrôlez /skills, un appel explicite, puis une demande correspondante sans nommer le skill. Comparez /skill-doctor, /doctor et /context avant et après une modification, pour le déclenchement correct comme pour les tokens.