self-eval

Présentation du self-eval skill

À quoi sert self-eval

Le self-eval skill est un skill Claude Code entièrement basé sur un prompt, conçu pour obtenir une évaluation honnête après coup. Il aide un agent IA à examiner sa propre production après une tâche, une revue de code, une session d’implémentation, une passe de débogage ou un travail de planification, sans tomber dans les compliments vagues ni les notes gonflées du type “4/5”.

Plutôt que de demander “à quel point est-ce bon ?” sur une seule échelle subjective, self-eval sépare l’évaluation en deux axes : l’ambition de la tâche et la qualité d’exécution. C’est utile quand vous avez besoin d’une réponse calibrée à la question : “Est-ce vraiment du travail solide, ou simplement un résultat correct sur une tâche facile ?”

Utilisateurs et cas d’usage les plus adaptés

Utilisez le self-eval skill si vous voulez qu’un agent relise un travail terminé avant de l’accepter, de le merger ou de continuer à construire dessus. Il est particulièrement pertinent pour les équipes d’ingénierie qui utilisent l’IA pour générer du code, refactorer, trier des issues, écrire des tests ou analyser une architecture.

Il ne remplace pas les suites de tests, la revue humaine, l’audit de sécurité ni la validation en production. Sa valeur tient à l’autocritique structurée : limiter l’excès de confiance, faire remonter les faiblesses et créer un historique de scores d’une session de travail à l’autre.

Ce qui le distingue d’un prompt classique

Un prompt classique du type “évalue ton travail” produit souvent des points positifs génériques, quelques réserves modérées et une note optimiste. self-eval ajoute des contraintes qui rendent l’inflation plus difficile : raisonnement obligatoire en mode avocat du diable, matrice de notation fixe et persistance des scores dans .self-eval-scores.jsonl.

Cette persistance compte. Si les évaluations récentes se regroupent de façon trop serrée, le skill peut signaler des schémas de notation trop généreuse au lieu de traiter chaque revue comme un cas isolé.

Comment utiliser le self-eval skill

Installation de self-eval et vérification du dépôt

Installez-le depuis la source GitHub du skill avec votre gestionnaire de skills, par exemple :

npx skills add alirezarezvani/claude-skills --skill self-eval

Le chemin pertinent dans le dépôt est :

engineering/skills/self-eval/SKILL.md

Dans la structure actuelle, il n’y a pas de dépendances externes, de scripts d’aide, de règles embarquées ni de fichiers de référence. Pour une revue rapide avant installation, commencez par lire SKILL.md : le fichier contient le modèle de notation, le workflow et les attentes de sortie. Comme il s’agit d’un skill uniquement basé sur un prompt, le risque d’adoption est faible, mais la qualité des résultats dépend fortement du contexte que vous lui fournissez.

Entrées dont le skill a besoin

Pour obtenir une utilisation pertinente de self-eval, ne vous contentez pas de dire “évalue ceci”. Donnez à l’agent le travail terminé et le standard selon lequel il doit être jugé.

Les entrées solides incluent :

• La demande utilisateur initiale ou la description de l’issue
• La réponse finale, le patch, le plan ou la revue produit par l’agent
• Les contraintes pertinentes, par exemple les délais, règles de style, exigences de test ou approches interdites
• Les éléments de validation, comme les tests exécutés, fichiers modifiés, commandes lancées ou lacunes connues
• Le public visé : maintainer, reviewer, product owner, utilisateur débutant ou équipe production

Un prompt faible demande une note. Un prompt solide donne au skill assez d’éléments pour distinguer “peu ambitieux mais propre” de “ambitieux mais incomplet”.

Modèle de prompt pour de meilleurs résultats

Utilisez self-eval une fois le travail terminé, pas avant. Un prompt pratique ressemble à ceci :

Use the self-eval skill to evaluate the work below. Original task: [goal]. Output produced: [answer or diff summary]. Constraints: [tests, style, repo rules]. Validation performed: [commands or none]. Known concerns: [risks]. Give the two-axis evaluation, devil's advocate reasoning, final matrix score, and concrete follow-up actions.

Cette structure améliore le résultat parce qu’elle empêche le modèle d’évaluer seulement le ton ou l’effort. Elle force la revue à prendre en compte l’ambition, l’exécution, les preuves disponibles et les risques non résolus.

Workflow conseillé

Lancez self-eval aux points de contrôle où une évaluation faussement positive coûterait cher :

1. Terminez la tâche ou rédigez la solution.
2. Demandez une self-eval en fournissant l’objectif initial et les preuves du travail réalisé.
3. Lisez la section avocat du diable avant la note finale.
4. Transformez les faiblesses en courte liste de corrections.
5. Relancez uniquement après des changements significatifs, pas après de simples retouches cosmétiques.

