Agent Skills dans Claude Code : Le Guide Avancé

Agent Skills dans Claude Code : Le Guide Avancé

Le skill a planté ma session principale. Pas un petit dysfonctionnement — pas une situation du genre « hmm, ça n'a pas l'air correct ». Je parle d'une context window de 47 000 tokens consommée en huit secondes, parce qu'un skill de recherche que j'avais écrit a tenté d'aspirer l'intégralité de l'historique des issues d'un dépôt GitHub dans la conversation. Claude a cessé de répondre en pleine phrase. La session était fichue.

C'était il y a trois semaines. J'essayais de créer un skill capable de rassembler de la veille concurrentielle avant de rédiger un article technique. Idée simple : interroger GitHub, récupérer les issues récentes, résumer les tendances. Le skill fonctionnait — techniquement. Mais il fonctionnait comme une lance à incendie qu'on utiliserait pour remplir une tasse de café. Toutes les données sont arrivées, et elles ont tout détruit autour d'elles.

J'ai passé la semaine suivante à reconstruire ce skill en utilisant trois fonctionnalités que j'avais ignorées : le context forking, l'injection dynamique de contexte et les agents en arrière-plan. Le même skill s'exécute désormais dans sa propre session isolée, pré-traite les données via des scripts shell avant que Claude ne les voie, et fonctionne de manière asynchrone pendant que je continue à coder dans ma fenêtre principale. Le coût en tokens est passé de 47 000 à environ 3 200. Même qualité de résultat. Un univers d'efficacité complètement différent.

Cette expérience m'a appris quelque chose que je n'avais lu dans aucune documentation ni tutoriel : l'architecture de base d'un skill — un dossier avec un fichier SKILL.md — est la ligne de départ, pas la ligne d'arrivée. Les fonctionnalités avancées qui se superposent à cette fondation sont ce qui transforme les skills, les faisant passer de « raccourci de prompt astucieux » à « véritable flux de travail autonome ». Et la plupart des développeurs qui créent des skills en ce moment ne les ont même pas effleurées.

Voici tout ce que j'ai appris sur le versant avancé des skills de Claude Code — les aspects qui m'ont fait passer de la construction de jouets à la construction de systèmes.

Où en sont les Skills aujourd'hui (et pourquoi les bases ne suffisent plus)

Si vous avez lu mon précédent article sur le fonctionnement fondamental des agent skills, vous connaissez le concept de base : un skill est un dossier contenant un fichier SKILL.md avec du frontmatter YAML et des instructions en markdown. Claude charge les métadonnées, voit quels skills sont disponibles, et ne récupère le contenu complet que lorsqu'un skill est pertinent pour la tâche en cours. Divulgation progressive. Efficacité du contexte. Expertise modulaire.

Cette architecture est véritablement bien conçue. J'utilise encore des skills basiques tous les jours — mon formateur de messages de commit, ma checklist de revue de code, mon script de vérification pré-déploiement. Ils sont simples, ils fonctionnent, et ils me font gagner 10 à 15 minutes à chaque utilisation.

Mais je n'arrêtais pas de me heurter à des murs.

L'incident du skill de recherche était l'exemple spectaculaire, mais les échecs plus discrets étaient plus instructifs. Un skill qui avait besoin de l'état actuel du projet — quels fichiers avaient changé, sur quelle branche je me trouvais, quelles dépendances étaient installées — mais qui ne pouvait accéder qu'à des instructions statiques écrites au moment de la création du skill. Un skill qui exécutait un flux de travail complexe en plusieurs étapes et polluait ma conversation principale avec 30 messages de résultats intermédiaires dont je n'avais que faire. Un skill qui fonctionnait brillamment avec Opus 4 mais qui se mettait à halluciner des étapes après que j'ai basculé sur Sonnet 4.6.

Chacun de ces échecs pointait vers la même lacune : les skills de base sont statiques. Ils encodent du savoir, mais ils ne peuvent pas s'adapter au contexte en temps réel, isoler leur travail, ni prouver qu'ils fonctionnent encore correctement à mesure que les modèles évoluent.

Anthropic a manifestement identifié la même lacune. Le système de skills en date de mars 2026 inclut des fonctionnalités qui répondent à chacun de ces problèmes. La difficulté, c'est que ces fonctionnalités sont documentées sur différentes pages, expliquées dans différents contextes, et — honnêtement — pas toujours évidentes dans leur puissance tant qu'on n'a pas heurté le mur spécifique qu'elles résolvent.

Je vais les parcourir une par une, dans l'ordre où j'aurais aimé les apprendre.

Types de Skills : choisir la bonne architecture avant d'écrire une seule ligne

