Freelance web, solo, depuis un bail. Pas d’équipe. Je suis le dev, le SEO, le sysadmin, le comptable, le support et le mec qui relance ses propres factures. Six casquettes, une personne.

Depuis que je bosse sous Claude Code (le CLI d’Anthropic, avec les skills : des dossiers SKILL.md que l’agent charge à la demande), j’ai transformé chaque casquette en skill. J’en suis à une soixantaine. Voici comment c’est organisé, et surtout pourquoi le vrai défi n’était pas de les écrire.

Un skill, c’est un bout de prompt + des instructions + parfois des scripts Node. Facile à créer. Trop facile.

Le piège arrive après : si tu charges tes 60 skills à chaque session, tu manges 8 à 10k tokens de baseline avant même de dire bonjour. Et dans une session donnée, 90 % ne servent à rien. Tu paies le contexte plein pot pour un outillage que tu n’utilises pas.

Donc la question n’est pas combien de skills je peux écrire, c’est comment je les range pour qu’ils ne me coûtent rien tant que je ne m’en sers pas.

Les trucs que j’utilise partout, quel que soit le projet : génération de factures, courriers admin en PDF brandé, optimisation d’images, conversion pandoc, la famille wrap-up/wrap-in (clôture et reprise de session). Ceux-là sont toujours dispo.

Toute la chaîne de prod client : nouveau-client, architecte, les trois builders (Elementor, Divi, Gutenberg), write-article, publish-wp-article, publish-social, deploy-ftp, plesk-server-admin.

Point clé : ce pack n’est pas chargé par défaut. Les projets web portent juste un pointeur du genre « si l’utilisateur tape /elementor-builder, va lire le SKILL.md et suis-le ». Le coût en baseline est quasi nul tant que je n’appelle pas le skill.

La version figée d’un skill, adaptée à un client précis : ses credentials, ses IDs de prod, sa voix éditoriale. Règle de priorité stricte : local > pack > global. Le snapshot local gagne toujours. Comme ça, le générique reste propre et sans secret, et le spécifique vit chez le client.

Résultat concret : une session admin ne charge pas les skills web. Une session web charge un pointeur, pas 23 skills d’un coup. Le contexte reste maigre, et je peux avoir 60 skills sans en payer le prix.

J’ai un skill dont le seul job est de m’empêcher d’en créer trop : do-i-have-a-skill.

Avant d’écrire un nouveau script, il cherche s’il existe déjà (local + global + les README de scripts). Verdict : 0 match, ok tu crées. 1 match ou plus, réutilise l’existant.

Je l’ai fait parce que je me suis retrouvé avec trois scripts qui faisaient la même chose. Sur une bibliothèque qui grossit, la prolifération est le vrai ennemi, pas le manque d’outils.

• publish-wp-article : preview HTML, scripts de publi, génération du JSON Elementor, push d’un draft WordPress + métas Yoast. Une commande au lieu d’une heure de clic.
• audit-seo : audit 4D (technique + Core Web Vitals + GA4/GSC + stratégie) qui sort un AUDIT.md exploitable.
• generate-facture : le launcher n’a aucun secret. Il délègue à un moteur planqué dans mon coffre-fort administratif, seul à toucher l’IBAN et la numérotation. Séparation des secrets, même en local.

• Maintenance : 60 skills, ça se met à jour et ça se resynchronise. J’ai fini par écrire des skills (wrap-in, update-skills) juste pour gérer la dette des autres skills. Meta-galère.
• Sur-ingénierie : la moitié du temps, un simple prompt aurait suffi. Un skill se justifie quand tu répètes un truc cinq fois ou plus, pas avant.
• Ma bête noire : l’éditeur Elementor sur mutualisé OVH qui sature (500/503 en rafale) dès que plusieurs previews tapent en même temps. Rien à voir avec les skills, mais ça pourrit la chaîne de publi. Le WAF a aidé, pas réglé.
• Le budget tokens reste un arbitrage permanent. Plus tu automatises, plus tu es tenté de tout charger, et là tu recrées le problème que tu voulais tuer.

Ce système, ce n’est pas « l’IA fait mon boulot ». C’est l’IA me rend l’équipe que je n’ai pas les moyens de payer. La différence est énorme : je garde la main sur chaque décision, l’outillage exécute le répétitif.

Si tu veux voir la première brique de cette bibliothèque, j’en avais parlé dans Skills Claude Code : ma bibliothèque. Cet article-ci en est la version consolidée, un an de bricolage plus tard. Et si le sujet des fichiers de contexte t’intéresse, il y a aussi SOUL.md.