Tiering des skills : le modèle à quatre catégories qui maintient nos 80+ skills hors du contexte

Pourquoi davantage de skills ne signifie pas forcément moins de contexte

La configuration Claude Code de Statnive charge plus de 80 skills couvrant la gestion de produit, le scaffolding backend, la QA, l’audit de sécurité, les patterns spécifiques à WordPress, le packaging de release, et bien d’autres domaines. Le framework sur lequel nous bâtissons (jaan.to) en livre 141 à lui seul. Lecture naïve : plus de skills, plus de surcharge contextuelle, moins de marge pour le travail réel et productif.

Le calcul réel est bien plus intéressant. 80 skills peuvent coûter 3 200 tokens de métadonnées permanentes, ou zéro, selon la configuration de chacun. La différence tient au modèle de tiering à quatre catégories défini par le système de skills de Claude Code, et à un unique test à une seule question pour choisir la bonne catégorie.

Cet article passe en revue les quatre catégories avec la distribution réelle des skills Statnive, le test que nous utilisons pour décider, et les trois choses que nous avons mal faites avant de les corriger définitivement.

Divulgation progressive : le mécanisme sous-jacent

Avant que le modèle de tiering n’ait du sens, le mécanisme de chargement doit l’avoir. Claude Code utilise trois couches de divulgation progressive pour les skills :

Couche	Ce qui se charge	Quand	Coût
1 — Métadonnées	Frontmatter YAML name + description	Toujours au démarrage	~30–50 tokens par skill
2 — Corps	Contenu complet de SKILL.md	Lorsque le skill est invoqué	Anthropic recommande ≤ 500 lignes / ~5K tokens
3 — Ressources groupées	Scripts référencés, modèles, références	Uniquement à l’accès	Coût de base nul

C’est le levier qu’utilise le modèle de tiering. La couche de métadonnées est la seule chose qui soit toujours en contexte. Tout le reste est à la demande.

Pour un framework de 141 skills, cela représente 4 200 à 14 100 tokens de surcharge permanente rien que pour les métadonnées, augmentant linéairement avec le nombre de skills. Davantage si les descriptions sont verbeuses. Moins — voire zéro — si vous demandez à certains skills d’ignorer entièrement le registre des métadonnées.

