Anthropic Skills : quand Claude apprend à s'auto-évaluer

Qu'est ce qu'un skills ?

Avant de parler de la nouveauté, posons les bases. Un skill, chez Anthropic, c'est un fichier SKILL.md — une instruction contextuelle que Claude peut consulter pour mieux accomplir une tâche spécifique. Concrètement, c'est la différence entre un Claude généraliste et un Claude qui connaît exactement vos conventions internes, votre stack technique, ou votre façon de rédiger des rapports.

La structure d'un skill ressemble à ceci :

mon-skill/
├── SKILL.md              ← les instructions principales
└── ressources/
    ├── scripts/          ← code réutilisable entre exécutions
    ├── references/       ← documentation chargée au besoin
    └── assets/           ← templates, polices, icônes...

Le chargement est progressif : seules les métadonnées (nom + description, ~100 mots) sont toujours en contexte. Le corps du SKILL.md n'est chargé que lorsque le skill se déclenche, et les ressources supplémentaires uniquement si Claude en a besoin. C'est une architecture pensée pour l'efficacité, pas juste pour l'ergonomie.

La boucle d'ingénierie : la vraie nouveauté

Ce qui change fondamentalement avec cette mise à jour, c'est que le skill-creator n'est plus un outil qui produit un fichier Markdown "à peu près bien". Il est devenu un vrai cycle d'ingénierie itératif, outillé pour mesurer objectivement si un skill fonctionne — et dans quelle mesure il fait mieux que de ne pas l'utiliser du tout.

La boucle complète ressemble à ceci :

Définir l'intention
      ↓
Écrire un draft du SKILL.md
      ↓
Générer des cas de test réalistes
      ↓
Lancer les runs en parallèle (avec-skill vs baseline)
      ↓
Pendant les runs : rédiger les assertions quantitatives
      ↓
Afficher les 11 lignes restantes

Chaque étape est précisément définie. Ce n'est pas "essayez et voyez si c'est mieux" — c'est un processus structuré avec des sorties mesurables à chaque cycle.

Runs parallèles et comparaison baseline

L'élément le plus structurant est l'exécution simultanée de deux agents pour chaque cas de test :