Avant de construire un skill avancé, vous devez répondre à une question : quel type de problème ce skill résout-il ? Anthropic catégorise les skills en deux types, et se tromper de choix signifie construire quelque chose de soit trop compliqué, soit trop limité.

Skills d'augmentation de capacité

Ceux-ci confèrent à Claude des capacités qu'il ne possède pas nativement. Mon skill d'automatisation de navigateur Airtop est un pur skill d'augmentation de capacité — Claude ne peut pas piloter un navigateur cloud de manière native, mais avec le skill installé, il peut naviguer sur des sites web, remplir des formulaires, extraire des données et gérer des sessions authentifiées. L'intégration Airtop compile des instructions en langage naturel en code déterministe qui s'exécute sur une véritable instance Chromium dans le cloud.

Autres exemples de skills d'augmentation de capacité que j'utilise quotidiennement : un skill qui exécute des audits Lighthouse et renvoie les scores dans la conversation. Un skill qui interroge ma base de données de projets Airtable. Un skill qui génère et rend des compositions vidéo Remotion.

Le schéma est constant — les skills d'augmentation de capacité incluent des scripts exécutables (bash, Python, Node) que Claude invoque comme des outils. Les instructions en markdown indiquent à Claude quand et comment utiliser l'outil. Le script fait le travail effectif.

Skills de préférences encodées

Ceux-ci n'ajoutent pas de nouvelles capacités. Ils encodent des flux de travail spécifiques, des conventions et des schémas de prise de décision. Mon skill de revue de code ne donne à Claude aucun nouvel outil — Claude sait déjà lire du code et suggérer des améliorations. Le skill encode les standards de revue de mon équipe : vérifier d'abord les requêtes N+1, s'assurer que toutes les méthodes publiques ont des docblocks, signaler tout SQL brut non paramétré, vérifier que les réponses d'erreur respectent notre contrat API.

La distinction est importante car elle détermine la complexité. Les skills d'augmentation de capacité nécessitent des scripts, des définitions d'outils, parfois des configurations de serveur MCP. Les skills de préférences encodées sont du pur markdown — souvent 50 à 200 lignes d'instructions précises. Si vous construisez un skill de préférences encodées et que vous vous retrouvez à écrire des scripts shell, vous avez probablement mal identifié le type.

J'ai fait cette erreur deux fois avant de retenir la leçon. J'ai construit un skill élaboré avec un script Python pour « analyser » les patterns de test de ma base de code, alors que tout ce dont j'avais besoin était un fichier markdown indiquant à Claude « quand tu écris des tests pour ce projet, utilise Pest au lieu de PHPUnit, mock les services externes avec Http::fake(), et teste toujours le cas d'erreur en premier ». La version en pur markdown était plus rapide à construire, plus rapide à charger, et produisait de meilleurs résultats parce que Claude n'alternait pas entre le suivi d'instructions et l'appel d'outils.