Si .self-eval-scores.jsonl est créé dans votre répertoire de travail, traitez-le comme un historique local d’évaluation. Décidez si votre équipe souhaite committer ce fichier, l’ignorer ou le relire périodiquement.

FAQ du self-eval skill

self-eval sert-il à la Model Evaluation ou à la qualité du code ?

Il peut servir aux deux, mais dans un sens précis. self-eval for Model Evaluation doit être compris comme une évaluation au niveau de la tâche du travail produit par un agent IA, et non comme une mesure de modèle de niveau benchmark. Il peut aider à comparer des sessions, détecter des auto-notations gonflées et améliorer la discipline de revue, mais il ne remplace pas les harnais d’évaluation formels, les jeux de données de référence ni les scores annotés par des humains.

Quand ne faut-il pas utiliser self-eval ?

Ne l’utilisez pas comme seul point de contrôle pour des travaux à risque élevé : changements sensibles côté sécurité, contenus juridiques ou médicaux, migrations de production, ou tout élément nécessitant une exactitude vérifiée. Évitez-le aussi lorsqu’il n’existe aucun artefact concret à évaluer. Le skill a besoin d’une tâche, d’une sortie et de critères d’évaluation ; sinon, il produira quand même une structure, mais avec des preuves faibles.

Est-ce adapté aux débutants ?

Oui, parce qu’il repose uniquement sur un prompt et n’a aucune dépendance d’outillage. Les débutants devraient tout de même lire SKILL.md avant de l’utiliser, en particulier la logique de notation. La principale courbe d’apprentissage n’est pas l’installation ; c’est la capacité à fournir assez de contexte pour que l’évaluation ne repose pas sur une impression générale.

En quoi est-ce différent d’une simple demande de critique ?

Une critique peut lister des problèmes sans notation calibrée. self-eval utilise un modèle à deux axes et une note finale verrouillée par une matrice, ce qui laisse moins de liberté à l’agent pour justifier la note qui lui “semble” juste. L’étape avocat du diable impose aussi d’argumenter à la fois pour une note plus élevée et pour une note plus basse avant de trancher.

Comment améliorer le self-eval skill

Fournir à self-eval des preuves plus solides

La meilleure manière d’améliorer les résultats de self-eval est de rendre les preuves concrètes. Incluez les fichiers modifiés, les tests en échec ou réussis, les omissions importantes et les critères d’acceptation. Si aucun test n’a été lancé, dites-le. Si la réponse a volontairement laissé de côté une exigence, indiquez-le aussi.

Une meilleure entrée ne veut pas dire une entrée plus longue ; cela veut dire une entrée évaluable. “Refactored auth code” est faible. “Refactored auth/session.ts to remove duplicated token parsing; ran npm test -- auth; did not test OAuth callback manually” donne au skill quelque chose de réel à noter.

Surveiller les modes d’échec courants

L’échec le plus fréquent consiste à laisser le modèle récompenser l’effort plutôt que le résultat. Un autre consiste à considérer qu’une tâche difficile, mais seulement partiellement exécutée, est automatiquement forte. self-eval est conçu pour résister à ces biais, mais seulement si l’utilisateur fournit l’ambition initiale et le livrable réel.

Surveillez aussi le bruit dans l’historique des scores. Si .self-eval-scores.jsonl mélange des types de tâches sans rapport, les signaux de regroupement peuvent perdre en pertinence. Une passe de finition sur de la documentation et une migration complexe ne devraient pas être interprétées comme équivalentes simplement parce qu’elles partagent une note numérique.

Passer du score à l’action

Ne vous arrêtez pas à la note finale. La sortie utile est l’écart entre l’ambition et l’exécution. Transformez cet écart en prompt de correction :

Based on the self-eval weaknesses, revise the work to address the top three execution gaps. Do not expand scope. Preserve the original constraints and report what changed.

Cela garde l’itération suivante bien ciblée. Cela empêche aussi l’agent “d’améliorer” le travail en ajoutant des fonctionnalités sans rapport pour courir après une meilleure note.

Personnaliser avec prudence

Si vous adaptez le self-eval skill, conservez les éléments qui créent la calibration : axes séparés, raisonnement en avocat du diable, correspondance fixe des scores et prise en compte de l’historique de notation. Personnaliser les libellés, le format de sortie ou les critères d’acceptation propres à l’équipe est généralement sûr. Supprimer les contraintes qui obligent le modèle à argumenter contre lui-même fera ressembler le skill à un prompt de revue ordinaire.