Aller au contenu principal

Créer de meilleurs Agent Skills avec Test-Measure-Refine

· 4 minutes de lecture
Claude Dev
Claude Dev
Claude Dev

La plupart des agent skills échouent pour une raison simple : on modifie le prompt, on relance une fois, puis on conclut que c’est “mieux”.

La dernière mise à jour de Skill Creator chez Anthropic pousse une boucle plus orientée ingénierie : tester d’abord, mesurer le comportement, puis affiner. Si vous construisez des workflows d’agents en interne, c’est ce changement qui compte vraiment.

Cet article réécrit l’annonce officielle en workflow développeur exécutable chaque semaine.

Idée centrale : arrêter de prompter à l’aveugle​

La mise à jour officielle n’est pas seulement une “meilleure génération de prompts”. C’est une boucle qualité :

  1. Définir un comportement mesurable dès le départ
  2. Générer une suite de tests à partir de ce comportement
  3. Exécuter des évaluations sur l’ancienne et la nouvelle version
  4. Utiliser le feedback de l’evaluator pour supprimer conflits et instructions mortes
  5. Itérer avec des preuves, pas au ressenti

Si cela ressemble à de la CI pour prompts, c’est exactement l’objectif.

Ce qui change dans Skill Creator (version développeur)​

D’après l’article officiel, voici les changements vraiment utiles :

  • Golden prompts avant l’implémentation
    Vous écrivez (ou co-créez) des prompts concrets qui représentent des tâches réelles. Ils deviennent vos cas de base.

  • test-creator pour générer des tests de skill automatiquement
    Skill Creator peut créer des tests à partir de vos exigences, donc vous n’écrivez pas tout à la main.

  • Skill evaluator intégré
    Le feedback de l’evaluator met en évidence conflits d’instructions, chevauchements et zones faibles pour durcir la spec.

  • Affinage basé sur un signal qualité
    Vous êtes censé itérer sur plusieurs versions, en mesurant les changements via les sorties de tests, pas via “ça semble mieux”.

Cette approche convient mieux aux ingénieurs, car elle traite les skills comme des artefacts versionnés.

Workflow pratique à utiliser tout de suite​

Étape 1) Écrire les critères d’acceptation comme un contrat d’API​

Avant de modifier le skill, formalisez le comportement attendu :

  • Structure d’entrée
  • Schéma de sortie
  • Règles obligatoires
  • Règles interdites
  • Comportement en échec (que faire si le contexte manque)

Des critères flous donnent des tests flous.

Étape 2) Construire un set de golden prompts depuis des cas réels​

Utilisez de vrais logs, tickets ou demandes de votre équipe. Incluez :

  • Cas normal
  • Cas bruité/ambigu
  • Cas avec contexte manquant
  • Cas hors périmètre

C’est votre suite de régression. Petite, mais avec un signal fort.

Étape 3) Générer et exécuter les tests​

Utilisez Skill Creator + test-creator pour générer des tests structurés. Puis lancez :

  • Le skill actuel en production
  • Le skill candidat mis à jour

Comparez la qualité de sortie sur le même jeu de tests.

Étape 4) Exploiter le feedback evaluator et épurer les instructions​

Cherchez les patterns d’échec récurrents :

  • Instructions contradictoires
  • Instructions trop larges
  • Hypothèses cachées
  • Instabilité du format de sortie

À chaque itération, ne modifiez qu’une ou deux variables.

Étape 5) Promouvoir uniquement si les métriques montent​

Ne livrez pas parce qu’un exemple était bon. Promouvez seulement si :

  • Le taux de réussite progresse sur toute la suite
  • Les modes d’échec diminuent au lieu d’être déplacés
  • Le format de sortie reste stable sur les edge cases

Là où les équipes bloquent le plus souvent​

Voici les échecs classiques côté équipes dev :

  • Trop de règles dans un seul skill
    Un mega-skill qui fait résumé, planification, classification et interprétation de policy se dégrade vite.

  • Aucune version des données de test
    Sans versionner les golden prompts, vous ne pouvez pas faire confiance aux tendances.

  • Pas de comportement de refus
    Un skill doit définir quoi faire quand les données sont insuffisantes ou hors périmètre.

  • Affinage sans hypothèse
    “On ajuste le wording” sans hypothèse mesurable gaspille des cycles.

Meilleur modèle mental​

Traitez un skill comme ceci :

  • Prompt text = implémentation
  • Golden prompts = tests unitaires
  • Evaluator + test runs = checks de régression
  • Release note = changelog

Quand une équipe adopte ce modèle, la qualité des skills devient prévisible.

Template minimal pour votre prochain PR de skill​

Utilisez cette structure dans votre description de PR interne :

## Goal
What user job this skill solves.

## Behavior Contract
- Inputs
- Outputs
- Guardrails
- Refusal policy

## Test Set
- Golden prompts: N
- Edge cases included: yes/no

## Results
- Baseline pass rate: X%
- Candidate pass rate: Y%
- Known regressions: ...

## Decision
Promote / Hold / Roll back

Cela rend les changements de skills révisables avec les mêmes standards que le code.

Conclusion​

Le meilleur apport de la mise à jour Skill Creator d’Anthropic n’est pas une “génération plus intelligente”.

C’est le fait que les skills s’alignent désormais sur un cycle naturel pour développeurs :

design -> test -> evaluate -> refine -> release

Si votre équipe construit des workflows d’agents sérieux, c’est la méthode pour stopper le prompt drift et livrer des skills fiables.

Source​