Cela dit — les skills les plus puissants que j'ai construits combinent les deux types. Le skill de recherche que j'ai fini par corriger ? Augmentation de capacité pour la collecte de données (scripts shell interrogeant l'API GitHub), préférences encodées pour l'analyse (comment pondérer les différents signaux, quel format de sortie utiliser). Les skills hybrides, c'est là que les choses deviennent intéressantes, et c'est là que les fonctionnalités avancées commencent à justifier leur complexité.

Context Forking : offrir aux Skills leur propre espace de réflexion

C'est la fonctionnalité qui a sauvé mon skill de recherche. Et c'est celle que je pense que la plupart des développeurs devraient apprendre en premier.

Voici le problème que résout le context forking. Quand un skill s'exécute dans votre session Claude principale, chaque token qu'il génère — chaque étape intermédiaire, chaque donnée qu'il traite, chaque chaîne de raisonnement qu'il suit — vit dans votre context window principale. Un skill qui effectue 15 étapes de travail avant de produire une réponse finale a déversé 15 étapes de contexte non sollicité dans votre conversation. Votre prochain prompt doit maintenant rivaliser avec tout ce bruit pour capter l'attention de Claude.

J'ai mesuré cela sur un projet réel le mois dernier. Ma session principale était à environ 12 000 tokens quand j'ai déclenché un skill qui analysait mon package.json, vérifiait les dépendances obsolètes, les croisait avec les vulnérabilités connues, et produisait un plan de mise à jour priorisé. Le temps que le skill termine, ma context window contenait 38 000 tokens. La sortie du skill — la partie que je voulais réellement — faisait environ 800 tokens. Les 25 200 autres tokens étaient de la mémoire de travail que je ne regarderais plus jamais. Et ils allaient rester là, consommant de la capacité et dégradant légèrement la concentration de Claude, pour le reste de la session.

Le context forking élimine totalement ce problème. Vous ajoutez une seule ligne au frontmatter YAML de votre skill :

---
name: dependency-audit
description: Analyzes project dependencies for security issues and updates
context: fork
---

La directive context: fork indique à Claude Code de créer un subagent dédié pour ce skill. Le subagent obtient sa propre context window, son propre historique de conversation, et le contenu complet du skill injecté au démarrage. Il fait tout son travail en isolation, puis ne renvoie que le résultat final à votre session principale.

Même skill d'audit de dépendances, même projet. Coût en session principale : environ 1 200 tokens (la requête et le résumé renvoyé). Le subagent a consommé ses propres 26 000 tokens dans sa propre fenêtre, qui a été nettoyée une fois le skill terminé.

Le modèle mental qui m'a aidé : imaginez le context forking comme l'exécution d'une fonction dans un thread séparé plutôt qu'en ligne. La version en ligne fonctionne, mais elle bloque votre thread principal et laisse ses stack frames traîner. La version forkée s'exécute indépendamment et renvoie un résultat propre.

Quand forker (et quand ne pas forker)

Je forke tout ce qui implique plus de 3-4 étapes de traitement intermédiaire. Les skills courts — formater un message de commit, générer un fichier de migration, vérifier une seule configuration — s'exécutent très bien dans le contexte principal. Le surcoût de création d'un subagent n'en vaut pas la peine pour un skill qui génère 500 tokens de mémoire de travail.

Mais tout ce qui implique de la recherche, de l'analyse, du traitement multi-fichiers ou du raisonnement complexe ? Forkez-le. Les économies de contexte se cumulent au fil d'une journée de travail. Avant, je redémarrais mes sessions Claude toutes les 2-3 heures parce que le contexte devenait trop encombré. Avec les skills forkés qui gèrent le travail lourd, je tiens régulièrement des sessions complètes de 8 heures sans dégradation.

Un point que la documentation ne souligne pas assez : les skills forkés peuvent spécifier quel modèle d'agent utiliser. J'exécute ma session principale sur Opus 4.6 pour son raisonnement profond, mais mes skills forkés plus simples — collecte de données, formatage, organisation de fichiers — tournent sur Sonnet 4.6 pour une fraction du coût. Vous définissez cela dans le frontmatter :

---
name: format-changelog
description: Generates a formatted changelog from git history
context: fork
model: sonnet
---

Un seul skill de recherche qui me coûtait 0,40 $ par exécution sur Opus ne coûte désormais que 0,06 $ parce que le fork de collecte de données tourne sur Sonnet et seule l'étape d'analyse finale utilise Opus dans ma session principale. Sur un mois d'utilisation quotidienne, ça représente une somme concrète.

Injection dynamique de contexte : des Skills qui savent ce qui se passe en temps réel

Les instructions statiques deviennent caduques dès que l'état de votre projet entre en jeu. J'ai appris cela en construisant un skill de déploiement qui avait besoin de connaître la branche git actuelle, le hash du dernier commit, quelles variables d'environnement étaient définies, et si des migrations étaient en attente. Je pouvais coder en dur des instructions sur comment vérifier ces informations, mais le skill passait des tokens à faire exécuter des commandes par Claude et traiter des sorties que j'aurais pu rassembler à l'avance.

L'injection dynamique de contexte inverse le modèle. Au lieu que Claude découvre l'état du projet à l'exécution, un script de pré-traitement collecte les données avant le chargement du skill, et les injecte directement dans le contenu du skill. Claude reçoit le skill avec les données en temps réel déjà intégrées. Aucune étape de découverte. Aucun token gaspillé.

La syntaxe utilise des espaces réservés !command dans votre SKILL.md :

---
name: deploy-preflight
description: Runs deployment readiness checks for current branch
context: fork
---

## Current Project State

- **Branch:** !git rev-parse --abbrev-ref HEAD
- **Last commit:** !git log -1 --oneline
- **Uncommitted changes:** !git status --porcelain | wc -l
- **Pending migrations:** !php artisan migrate:status --pending 2>/dev/null || echo "N/A"
- **Node version:** !node --version
- **Environment:** !echo $APP_ENV

## Deployment Checklist

Based on the current state above, verify the following...

Quand ce skill s'active, Claude Code exécute chaque commande shell !command, capture la sortie, et remplace l'espace réservé par le résultat réel. Claude voit :

- **Branch:** feature/payment-gateway
- **Last commit:** a3f2c91 Add Stripe webhook handler
- **Uncommitted changes:** 3
- **Pending migrations:** 2 pending

Pas les commandes. Les résultats. Claude commence à raisonner sur l'état de préparation au déploiement à partir de l'état réel du projet au lieu de dépenser des tokens à le découvrir.

Les économies de tokens sont significatives — mon skill deploy-preflight est passé d'environ 4 800 tokens (avec Claude exécutant des commandes de découverte) à 1 900 tokens (avec l'état pré-injecté). Mais le gain le plus important concerne la précision. Quand Claude découvre l'état lui-même, il arrive qu'il parse mal la sortie d'une commande, saute une vérification s'il est « suffisamment confiant », ou se laisse distraire par une réponse inattendue. Avec des données pré-injectées, chaque élément d'état est garanti présent et correctement formaté.