• with-skill : Claude avec accès au skill
• baseline : Claude sans le skill (ou, si vous améliorez un skill existant, Claude avec l'ancienne version)

Pourquoi simultanément ? Pour éviter que les résultats de l'une n'influencent l'autre, et pour que tout soit prêt en même temps. Claude ne lance pas les runs with-skill d'abord, puis revient pour les baselines — tout part dans le même tour.

Pendant que les agents tournent en arrière-plan, Claude ne reste pas inactif : il rédige les assertions (les critères de validation quantitatifs) et les explique à l'utilisateur. Deux activités en parallèle, sans friction.

Quand chaque tâche se termine, la notification contient total_tokens et duration_ms — des données éphémères que Claude capture immédiatement dans un timing.json. C'est la seule occasion de les récupérer.

L'eval-viewer

Une fois les runs terminés, Claude agrège tout dans un benchmark.json et lance le eval-viewer — une interface web locale générée par eval-viewer/generate_review.py. L'outil produit deux onglets :

Onglet "Outputs" — pour la revue qualitative :

• Le prompt soumis à l'agent
• Le fichier ou texte produit (rendu inline si possible)
• L'output de l'itération précédente (pour comparer l'évolution)
• Les grades formels sur les assertions (pass/fail + preuve)
• Une zone de feedback libre, auto-sauvegardée

Onglet "Benchmark" — pour la revue quantitative :

• Taux de réussite des assertions par configuration (with-skill vs baseline)
• Temps d'exécution et consommation de tokens (moyenne ± écart-type)
• Delta entre les deux configurations

À la fin, un "Submit All Reviews" exporte un feedback.json que Claude lit pour préparer l'itération suivante.

Un point d'ordre : Claude est explicitement instruit de lancer le viewer avant d'analyser les outputs lui-même. L'idée est de mettre les résultats devant l'humain le plus tôt possible, pas de filtrer à sa place.

Optimisation du déclenchement

Un skill peut être brillamment rédigé et pourtant ne jamais se déclencher. Le mécanisme de déclenchement repose entièrement sur la description dans le frontmatter YAML — c'est elle que Claude lit pour décider si un skill est pertinent. Et Claude a une tendance naturelle au sous-déclenchement : si la description est ambiguë, il préfère ne pas consulter le skill.

La mise à jour introduit un système d'optimisation automatique de la description via un script run_loop.py. La procédure :

1. Générer 20 requêtes de test : des should-trigger (8-10) et des should-not-trigger (8-10). Les cas les plus utiles sont les faux amis — des requêtes qui partagent des mots-clés avec le skill mais n'en ont pas besoin. Pas "écris une fonction fibonacci" comme négatif d'un skill PDF — trop facile — mais des cas frontières réels.

2. Faire valider les requêtes par l'utilisateur via une interface HTML.

3. Lancer la boucle d'optimisation :

python -m scripts.run_loop \
  --eval-set trigger-eval.json \
  --skill-path ./mon-skill \
  --model claude-sonnet-4-20250514 \
  --max-iterations 5 \
  --verbose

Le script divise automatiquement en 60% train / 40% test, évalue la description courante (3 fois par requête pour fiabilité), fait appel à Claude en extended thinking pour proposer des améliorations, réévalue, et répète jusqu'à 5 fois. Le résultat final : un best_description sélectionné sur le score test (pas train) pour éviter le surapprentissage, et un rapport HTML complet.

Expliquer le pourquoi

C'est probablement le point le plus important de cette mise à jour, et pourtant le moins spectaculaire. Le skill-creator décourage désormais activement les instructions rigides du type TOUJOURS faire X ou NE JAMAIS faire Y en majuscules. Non pas qu'elles soient interdites — mais elles sont un signal d'alarme.

La logique est simple : un skill va potentiellement être exécuté des millions de fois, sur des prompts qu'on ne peut pas tous anticiper. Une règle rigide sans justification se casse sur les cas imprévus. Une règle dont le raisonnement est explicite permet à Claude de l'appliquer intelligemment, même dans des situations non couvertes par les exemples.

En pratique, ça donne la différence entre :

TOUJOURS inclure un résumé exécutif en première section.

et

Commence par un résumé exécutif. Les lecteurs de ce type de rapport sont généralement des managers qui ne lisent que les premières lignes — le résumé est souvent tout ce qu'ils voient.

Le second est plus long.
Il est aussi infiniment plus robuste.

Mini-tutoriel : créer un skill de revue de code Go

Voici le parcours complet, du prompt initial au skill optimisé.

Étape 1 — Définir l'intention

Dites simplement à Claude ce que vous voulez :

"Je veux un skill pour faire des revues de code Go selon nos standards internes : respect des conventions idiomatiques Go, gestion explicite des erreurs, absence de secrets hardcodés, et commentaires godoc sur les fonctions exportées."

Claude va vous poser des questions de clarification : utilisez-vous golangci-lint ou un linter spécifique ? Travaillez-vous avec des modules Go ? Quel format de rapport attendez-vous ? Ne brûlez pas cette étape — les réponses alimentent directement la qualité du draft.

Étape 2 — Le draft du SKILL.md

Claude génère la structure de base. Le frontmatter ressemble à :

---
name: go-code-reviewer
description: >
  Analyse le code Go pour vérifier les conventions idiomatiques (nommage,
  gestion d'erreurs, interfaces), l'absence de secrets hardcodés, et la
  présence de commentaires godoc sur les symboles exportés.
  Déclenche ce skill dès qu'on ouvre ou modifie un fichier .go,
  lors d'une revue de PR, ou si l'utilisateur mentionne "code review",
  "relire mon Go", "vérifier mon package", ou "revoir ma PR Go".
  Ne pas déclencher pour des questions générales sur Go ou pour
Afficher les 2 lignes restantes

Notez la description "pushy" : elle liste des contextes de déclenchement spécifiques et des cas d'exclusion. C'est intentionnel pour contrer le sous-déclenchement.

Étape 3 — Cas de test et runs parallèles

Claude propose 2-3 cas de test réalistes, par exemple :

• Un package Go avec des erreurs silencieuses (_ = someFunc()) et des tokens API hardcodés
• Un handler HTTP qui ne respecte pas les conventions d'interface (io.Reader, http.Handler) et dont les types exportés sont non documentés
• Une PR mixant bons et mauvais patterns : goroutines sans context, nommage non-idiomatique (getUser au lieu de User), absence de defer pour fermer les ressources

Pour chaque cas, deux agents sont lancés simultanément : un avec le skill, un sans. Pendant ce temps, Claude rédige les assertions — par exemple :

{
  "assertions": [
    {
      "text": "Le rapport identifie les erreurs ignorées ou non gérées",
      "type": "boolean"
    },
    {
      "text": "Le rapport signale les secrets ou credentials hardcodés",
      "type": "boolean"
    },
Afficher les 10 lignes restantes

Étape 4 — Revue dans l'eval-viewer

Une fois les runs terminés, l'interface s'ouvre automatiquement. Vous voyez côte à côte ce que Claude produit avec et sans le skill, les scores sur chaque assertion, et le temps d'exécution. Vous laissez vos commentaires case par case.

Étape 5 — Itération

Claude lit vos retours, améliore le skill, et relance une nouvelle itération dans un répertoire iteration-2/. Le viewer vous montre alors les outputs en parallèle — cette itération vs la précédente.

On répète jusqu'à ce que les outputs soient satisfaisants.

Étape 6 — Optimisation du déclenchement

Skill validé ? On passe à l'optimisation de la description. Claude génère les 20 requêtes de test, vous les validez dans l'interface, et le script run_loop.py fait le reste. En sortie : une description optimisée avec le score de déclenchement avant/après.

Avant : 62% de déclenchement correct
Après : 91% de déclenchement correct

Étape 7 — Packaging

python -m scripts.package_skill ./python-code-reviewer

Cela produit un fichier .skill prêt à installer.

En résumé

Ce qui rend cette mise à jour significative n'est pas une fonctionnalité spectaculaire — c'est une philosophie d'ingénierie appliquée à la construction de prompts. Mesurer plutôt qu'estimer. Comparer contre une baseline plutôt que dans l'absolu. Expliquer le raisonnement plutôt qu'imposer des règles. Et surtout : garder l'humain dans la boucle à chaque itération, avec les bons outils pour qu'il puisse donner un feedback éclairé.

Petit bonus

Voici le skills de revue de code Go généré par ce tutoriel 😉

---
name: go-code-review
description: >
  Effectue des revues de code Go approfondies selon les standards internes de l'équipe : Clean
  Architecture (hexagonale), Go 1.21+, complémentaire à golangci-lint et go vet. Produit un
  commentaire par problème au format inline style PR GitHub/GitLab, avec niveaux de sévérité
  explicites. Utiliser ce skill dès qu'un utilisateur soumet du code Go à relire, demande une
  revue avant PR, un audit, une analyse qualité, mentionne "review", "relire", "vérifier mon
  code Go", "PR Go", "code à valider" — même sans mentionner explicitement les standards internes.
---
Afficher les 229 lignes restantes

Sources

• Vidéo tutoriel (Nate Herk) : Claude Code Skills Just Got Better
• Dépôt officiel Anthropic Skills : github.com/anthropics/skills
• Documentation : Agent Skills Overview
• Le guide complet pour construire des skills pour Claude : Guide de création de skills en PDF

Note : La boucle d'évaluation complète (runs parallèles, eval-viewer, optimisation de description) nécessite l'activation de l'exécution de code et est disponible dans sa forme complète via Claude Code. Sur Claude.ai, une version allégée reste accessible.