Créateur de Skill

Un skill pour créer de nouveaux skills et les améliorer itérativement.

À haut niveau, le processus de création d'un skill se déroule comme suit :

Décider ce que le skill doit faire et à peu près comment il doit le faire
Rédiger un brouillon du skill
Créer quelques prompts de test et exécuter claude-with-access-to-the-skill sur ces prompts
Aider l'utilisateur à évaluer les résultats tant qualitativement que quantitativement
- Pendant que les exécutions se font en arrière-plan, rédiger quelques évaluations quantitatives s'il n'y en a pas (s'il y en a, vous pouvez les utiliser tels quels ou les modifier si vous estimez qu'il faut changer quelque chose). Puis les expliquer à l'utilisateur (ou s'ils existent déjà, expliquer ceux qui existent)
- Utiliser le script eval-viewer/generate_review.py pour montrer les résultats à l'utilisateur afin qu'il les examine, et aussi lui permettre de consulter les métriques quantitatives
Réécrire le skill en fonction des commentaires de l'utilisateur sur l'évaluation des résultats (et aussi s'il y a des défauts évidents qui ressortent des benchmarks quantitatifs)
Répéter jusqu'à satisfaction
Élargir l'ensemble de test et réessayer à plus grande échelle

Votre rôle en utilisant ce skill est de déterminer où se situe l'utilisateur dans ce processus, puis d'intervenir et de l'aider à progresser dans ces étapes. Par exemple, peut-être qu'il dit « Je veux créer un skill pour X ». Vous pouvez l'aider à affiner ce qu'il veut dire, rédiger un brouillon, créer les cas de test, déterminer comment il veut évaluer, exécuter tous les prompts et itérer.

D'un autre côté, peut-être qu'il a déjà un brouillon du skill. Dans ce cas, vous pouvez passer directement à la partie éval/itération de la boucle.

Bien sûr, vous devez toujours être flexible. Si l'utilisateur dit « Je n'ai pas besoin de lancer un tas d'évaluations, parlons juste ensemble », vous pouvez faire ça à la place.

Ensuite, après que le skill soit terminé (mais encore une fois, l'ordre est flexible), vous pouvez aussi lancer le skill description improver, pour lequel nous avons un script séparé, pour optimiser le déclenchement du skill.

Ça marche ? Ça marche.

Communication avec l'utilisateur

Le skill creator risque d'être utilisé par des personnes ayant une large gamme de familiarité avec le jargon informatique. S'il y a une tendance (et comment ne pas le savoir, c'est seulement très récemment que ça a commencé), c'est que la puissance de Claude inspire les plombiers à ouvrir leur terminal, les parents et grands-parents à googler « how to install npm ». D'un autre côté, la majorité des utilisateurs sont probablement assez versés en informatique.

Alors s'il vous plaît, faites attention aux indices de contexte pour comprendre comment formuler votre communication ! Par défaut, juste pour vous donner une idée :

« evaluation » et « benchmark » sont limites, mais OK
pour « JSON » et « assertion » vous voulez voir des indices sérieux de la part de l'utilisateur qu'il sait ce que c'est avant de les utiliser sans les expliquer

C'est OK de brièvement expliquer les termes si vous avez un doute, et n'hésitez pas à clarifier un terme avec une courte définition si vous n'êtes pas sûr que l'utilisateur le comprendra.

Créer un skill

Capturer l'intention

Commencez par comprendre l'intention de l'utilisateur. La conversation actuelle pourrait déjà contenir un workflow que l'utilisateur veut capturer (par exemple, il dit « en faire un skill »). Si c'est le cas, extrayez les réponses de l'historique de conversation d'abord — les outils utilisés, la séquence d'étapes, les corrections que l'utilisateur a apportées, les formats entrée/sortie observés. L'utilisateur devra peut-être compléter les lacunes, et devrait confirmer avant de passer à l'étape suivante.

Qu'est-ce que ce skill devrait permettre à Claude de faire ?
Quand ce skill doit-il se déclencher ? (quels phrases/contextes utilisateur)
Quel est le format de sortie attendu ?
Devrions-nous mettre en place des cas de test pour vérifier que le skill fonctionne ? Les skills avec des sorties objectivement vérifiables (transformations de fichiers, extraction de données, génération de code, étapes de workflow fixes) bénéficient de cas de test. Les skills avec des sorties subjectives (style d'écriture, art) n'en ont souvent pas besoin. Suggérez la valeur par défaut appropriée basée sur le type de skill, mais laissez l'utilisateur décider.

Entrevue et recherche

Posez proactivement des questions sur les cas limites, les formats entrée/sortie, les fichiers d'exemple, les critères de succès et les dépendances. Attendez pour rédiger les prompts de test jusqu'à ce que vous ayez bien compris cette partie.

Vérifiez les MCPs disponibles — si utiles pour la recherche (chercher dans la doc, trouver des skills similaires, chercher les bonnes pratiques), recherchez en parallèle via des subagents si disponibles, sinon inline. Arrivez préparé avec du contexte pour réduire la charge pour l'utilisateur.

Rédiger le SKILL.md

Basé sur l'entrevue utilisateur, remplissez ces composants :

name: Identifiant du skill
description: Quand se déclencher, ce qu'il fait. C'est le mécanisme de déclenchement principal — inclure à la fois ce que le skill fait ET des contextes spécifiques pour quand l'utiliser. Toute info « quand l'utiliser » va ici, pas dans le corps. Remarque : actuellement Claude a tendance à « sous-déclencher » les skills — à ne pas les utiliser quand ils seraient utiles. Pour combattre cela, rendez les descriptions de skill un peu « agressives ». Par exemple, au lieu de « How to build a simple fast dashboard to display internal Anthropic data. », vous pourriez écrire « How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.' »
compatibility: Outils requis, dépendances (optionnel, rarement nécessaire)
le reste du skill :)

Guide de rédaction de skill

Anatomie d'un skill

skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/    - Executable code for deterministic/repetitive tasks
    ├── references/ - Docs loaded into context as needed
    └── assets/     - Files used in output (templates, icons, fonts)

Progressive Disclosure

Les skills utilisent un système de chargement à trois niveaux :

Metadata (name + description) - Toujours en contexte (~100 mots)
SKILL.md body - En contexte à chaque fois que le skill se déclenche (<500 lignes idéalement)
Bundled resources - Au besoin (illimité, les scripts peuvent s'exécuter sans être chargés)

Ces limites de mots sont approximatives et vous pouvez vous permettre d'aller plus long si nécessaire.

Motifs clés :

Garder SKILL.md sous 500 lignes ; si vous approchez cette limite, ajoutez une couche supplémentaire de hiérarchie avec des pointeurs clairs sur où le modèle utilisant le skill devrait aller pour continuer.
Référencer clairement les fichiers depuis SKILL.md avec des conseils sur quand les lire
Pour les fichiers de référence volumineux (>300 lignes), inclure une table des matières

Organisation par domaine : Quand un skill supporte plusieurs domaines/frameworks, organisez par variante :

cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Claude lit uniquement le fichier de référence pertinent.

Principe du manque de surprise

Cela va de soi, mais les skills ne doivent pas contenir de malware, code d'exploitation ou tout contenu qui pourrait compromettre la sécurité du système. Le contenu d'un skill ne doit pas surprendre l'utilisateur dans son intention s'il est décrit. Ne pas accepter les demandes de créer des skills trompeurs ou conçus pour faciliter l'accès non autorisé, l'exfiltration de données ou d'autres activités malveillantes. Les trucs comme « roleplay as an XYZ » sont OK cependant.

Motifs d'écriture

Préférer la forme impérative dans les instructions.

Définir les formats de sortie - Vous pouvez le faire comme ceci :

## Report structure
ALWAYS use this exact template:
# [Title]
## Executive summary
## Key findings
## Recommendations

Motif d'exemples - C'est utile d'inclure des exemples. Vous pouvez les formater comme ceci (mais si « Input » et « Output » sont dans les exemples vous voudrez peut-être dévier un peu) :

## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

Style d'écriture

Essayez d'expliquer au modèle pourquoi les choses sont importantes plutôt que des MUST heavy-handed et étouffants. Utilisez la théorie de l'esprit et essayez de rendre le skill général et non super-étroit sur des exemples spécifiques. Commencez par rédiger un brouillon puis regardez-le avec un œil neuf et améliorez-le.

Cas de test

Après avoir rédigé le brouillon du skill, venez avec 2-3 prompts de test réalistes — le genre de choses qu'un vrai utilisateur dirait réellement. Partagez-les avec l'utilisateur : [vous n'avez pas à utiliser exactement ce langage] « Voici quelques cas de test que j'aimerais essayer. Est-ce que ça vous va, ou voulez-vous en ajouter ? » Puis exécutez-les.

Sauvegardez les cas de test dans evals/evals.json. Ne rédigez pas les assertions encore — juste les prompts. Vous rédigerez les assertions à l'étape suivante pendant que les exécutions se font en arrière-plan.

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}

Voir references/schemas.md pour le schéma complet (inclure le champ assertions, que vous ajouterez plus tard).

Exécuter et évaluer les cas de test

Cette section est une séquence continue — ne pas vous arrêter à mi-chemin. NE PAS utiliser /skill-test ou tout autre skill de test.

Mettre les résultats dans <skill-name>-workspace/ comme frère du répertoire skill. Dans le workspace, organiser les résultats par itération (iteration-1/, iteration-2/, etc.) et à l'intérieur de cela, chaque cas de test reçoit un répertoire (eval-0/, eval-1/, etc.). Ne pas créer tout cela à l'avance — juste créer les répertoires en chemin.

Étape 1 : Lancer toutes les exécutions (with-skill ET baseline) dans le même tour

Pour chaque cas de test, lancer deux subagents dans le même tour — l'un avec le skill, l'autre sans. C'est important : ne pas lancer les exécutions with-skill d'abord puis revenir pour les baselines plus tard. Lancer tout à la fois pour que tout se termine environ au même moment.

Exécution with-skill :

Execute this task:
- Skill path: <path-to-skill>
- Task: <eval prompt>
- Input files: <eval files if any, or "none">
- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Outputs to save: <what the user cares about — e.g., "the .docx file", "the final CSV">

Exécution baseline (même prompt, mais la baseline dépend du contexte) :

Créer un nouveau skill : pas de skill du tout. Même prompt, pas de chemin de skill, sauvegarder vers without_skill/outputs/.
Améliorer un skill existant : l'ancienne version. Avant de modifier, snapshot le skill (cp -r <skill-path> <workspace>/skill-snapshot/), puis pointer le subagent baseline vers le snapshot. Sauvegarder vers old_skill/outputs/.

Rédiger un eval_metadata.json pour chaque cas de test (les assertions peuvent être vides pour l'instant). Donner à chaque eval un nom descriptif basé sur ce qu'il teste — pas juste « eval-0 ». Utiliser ce nom pour le répertoire aussi. Si cette itération utilise des prompts de test nouveaux ou modifiés, créer ces fichiers pour chaque nouveau répertoire eval — ne pas assumer qu'ils se reportent des itérations précédentes.

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task prompt",
  "assertions": []
}

Étape 2 : Pendant que les exécutions progressent, rédiger les assertions

Ne pas simplement attendre que les exécutions se terminent — vous pouvez utiliser ce temps de manière productive. Rédiger les assertions quantitatives pour chaque cas de test et les expliquer à l'utilisateur. Si des assertions existent déjà dans evals/evals.json, les examiner et expliquer ce qu'elles vérifient.

Les bonnes assertions sont objectivement vérifiables et ont des noms descriptifs — elles devraient se lire clairement dans le viewer de benchmark pour que quelqu'un jetant un coup d'œil aux résultats comprenne immédiatement ce que chacune vérifie. Les skills subjectifs (style d'écriture, qualité du design) sont mieux évalués qualitativement — ne pas forcer les assertions sur les choses qui ont besoin de jugement humain.

Mettre à jour les fichiers eval_metadata.json et evals/evals.json avec les assertions une fois rédigées. Aussi expliquer à l'utilisateur ce qu'il verra dans le viewer — à la fois les sorties qualitatives et les benchmarks quantitatifs.

Étape 3 : À mesure que les exécutions se complètent, capturer les données de chronométrage

Quand chaque tâche de subagent se termine, vous recevez une notification contenant total_tokens et duration_ms. Sauvegarder immédiatement ces données vers timing.json dans le répertoire d'exécution :

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

C'est la seule opportunité de capturer ces données — elle vient par la notification de tâche et n'est pas persistée ailleurs. Traiter chaque notification à son arrivée plutôt que d'essayer de les regrouper.

Étape 4 : Noter, agréger et lancer le viewer

Une fois toutes les exécutions terminées :

Noter chaque exécution — lancer un subagent grader (ou noter inline) qui lit agents/grader.md et évalue chaque assertion contre les sorties. Sauvegarder les résultats vers grading.json dans chaque répertoire d'exécution. Le tableau expectations dans grading.json doit utiliser les champs text, passed et evidence (pas name/met/details ou autres variantes) — le viewer dépend de ces noms de champ exacts. Pour les assertions qui peuvent être vérifiées programmatiquement, écrire et exécuter un script plutôt que de l'eyeballer — les scripts sont plus rapides, plus fiables et réutilisables sur les itérations.
Agréger dans benchmark — lancer le script d'agrégation depuis le répertoire skill-creator :
```
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
```
Cela produit benchmark.json et benchmark.md avec pass_rate, time, et tokens pour chaque configuration, avec mean ± stddev et le delta. Si générer benchmark.json manuellement, voir references/schemas.md pour le schéma exact que le viewer attend. Mettre chaque version with_skill avant sa contrepartie baseline.
Faire une passe d'analyst — lire les données de benchmark et mettre en évidence les motifs que les stats d'agrégation pourraient cacher. Voir agents/analyzer.md (la section « Analyzing Benchmark Results ») pour ce qu'il faut chercher — les choses comme les assertions qui passent toujours indépendamment du skill (non-discriminant), les evals à haute variance (possiblement flaky) et les trade-offs temps/token.
Lancer le viewer avec à la fois les sorties qualitatives et les données quantitatives :
```
nohup python <skill-creator-path>/eval-viewer/generate_review.py \
  <workspace>/iteration-N \
  --skill-name "my-skill" \
  --benchmark <workspace>/iteration-N/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!
```
Pour l'itération 2+, aussi passer --previous-workspace <workspace>/iteration-<N-1>.

Environnements Cowork / headless : Si webbrowser.open() n'est pas disponible ou que l'environnement n'a pas d'affichage, utiliser --static <output_path> pour écrire un fichier HTML autonome au lieu de démarrer un serveur. Les retours seront téléchargés comme fichier feedback.json quand l'utilisateur clique sur « Submit All Reviews ». Après le téléchargement, copier feedback.json dans le répertoire workspace pour la prochaine itération.

Note : veuillez utiliser generate_review.py pour créer le viewer ; pas besoin d'écrire du HTML personnalisé.

Dire à l'utilisateur quelque chose comme : « J'ai ouvert les résultats dans votre navigateur. Il y a deux onglets — 'Outputs' vous permet de cliquer sur chaque cas de test et de laisser des commentaires, 'Benchmark' montre la comparaison quantitative. Quand vous avez terminé, revenez ici et faites-moi savoir. »

Ce que l'utilisateur voit dans le viewer

L'onglet « Outputs » montre un cas de test à la fois :

Prompt : la tâche qui a été donnée
Output : les fichiers que le skill a produits, affichés inline où possible
Previous Output (itération 2+) : section réduite montrant la sortie de la dernière itération
Formal Grades (si la notation a été exécutée) : section réduite montrant le passage/échec de l'assertion
Feedback : une zone de texte qui auto-sauvegarde au fur et à mesure qu'ils tapent
Previous Feedback (itération 2+) : leurs commentaires d'avant, affichés sous la zone de texte

La navigation se fait via les boutons prev/next ou les flèches du clavier. Quand terminé, ils cliquent sur « Submit All Reviews » qui sauvegarde tous les commentaires vers feedback.json.

Étape 5 : Lire les commentaires

Quand l'utilisateur vous dit qu'il a terminé, lire feedback.json :

{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "the chart is missing axis labels", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "perfect, love this", "timestamp": "..."}
  ],
  "status": "complete"
}

Les commentaires vides signifient que l'utilisateur pensait que c'était bien. Concentrez vos améliorations sur les cas de test où l'utilisateur avait des plaintes spécifiques.

Arrêter le serveur du viewer quand vous avez terminé :

kill $VIEWER_PID 2>/dev/null

Améliorer le skill

C'est le cœur de la boucle. Vous avez exécuté les cas de test, l'utilisateur a examiné les résultats, et maintenant vous devez améliorer le skill en fonction de ses commentaires.

Comment penser aux améliorations

Généraliser à partir des commentaires. La grosse image qui se passe ici c'est qu'on essaie de créer des skills qui peuvent être utilisés un million de fois (peut-être littéralement, peut-être même plus qui sait) sur beaucoup de différents prompts. Ici vous et l'utilisateur itérez seulement sur quelques exemples encore et encore parce que ça aide à accélérer. L'utilisateur connaît ces exemples à fond et c'est rapide pour lui d'évaluer les nouvelles sorties. Mais si le skill que vous et l'utilisateur codéveloppez fonctionne seulement pour ces exemples, c'est inutile. Plutôt que de faire des changements fiddly overfitty, ou constrains oppressively restrictives, s'il y a un problème opiniâtre, vous pourriez essayer de brancher et d'utiliser différentes métaphores, ou recommander différents motifs de travail. C'est relativement bon marché à essayer et peut-être vous atterrirez sur quelque chose de super.
Garder le prompt maigre. Supprimer les choses qui ne tirent pas leur poids. Assurez-vous de lire les transcriptions, pas juste les sorties finales — s'il semble que le skill fait gaspiller au modèle beaucoup de temps en faisant des choses improductives, vous pouvez essayer de supprimer les parties du skill qui le font faire ça et voir ce qui se passe.
Expliquer le pourquoi. Essayez dur d'expliquer le pourquoi derrière tout ce que vous demandez au modèle de faire. Les LLM actuels sont intelligents. Ils ont une bonne théorie de l'esprit et quand donnés un bon harnais peuvent aller au-delà des instructions rotes et vraiment faire arriver les choses. Même si les commentaires de l'utilisateur sont terse ou frustrés, essayez de réellement comprendre la tâche et pourquoi l'utilisateur écrit ce qu'il a écrit, et ce qu'il a réellement écrit, et puis transmettez cette compréhension dans les instructions. Si vous vous trouvez à écrire ALWAYS ou NEVER en majuscules, ou à utiliser des structures super rigides, c'est un drapeau jaune — si possible, reformulez et expliquez le raisonnement pour que le modèle comprenne pourquoi la chose que vous demandez est importante. C'est une approche plus humaine, puissante et efficace.
Chercher le travail répété sur les cas de test. Lire les transcriptions des exécutions de test et remarquer si les subagents ont tous indépendamment écrit des scripts helper similaires ou pris la même approche multi-étape pour quelque chose. Si tous les 3 cas de test ont résulté en le subagent écrivant un create_docx.py ou un build_chart.py, c'est un signal fort que le skill devrait inclure ce script. L'écrire une fois, le mettre dans scripts/, et dire au skill de l'utiliser. Cela sauve chaque invocation future de réinventer la roue.

Cette tâche est assez importante (on essaie de créer des milliards par an en valeur économique ici !) et votre temps de pensée n'est pas le goulot — prenez votre temps et réfléchissez vraiment à fonds. Je suggérerais d'écrire un brouillon de révision puis de le regarder à neuf et de faire des améliorations. Essayez vraiment de vous mettre à la place de l'utilisateur et de comprendre ce qu'il veut et dont il a besoin.

La boucle d'itération

Après avoir amélioré le skill :

Appliquer vos améliorations au skill
Relancer tous les cas de test dans un nouveau répertoire iteration-<N+1>/, incluant les exécutions baseline. Si vous créez un nouveau skill, la baseline est toujours without_skill (pas de skill) — cela reste le même sur les itérations. Si vous améliorez un skill existant, utiliser votre jugement sur ce qui a du sens comme baseline : la version originale avec laquelle l'utilisateur est venu, ou l'itération précédente.
Lancer le reviewer avec --previous-workspace pointant vers l'itération précédente
Attendre que l'utilisateur examine et vous dise qu'il a terminé
Lire les nouveaux commentaires, améliorer à nouveau, répéter

Continuer jusqu'à :

L'utilisateur dit qu'il est satisfait
Les commentaires sont tous vides (tout semble bon)
Vous ne faites pas de progrès significatif

Avancé : Comparaison en aveugle

Pour les situations où vous voulez une comparaison plus rigoureuse entre deux versions d'un skill (par exemple, l'utilisateur demande « la nouvelle version est-elle vraiment meilleure ? »), il y a un système de comparaison en aveugle. Lire agents/comparator.md et agents/analyzer.md pour les détails. L'idée de base est : donner deux sorties à un agent indépendant sans lui dire lesquelles sont lesquelles, et le laisser juger la qualité. Puis analyser pourquoi le gagnant a gagné.

C'est optionnel, nécessite des subagents, et la plupart des utilisateurs n'en auront pas besoin. La boucle de review humain est généralement suffisante.

Optimisation de description

Le champ description dans le frontmatter SKILL.md est le mécanisme principal qui détermine si Claude invoque un skill. Après avoir créé ou amélioré un skill, offrir d'optimiser la description pour une meilleure précision de déclenchement.

Étape 1 : Générer les queries d'éval de déclenchement

Créer 20 queries d'éval — un mélange de should-trigger et should-not-trigger. Sauvegarder en JSON :

[
  {"query": "the user prompt", "should_trigger": true},
  {"query": "another prompt", "should_trigger": false}
]

Les queries doivent être réalistes et quelque chose qu'un utilisateur Claude Code ou Claude.ai taperait réellement. Pas des demandes abstraites, mais des demandes concrètes et spécifiques avec une bonne quantité de détail. Par exemple, chemins de fichiers, contexte personnel sur le job ou la situation de l'utilisateur, noms de colonnes et valeurs, noms de compagnie, URLs. Un petit peu de backstory. Certains pourraient être en minuscules ou contenir des abréviations ou des typos ou du speech casual. Utiliser un mélange de différentes longueurs, et se concentrer sur les cas limites plutôt que de les rendre clairs.

Mauvais : "Format this data", "Extract text from PDF", "Create a chart"

Bon : "ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think"

Pour les queries should-trigger (8-10), penser à la couverture. Vous voulez différentes formulations de la même intention — formelles, cassuelles. Inclure les cas où l'utilisateur n'énonce pas explicitement le skill ou le type de fichier mais clairement en a besoin. Jeter quelques cas d'usage peu courants et cas où ce skill entre en concurrence avec un autre mais devrait gagner.

Pour les queries should-not-trigger (8-10), les plus précieuses sont les near-misses — queries qui partagent des mots-clés ou concepts avec le skill mais qui ont en fait besoin de quelque chose de différent. Penser domaines adjacents, formulation ambiguë où une correspondance de mots-clés naive déclencherait mais ne devrait pas, et cas où la query touche quelque chose que le skill fait mais dans un contexte où un autre outil est plus approprié.

Le truc clé à éviter : ne pas faire les queries should-not-trigger évidemment non pertinentes. « Write a fibonacci function » comme cas négatif pour un skill PDF c'est trop facile — ça ne teste rien. Les cas négatifs devraient être réellement tricky.

Étape 2 : Examiner avec l'utilisateur

Présenter l'ensemble d'éval à l'utilisateur pour examen en utilisant le template HTML :

Lire le template depuis assets/eval_review.html
Remplacer les placeholders :
- __EVAL_DATA_PLACEHOLDER__ → le tableau JSON des items d'éval (pas de guillemets autour — c'est une assignation de variable JS)
- __SKILL_NAME_PLACEHOLDER__ → le nom du skill
- __SKILL_DESCRIPTION_PLACEHOLDER__ → la description actuelle du skill
Écrire vers un fichier temporaire (par exemple, /tmp/eval_review_<skill-name>.html) et l'ouvrir : open /tmp/eval_review_<skill-name>.html
L'utilisateur peut modifier les queries, basculer should-trigger, ajouter/retirer les entrées, puis cliquer sur « Export Eval Set »
Le fichier télécharge