Combiner injection et forking

La vraie combinaison gagnante, c'est d'utiliser les deux ensemble. Mon skill de recherche concurrentielle — celui qui a déclenché tout ce parcours — ressemble maintenant à ceci :

---
name: competitive-research
description: Analyzes GitHub activity and trends for a given technology
context: fork
model: sonnet
---

## Research Context

Target technology: {{topic}}
Date range: !date -v-30d +%Y-%m-%d to !date +%Y-%m-%d

## Recent Activity
!gh api search/repositories --jq '.[0:5] | .[] | "\(.full_name) - \(.stargazers_count) stars - \(.description)"' -q "{{topic}} pushed:>$(date -v-30d +%Y-%m-%d)"

## Trending Issues
!gh api search/issues --jq '.[0:10] | .[] | "[\(.repository_url | split("/") | last)] \(.title)"' -q "{{topic}} is:issue created:>$(date -v-7d +%Y-%m-%d)"

Les commandes shell pré-traitent les requêtes à l'API GitHub. Le context: fork exécute le tout dans un subagent isolé sur Sonnet. Ma session principale sur Opus reçoit un résumé propre. Coût total en tokens pour la session principale : environ 900 tokens. Travail réellement accompli : l'équivalent de ce qui faisait exploser ma context window de 47 000 tokens.

Ce n'est pas une amélioration incrémentale. C'est une capacité fondamentalement différente.

Agents en arrière-plan : des Skills qui travaillent pendant que vous travaillez

Certains skills prennent du temps. Un audit de sécurité complet d'une base de code. L'exécution et l'analyse d'une suite de tests complète. Le scraping et le résumé de 20 pages de documentation. Ces flux de travail peuvent prendre 3 à 5 minutes — une éternité quand vous attendez que votre terminal redevienne utilisable.

Les agents en arrière-plan résolvent ce problème en permettant aux skills de s'exécuter de manière asynchrone. Vous déclenchez le skill, il crée un agent en arrière-plan, et votre session principale reste réactive. Quand l'agent en arrière-plan termine, il fait remonter les résultats.

J'utilise cela quotidiennement pour mon skill d'analyse de tests. Après avoir poussé une branche de fonctionnalité, je déclenche le skill :

/skill test-analysis

Le skill forke dans un agent en arrière-plan, exécute la suite de tests complète, capture les échecs, analyse les rapports de couverture, et rédige un résumé. Pendant ce temps, je travaille déjà sur la fonctionnalité suivante dans ma session principale. Trois minutes plus tard, l'agent en arrière-plan revient avec :

Test Analysis Complete:
- 247 tests passed, 2 failed
- Failed: OrderCalculation::test_discount_stacking (assertion mismatch on line 89)
- Failed: PaymentGateway::test_timeout_retry (mock not returning expected response)
- Coverage: 78.3% (down 0.4% from main branch)
- Suggestion: The discount stacking failure looks like a rounding issue...

Le flux de travail est similaire à l'utilisation de Ctrl+B pour mettre en arrière-plan un subagent en cours d'exécution — l'agent continue de travailler indépendamment même après que votre tâche principale se poursuit. La commande /tasks vous offre un tableau de bord de tout ce qui s'exécute en arrière-plan, avec des identifiants que vous pouvez utiliser pour vérifier le statut, afficher les détails ou annuler.

Voici ce que personne ne vous dit sur les agents en arrière-plan : leur principale valeur ne réside pas dans le gain de temps, mais dans l'isolation du contexte. Avant d'utiliser les agents en arrière-plan, j'exécutais ma suite de tests dans la session principale de Claude et je récupérais plus de 200 lignes de sortie de tests que je devais filtrer mentalement. L'agent en arrière-plan traite tout ce bruit dans son propre contexte et ne me renvoie que le signal utile.

Si vous préférez confier la construction de ce type de système de skills multi-agents à quelqu'un d'autre, j'accepte des missions d'automatisation Claude Code. Vous pouvez voir ce que j'ai réalisé sur fiverr.com/s/EgxYmWD.

Installer des Skills : l'écosystème est plus vaste que vous ne le pensez

Je devrais revenir en arrière et parler de l'installation des skills dans votre système, car la situation a évolué rapidement.

La commande plugin