Un bug documenté (Claude Code GitHub issue #14882) signale que certains plugin skills peuvent consommer leur corps complet au démarrage plutôt que le seul frontmatter. Nous le surveillons dans notre propre sortie /context. Si la ligne de métadonnées de skill affiche des nombres bien supérieurs à ~50 tokens × votre nombre de skills auto-invocables, vous tombez probablement dessus.

Les quatre catégories

Chaque skill du dépôt Statnive entre dans l’une des quatre catégories. Le champ de frontmatter qui définit chacune :

Catégorie 1 — Always-On (frontmatter par défaut)

---
name: simplify
description: Review changed code for reuse, quality, efficiency. Auto-fixes issues.
---

Ce sont les skills de workflow centraux vers lesquels le modèle doit router automatiquement. Frontmatter standard — aucun flag particulier. Métadonnées chargées au démarrage ; corps chargé à l’invocation.

Exemples Statnive : simplify, statnive-release, statnive-release-zip. Ils se déclenchent sur la plupart des tâches liées aux releases.

Coût par skill : ~40 tokens de métadonnées en permanence dans le contexte.

Catégorie 2 — Auto-invocable (frontmatter par défaut, description concise)

Configuration identique à Always-On du point de vue de Claude Code. La distinction est éditoriale : ce sont des skills de domaine qui ne se déclenchent que lorsque leurs mots-clés déclencheurs correspondent. La discipline consiste à garder la description orientée trigger et courte.

---
name: wp-rest-api
description: Use when building REST endpoints in WordPress plugins.
---

Mauvaise description (fonctionne quand même, coûte plus cher) :

description: A comprehensive skill for working with the WordPress REST API,
  including endpoint registration, controller patterns, schema validation,
  authentication, response shaping, and CPT/taxonomy exposure...

Bonne description (ci-dessus) : 13 tokens. Mauvaise description : 38 tokens. Sur 60+ skills auto-invocables, la différence représente environ 1 500 tokens d’économie de métadonnées permanentes.

Exemples Statnive : wp-rest-api, wp-plugin-development, wp-performance, react-best-practices, wp-block-development, tous les skills de planification jaan-to:*.

Coût par skill : ~30–50 tokens de métadonnées en permanence dans le contexte.

Catégorie 3 — Manuel uniquement (disable-model-invocation: true)

---
name: statnive-emergency-rollback
description: Emergency-only rollback procedure for a botched deploy.
disable-model-invocation: true
---

Le skill existe, la slash command fonctionne (/statnive-emergency-rollback), mais les métadonnées n’entrent jamais dans le registre <available_skills>. Claude ne sait pas qu’il existe à moins que l’utilisateur ne l’invoque explicitement.

Coût par skill : 0 token. C’est la catégorie magique.

Quand l’utiliser : workflows rares, opérations destructives, tout ce vers quoi vous ne voulez pas que le modèle route automatiquement. Si marquer un skill manuel uniquement empêcherait un workflow d’aboutir, il appartient plutôt aux Catégories 1 ou 2.

Exemples Statnive : Rollback d’urgence, chirurgie manuelle de base de données, scripts de migration ponctuels, tout ce qui existe « au cas où » mais ne devrait pas se déclencher de manière opportuniste.

Nous marquons à peu près la moitié de nos skills disable-model-invocation: true. Sur 80+ skills, cela représente ~1 800 tokens de métadonnées de base récupérés — et la qualité de routage sur les skills auto-invocables restants s’est en réalité améliorée, parce que Claude n’avait plus à choisir entre des quasi-doublons.

Catégorie 4 — Fork / Sous-agent (context: fork)

---
name: simplify
description: Review changed code for reuse, quality, efficiency. Auto-fixes issues.
context: fork
---

Le mode fork exécute le skill dans un contexte de sous-agent isolé avec son propre historique de conversation et sa propre fenêtre de 200K tokens. La sortie du travail reste hors de la fenêtre de contexte principale. Seul un résumé revient.

Pour des workflows autonomes comme les revues de code, les audits de sécurité et la recherche multi-étapes, c’est transformateur. Anthropic documente des sous-agents qui retournent ~500–1 000 tokens à partir de 10 000+ de travail interne — soit une réduction du contexte principal d’environ 37 % sur les tâches complexes où le sous-agent a effectué une lecture et un traitement substantiels.

Exemples Statnive : simplify (trois agents de revue parallèles, retourne un résumé), jaan-to:backend-pr-review, jaan-to:sec-audit-remediate, jaan-to:detect-dev. Tout ce qui lit beaucoup de fichiers et retourne un verdict précis.

Coût par skill : ~40 tokens de métadonnées, mais le travail lui-même se déroule en isolation.

Le test à une seule question

Les quatre catégories sonnent comme quatre décisions distinctes. Ce n’en est en réalité qu’une seule : la conversation principale a-t-elle besoin de voir le travail intermédiaire du skill ?

Réponse	Catégorie
Oui — le skill écrit du code que la session principale continuera à éditer	Always-on ou Auto-invocable
Non — le skill retourne un verdict, un résumé ou un rapport	Fork / sous-agent
Peut-être — mais il ne devrait jamais se déclencher automatiquement (rare, destructif, atypique)	Manuel uniquement

Si « non », réglez context: fork. Votre contexte principal reste propre et vous pouvez utiliser Haiku 4.5 ($1/$5 par MTok) pour le travail de lecture intensif du sous-agent, tandis que la session principale utilise Sonnet ou Opus. C’est un gain de coût de 3× en plus du gain de contexte.

Si « oui », il va dans les Catégories 1 ou 2. Le choix entre Always-On et Auto-invocable est éditorial : avec quelle confiance Claude peut-il déclencher ce skill à partir de signaux en langage naturel ? Les triggers forts et sans ambiguïté vont dans Auto-invocable. Les workflows que le modèle devrait considérer dans la plupart des sessions vont dans Always-On.

Si le skill existe mais ne devrait jamais se déclencher automatiquement, marquez-le Manuel uniquement et récupérez son coût en métadonnées.

La distribution réelle des skills Statnive

Voici notre répartition actuelle sur ~85 skills :

Catégorie	Nombre	Coût total des métadonnées	Notes
Always-On	8	~320 tokens	Release, simplify, planification de sprint, revue de PR
Auto-invocable	38	~1 520 tokens	Skills de domaine avec mots-clés déclencheurs forts
Manuel uniquement	32	0 tokens	Slash command uniquement
Fork / sous-agent	7	~280 tokens	Revues, audits, détections
Coût total des métadonnées	85	~2 120 tokens	Environ 1 % du contexte

Sans tiering — si les 85 étaient en configuration par défaut — nous paierions environ 3 400 tokens de métadonnées permanentes. Les 32 skills manuel uniquement à eux seuls économisent ~1 280 tokens. Cela paraît modeste isolément ; cela compte lorsque c’est cumulé avec les coupes du CLAUDE.md et MCP Tool Search.

Limites de corps : pourquoi 500 lignes est le bon nombre

Le côté métadonnées représente une surcharge permanente. Le côté corps représente une surcharge par invocation — et tout aussi importante à contrôler.

Anthropic recommande de garder chaque SKILL.md sous 500 lignes (~5K tokens). Les recherches sur l’optimisation agressive poussent ce chiffre à un plafond strict de 600 lignes par corps de skill, tout dépassement nécessitant une extraction par référence : sortir les modèles, les longues checklists, les comparaisons multi-stack, les catalogues d’anti-patterns du SKILL.md vers des fichiers séparés référencés via des pointeurs clairs.

Le pattern ressemble à ceci :

.claude/skills/wp-plugin-development/
├── SKILL.md                          # 380 lignes — cœur d'exécution uniquement
└── references/
    ├── activation-deactivation-patterns.md   # Chargé uniquement quand nécessaire
    ├── settings-api-patterns.md
    ├── nonce-and-capability-checklist.md
    └── release-packaging-checklist.md

Le cœur d’exécution reste compact et déterministe. Les références se chargent à la demande, ne coûtant zéro token tant qu’on n’y accède pas. Nous avons reconstruit trois de nos skills les plus lourds de cette manière et coupé ~12 000 tokens des budgets d’invocation typiques.

L’autre champ de contrôle de corps qui mérite d’être utilisé :

allowed-tools: ["Read", "Grep", "Glob"]

Ceci restreint les outils auxquels le skill peut accéder, réduisant à la fois la surcharge en tokens et la surface d’exécution. Un skill qui ne fait que lire du code ne devrait pas avoir accès à Write, Bash ou aux outils MCP — réduire la palette d’outils réduit le schéma injecté lorsque le skill se déclenche, et élimine des classes entières de comportements accidentels.

Ce que nous avons mal fait les trois premières fois

Mises en garde honnêtes, dans le même esprit que le reste de la série :

1. Nous avons commencé avec des descriptions verbeuses. Notre première vague de skills avait des descriptions de 60+ tokens optimisées pour les lecteurs humains. Elles fonctionnaient, mais elles coûtaient le double du nécessaire. Le premier cycle de réduction a coupé ~1 400 tokens de métadonnées sur la catégorie auto-invocable.
2. Nous avions trois skills qui faisaient des choses similaires. La catégorie auto-invocable comptait pm-roadmap-add, pm-roadmap-update et pm-sprint-plan avec des triggers qui se chevauchaient. Le routage devenait aléatoire. Nous avons consolidé et clarifié les triggers. La précision du routage a augmenté ; le coût en métadonnées a baissé.
3. Nous avions des skills lourds qui n’utilisaient pas le mode fork. simplify s’exécutait à l’origine en ligne. Il lisait 30+ fichiers, lançait trois passes de revue et retournait un rapport de 2 000 tokens — tout ce travail interne polluait le contexte principal. Le passage à context: fork a réduit l’utilisation typique du contexte principal de ~9 000 tokens par session de release.

L’étape de mesure

Comme pour le reste de la série : /context est le diagnostic. La ligne à surveiller pour le tiering des skills est celle qui affiche le décompte de tokens des métadonnées de skill. Les cibles que nous utilisons :

Source	Cible	Plafond strict
Métadonnées de skill	≤ 2 500 tokens	5 000
Nombre de skills auto-invocables	≤ 60	—
Tout corps de SKILL.md unique	≤ 500 lignes / ~5K tokens	600 lignes / ~8K tokens

Si votre ligne de métadonnées de skill est largement au-dessus de 5K tokens et que vous avez moins de 100 skills, vous avez probablement soit des descriptions verbeuses (problème de Catégorie 2), soit le bug de chargement mentionné plus haut (problème de Catégorie 1).

Comment cela s’articule avec le reste de Statnive

Nous exécutons 248 tests unitaires PHP à chaque commit. Les releases passent 22 portes de publication avant qu’une version ne soit livrée. Les skills qui orchestrent tout cela — statnive-release, simplify, wp-plugin-development, les générateurs QA — tiennent dans environ 2 100 tokens de métadonnées permanentes. Le travail s’exécute, le contexte reste propre, et l’équipe reste petite.

Le modèle à quatre catégories n’est pas un exercice académique. C’est la raison pour laquelle nous pouvons livrer un plugin d’analytique WordPress sous un budget tracker de 5 KB sans une équipe de cinq personnes derrière.

Essayez Statnive

Analytique WordPress qui place la confidentialité au premier plan, construit par une équipe qui exécute /context plus souvent que /help. Installez Statnive gratuitement depuis WordPress.org — vos données restent sur votre serveur, et notre bibliothèque de skills reste bien sous son budget de tokens.