La méthode principale est le système de plugin intégré à Claude Code :

/plugin install <skill-name>@<marketplace>

Pour le dépôt officiel de skills d'Anthropic :

/plugin install document-skills@anthropic-agent-skills

Vous pouvez également enregistrer des marketplaces tiers :

/plugin marketplace add alirezarezvani/claude-skills

Après avoir ajouté un marketplace, chaque skill de ce dépôt devient installable en une seule commande.

L'écosystème skills.sh

L'écosystème skills.sh a explosé depuis que j'en ai parlé pour la première fois. En mars 2026, il y a plus de 7 000 skills évalués sur plusieurs marketplaces, compatibles non seulement avec Claude Code mais aussi avec Codex CLI, Gemini CLI, Cursor et Antigravity IDE. Le format universel SKILL.md signifie qu'un skill que vous construisez pour Claude fonctionne sur tous ces outils.

La meilleure méthode de découverte que j'ai trouvée : parcourir SkillHub ou le dépôt VoltAgent awesome-agent-skills, qui sélectionne des skills provenant des équipes de développement officielles et de la communauté. Filtrez par catégorie, vérifiez les évaluations, et installez en une seule commande.

Installation manuelle

Pour les skills que vous construisez vous-même — c'est là que réside la vraie puissance — vous avez deux options :

Portée projet : Déposez le dossier du skill dans .claude/skills/ de votre dépôt. Chaque membre de l'équipe qui clone le dépôt obtient automatiquement le skill. Versionné, partagé, cohérent.

Personnel : Placez-le dans ~/.claude/skills/ pour les skills que vous voulez disponibles sur tous vos projets. Mes skills de formatage, mes standards généraux de revue de code, mon guide de style d'écriture — tout cela vit dans mon répertoire personnel car ce n'est pas spécifique à un projet.

La structure de dossiers est simple :

.claude/skills/
  deploy-preflight/
    SKILL.md          # Frontmatter + instructions
    scripts/
      check-deps.sh   # Optional executable scripts
    templates/
      deploy-log.md   # Optional reference files

Claude voit le nom et la description du skill depuis le frontmatter. Le contenu complet ne se charge que lorsqu'il est déclenché. Les scripts dans le dossier deviennent des outils que le skill peut invoquer.

Construire des Skills manuellement : les patterns qui fonctionnent vraiment

J'ai construit environ 40 skills au cours des quatre derniers mois. La plupart des premiers étaient médiocres. Ceux que je construis maintenant sont radicalement meilleurs, et la différence tient à trois patterns que j'ai dû apprendre par l'échec.

Pattern 1 : la spécificité des instructions plutôt que le volume

Mes premiers skills comptaient plus de 500 lignes d'instructions détaillées. « Si l'utilisateur pose une question sur X, faire Y. S'il mentionne Z, vérifier W d'abord. Dans les cas où... » Exhaustif. Et catastrophique.

Le problème : les skills longs consomment des tokens de contexte même après le forking, et Claude devient moins performant dans le suivi des instructions à mesure que le jeu d'instructions s'allonge. Il existe un point d'équilibre — et d'après mes tests, il se situe entre 80 et 200 lignes de markdown pour la section d'instructions.

La solution a été d'écrire les instructions comme je brieferais un ingénieur senior, pas un junior. Au lieu de détailler chaque étape, je décris l'objectif, les contraintes et le niveau de qualité attendu. Le raisonnement de Claude comble les lacunes.

Mauvais :

1. First, open the file
2. Then find all functions
3. For each function, check if it has a docblock
4. If it doesn't have a docblock, generate one
5. The docblock should include @param tags
6. The @param tags should list the type first, then the name
7. After the @param tags, add a @return tag
...

Bon :

## Task
Add PHPDoc blocks to all public methods missing them.

## Standards
- Follow PSR-5 PHPDoc format
- Infer parameter types from type hints; fall back to mixed
- Include @throws if the method contains throw statements
- Keep descriptions to one sentence — if you need two, the method needs refactoring

La bonne version fait 6 lignes au lieu de 30+. Elle produit de meilleurs résultats parce qu'elle laisse à Claude la liberté de raisonner sur chaque cas spécifique plutôt que de suivre mécaniquement une checklist.

Pattern 2 : des conditions de sortie, pas seulement des conditions d'entrée

Le frontmatter de chaque skill contient une description qui indique à Claude quand s'activer. La plupart des créateurs de skills s'arrêtent là. Mais indiquer à Claude quand le skill est terminé est tout aussi important.

Sans conditions de sortie explicites, les skills ont tendance à en faire trop. Mon skill d'audit SEO continuait à trouver « encore une chose à vérifier » jusqu'à consommer 15 000 tokens d'analyse pour une seule page. L'ajout de conditions de sortie a résolu le problème :

## Completion Criteria
- All five audit categories scored (Performance, Accessibility, SEO, Best Practices, Content)
- Critical issues listed (severity: high only)
- Three specific, actionable recommendations provided
- Total output: under 500 words

Stop when these criteria are met. Do not continue analyzing.

Pattern 3 : des instructions de récupération d'erreur

Les skills qui appellent des outils externes — API, commandes shell, requêtes de base de données — rencontreront des échecs. Si vous n'indiquez pas à Claude comment gérer les échecs, il s'arrête maladroitement ou se met à improviser, ce qui est souvent pire.

Chaque skill d'augmentation de capacité que je construis désormais inclut une section sur les modes d'échec :

## When Things Go Wrong

**API returns 401:** The token has expired. Tell the user to run `gh auth refresh` and retry.
**API returns 404:** The repository doesn't exist or is private. Ask the user to verify the repo name.
**Command timeout (>30s):** The network request is hanging. Suggest checking VPN status or retrying with `--timeout 60`.
**Empty results:** This is valid — not every query has results. Report "no data found" rather than guessing.

Never fabricate data if a command fails. Report the failure and suggest a fix.

Ce seul pattern a éliminé environ 80 % des comportements imprévisibles que j'observais dans mes skills.

Tests et évaluation des Skills : la partie que tout le monde néglige

Je vais être direct : si vous construisez des skills sans les tester, vous construisez des skills qui casseront sans prévenir.

J'ai négligé les tests pour mes 20 premiers skills. Puis Claude a reçu une mise à jour de modèle, et 6 d'entre eux ont commencé à produire des résultats moins bons. Pas cassés — moins bons. Une dégradation subtile. Mon skill de revue de code ne détectait plus les requêtes N+1. Mon skill de déploiement commençait à sauter la vérification des migrations. Je ne m'en suis pas rendu compte pendant une semaine parce que les skills fonctionnaient toujours — ils fonctionnaient juste mal.

C'est pourquoi Anthropic a créé le Skill Creator.

Le Skill Creator : un skill qui construit et teste d'autres skills

Le Skill Creator est un méta-skill — un skill qui automatise le développement, le test et l'évaluation d'autres skills. Installez-le comme plugin, et vous accédez à deux flux de travail principaux :

Mode eval : Définissez des prompts de test, décrivez les sorties attendues, et le Skill Creator exécute votre skill contre chaque prompt et note les résultats. Il évalue selon cinq dimensions : complétude du frontmatter, qualité de la description, clarté des instructions, profondeur des explications, et taux de réussite des evals.

eval: Execute skill on test prompts → Grade outputs → Report scores

Mode improve : Tout ce que fait le mode eval, plus des comparaisons A/B en aveugle, une analyse automatisée et un raffinement itératif. Le Skill Creator exécute deux instances de Claude — une avec votre skill, une sans — leur donne le même prompt, et compare les sorties. Si la version avec skill ne surpasse pas significativement la version de base, vous savez que le skill n'apporte pas de valeur ajoutée.

improve: Execute → Grade → Blind A/B compare → Analyze → Iterate

Comment je teste mes Skills aujourd'hui

Chaque skill que je construis passe par ce pipeline avant que je le considère comme terminé :

Étape 1 : Définir 3 à 5 prompts de test. Ceux-ci doivent couvrir le cas nominal du skill, un cas limite, et au moins un cas adversarial (un prompt proche du domaine du skill mais qui ne devrait pas le déclencher).

Étape 2 : Exécuter le mode eval. Vérifier que tous les prompts de test produisent les sorties attendues. Si l'un échoue, réviser les instructions du skill.

Étape 3 : Exécuter le test A/B. C'est l'étape qui a changé ma vision de la construction de skills. J'avais un skill que je pensais brillant — un skill de revue de code avec des standards détaillés. Le test A/B a montré que Claude sans skill produisait des revues de qualité équivalente pour 3 cas de test sur 5. Mon skill « brillant » n'apportait de la valeur que pour les cas limites impliquant des requêtes de base de données et la gestion des erreurs API. Je l'ai réécrit pour me concentrer exclusivement sur ces domaines, j'ai réduit la longueur des instructions de 60 %, et les scores A/B sont passés à 5 sur 5.

Étape 4 : Re-tester après les mises à jour de modèle. Je conserve mes prompts de test dans un sous-dossier tests/ au sein du répertoire de chaque skill. Après toute mise à jour du modèle Claude, je relance les evals. Cela prend environ 10 minutes pour toute ma bibliothèque de skills et a détecté une dégradation trois fois au cours des deux derniers mois.

Le système d'évaluation exécute chaque test en parallèle, dans des contextes isolés, pour que les skills ne puissent pas interférer entre eux pendant les tests. Cette isolation compte — j'ai eu une fois un test de skill qui passait individuellement mais échouait quand il était exécuté en même temps que d'autres skills à cause d'une collision de noms dans le frontmatter.

Cette discipline de test ressemble à du surcoût jusqu'à la première fois qu'elle vous sauve. Après, elle vous semble être la seule façon responsable de construire des skills.

Intégration concrète : automatisation de navigateur cloud avec Airtop

La théorie, c'est utile. Laissez-moi vous montrer à quoi ressemble un skill entièrement avancé en production.

Le skill dont je suis le plus fier en ce moment est mon skill d'automatisation de navigateur Airtop. Airtop fournit un véritable navigateur cloud — pas un scraper headless, pas un DOM simulé, une véritable instance Chromium tournant dans le cloud, capable de gérer des sites lourds en JavaScript, des sessions authentifiées et du contenu dynamique.

Voici pourquoi c'est important : la moitié des automatisations que je veux faire exécuter par Claude impliquent des sites web qui n'ont pas d'API. Des pages de tarification de concurrents. Des portails fournisseurs. Des bases de données de conformité gouvernementale. Des sites d'offres d'emploi. Des CRM. Il n'y a pas d'API à interroger — la seule interface est un navigateur.

Le skill Airtop résout ce problème en combinant toutes les fonctionnalités avancées :

---
name: airtop-research
description: Automates web research using a real cloud browser via Airtop
context: fork
model: sonnet
---

Il forke dans son propre contexte (car l'automatisation de navigateur génère une sortie intermédiaire verbeuse). Il utilise l'injection dynamique pour charger mes identifiants API Airtop et les URL cibles. Il exécute Sonnet pour les étapes d'interaction avec le navigateur (économique pour la navigation mécanique) et renvoie des résultats structurés à ma session principale Opus pour l'analyse.

Un flux de travail que j'ai exécuté hier : surveiller les tarifs de la concurrence sur cinq outils SaaS. J'ai décrit ce dont j'avais besoin en langage naturel, le skill l'a compilé en code d'automatisation déterministe, a lancé des sessions de navigateur cloud sur chaque site, extrait les grilles tarifaires, et renvoyé une comparaison structurée. Temps total : environ 90 secondes. Équivalent manuel : 20 à 30 minutes à basculer entre les onglets et à copier-coller.

L'automatisation compilée est la partie qui m'a le plus surpris. Airtop ne se contente pas de rejouer mes instructions — il génère du vrai code à partir d'elles, qui s'exécute de manière déterministe lors des exécutions suivantes. La première exécution est pilotée par l'agent et exploratoire. Chaque exécution ultérieure est rapide et fiable. C'est un pattern que je n'ai pas vu dans d'autres outils d'automatisation de navigateur, et c'est ce qui fait la différence entre une « démo sympa » et un « flux de travail en production ».

La convergence des Skills et des commandes personnalisées

Un changement architectural mérite d'être noté : les skills et les slash commands personnalisées dans Claude Code convergent. Les versions antérieures les traitaient comme des systèmes séparés — les commandes étaient des raccourcis rapides, les skills des modules de connaissances plus profonds. Depuis Claude Code 2.1, la frontière s'est estompée.

Un skill peut désormais s'enregistrer comme slash command via le frontmatter :

---
name: security-audit
description: Full OWASP-aligned security review of the current project
command: /audit
context: fork
---

Taper /audit dans Claude Code déclenche le skill complet avec toutes ses fonctionnalités avancées — forking, injection dynamique, exécution en arrière-plan. Plus besoin de maintenir des configurations de commandes séparées.

Cette convergence compte parce qu'elle réduit la charge cognitive liée à la gestion de votre boîte à outils. Avant, je maintenais une carte mentale de « quels éléments sont des skills et quels éléments sont des commandes ». Maintenant, tout est un skill, et certains disposent de raccourcis de commande. Un seul système. Un seul emplacement. Un seul framework de test.

L'article claude-skills-guide-decoded que j'avais écrit précédemment couvre le format fondamental SKILL.md en profondeur. Ce qui a changé depuis, c'est que le format prend désormais en charge beaucoup plus d'options de frontmatter — context, model, command, restrictions d'outils et hooks de cycle de vie — transformant un simple fichier markdown en une configuration d'agent complète.

Ce que j'ai fait de travers (et ce que je ferais différemment)

Je veux conclure par les erreurs, car elles sont plus utiles que les succès.

Erreur n°1 : le forking excessif. Après avoir découvert le context forking, je l'ai appliqué à tout. Un skill de formatage de 3 lignes qui générait 200 tokens de sortie ? Forké. Le surcoût de création d'un subagent dépassait le coût contextuel de l'exécution en ligne. Forkez les skills qui génèrent 2 000+ tokens de mémoire de travail. Laissez les skills simples s'exécuter dans votre session principale.

Erreur n°2 : l'injection dynamique sans mise en cache. Certains de mes appels !command interrogeaient des API à chaque activation du skill. Si vous déclenchez un skill 10 fois en une heure, ça fait 10 appels API identiques. J'utilise maintenant des commandes shell qui vérifient d'abord un résultat en cache et n'interrogent en direct que si le cache est périmé. Pattern simple, évident a posteriori, mais j'ai épuisé mes quotas d'API avant de trouver la solution.

Erreur n°3 : construire des skills pour des tâches que Claude maîtrise déjà bien. Le framework de test A/B m'a appris cela : si Claude de base gère la tâche avec une qualité de 80 %+ sans skill, le skill ne vaut pas la peine d'être maintenu. Les skills doivent cibler les lacunes — les conventions spécifiques au projet, les intégrations d'outils externes, le savoir métier que Claude ne possède pas. Construire un skill pour « écrire du bon code Python » est un effort gaspillé. Construire un skill pour « écrire du code Python qui suit le pattern de décorateurs de notre équipe pour les endpoints FastAPI avec de la journalisation structurée » est une vraie amélioration.

Erreur n°4 : négliger la stratégie de test jusqu'à ce qu'il soit trop tard. Six skills cassés après une mise à jour de modèle. Voilà ce qu'il a fallu. Construisez la suite d'eval en même temps que le skill, pas après.

L'évaluation honnête de l'état actuel des skills : le système fonctionne. Les fonctionnalités avancées — forking, injection, agents en arrière-plan, evals automatisées — transforment les skills de « modèles de prompts astucieux » en véritable automatisation de flux de travail. L'outillage est encore suffisamment jeune pour que vous rencontriez des aspérités (les messages d'erreur des skills forkés pourraient être bien plus descriptifs, et la mise en place du test A/B nécessite plus de configuration manuelle qu'elle ne le devrait). Mais l'architecture est solide, et l'écosystème évolue à un rythme que je n'avais pas vu depuis les débuts de npm.

Sept mille skills rien que sur SkillsMP, et le format fonctionne sur Claude Code, Codex CLI, Gemini CLI et Cursor. Ce n'est plus une fonctionnalité spécifique à Claude. C'est un standard industriel en train de se former en temps réel.

La question n'est pas de savoir s'il faut investir dans l'apprentissage des fonctionnalités avancées des skills. C'est de savoir si vous pouvez vous permettre de continuer à construire des agents sans elles.

Questions fréquemment posées

Qu'est-ce que le context forking dans les skills de Claude Code ?

Le context forking crée un subagent dédié avec sa propre context window pour exécuter un skill en isolation. Ajoutez context: fork au frontmatter de votre SKILL.md pour éviter que les skills lourds ne polluent votre conversation principale. Pour le guide complet, consultez la section Context Forking ci-dessus.

Comment installer des skills Claude Code depuis le marketplace ?

Exécutez /plugin install <skill-name>@<marketplace> dans Claude Code, ou ajoutez un marketplace tiers avec /plugin marketplace add <repo>. Les skills s'installent dans .claude/skills/ pour une utilisation au niveau du projet ou dans ~/.claude/skills/ pour un usage personnel.

Qu'est-ce que l'injection dynamique de contexte dans Claude Code ?

L'injection dynamique de contexte utilise la syntaxe !command dans SKILL.md pour exécuter des commandes shell avant le chargement du skill. La sortie de la commande remplace l'espace réservé, de sorte que Claude reçoit les données en temps réel du projet — branche git, variables d'environnement, réponses API — sans dépenser de tokens en phase de découverte.

Comment tester les skills Claude Code avec le Skill Creator ?

Installez le plugin Skill Creator, définissez des prompts de test avec les sorties attendues, et lancez le mode eval. Pour une validation plus approfondie, utilisez le mode improve, qui exécute des tests A/B en aveugle comparant la sortie de Claude avec et sans le skill actif. Consultez la section Tests et évaluation ci-dessus.

Les skills Claude Code peuvent-ils s'exécuter en arrière-plan ?

Oui. Les skills avec context: fork peuvent créer des agents en arrière-plan qui travaillent de manière asynchrone pendant que votre session principale reste réactive. Utilisez /tasks pour surveiller les skills en arrière-plan, vérifier leur statut ou les annuler.

Travaillons ensemble

Vous cherchez à développer des systèmes d'IA, automatiser vos flux de travail ou faire monter en puissance votre infrastructure technique ? Je serais ravi de vous accompagner.

• Fiverr (projets sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io