Zhr65/SkillFresh

Auditeur de Compétence — Évaluation de la Dépréciation et de l'Adéquation des Capacités d'Agent

Aperçu

Une compétence est un actif qui se déprécie. Les versions de modèle sortent tous les quelques mois. Une compétence qui a réussi le trimestre dernier peut régresser silencieusement — forme de sortie incorrecte, appels d'outils cassés, déclencheurs manqués — et personne ne dit à l'utilisateur que son agent est devenu moins performant.

Cette compétence est la méthodologie d'évaluation. Elle répond à trois questions :

1. Une compétence se dégrade-t-elle ? — régression des capacités entre les versions de modèle.
2. Une nouvelle compétence est-elle réellement bonne ? — efficacité vs coût.
3. Une compétence convient-elle À CET utilisateur ? — précision des déclencheurs + environnement + style.

Elle fournit cinq points d'entrée exécutables :

• scripts/console.py — la console résidente (couche de données) : maintient registry.<host>.json par hôte, détecte les changements de version de modèle (bump/check), et émet le panneau de recommandation/élimination. Voir USAGE.md pour l'ensemble complet des commandes.
• scripts/regress.py — à partir des résultats de rejeu d'un ensemble de référence, calcule la matrice de taux de réussite, signale la dégradation (seuil + direction), et signale FINGERPRINT-DRIFT lorsqu'un actif a été modifié à la place.
• scripts/baseline.py — échafaude une liste de contrôle de rejeu, puis fusionne les verdicts enregistrés dans baseline-results.json (par actif ; --replace pour un remplacement complet). Les cas de référence provisoires sont ignorés sauf si --allow-draft.
• scripts/fingerprint.py — CLI de rapport autonome ; une fine enveloppe autour du même code de hachage utilisé par scan. Elle écrit fingerprint-report.* uniquement ; elle n'écrit pas le registre.
• scripts/install.py — installe cette compétence dans chaque hôte d'agent sur la machine (~/.workbuddy-ai/skills, ~/.claude/skills, ~/.agents/skills, ~/.dsh/skills, ~/.codex/skills). Vérifie après l'installation ; ne laisse jamais de répertoire vide derrière ; ne copie jamais de données personnelles.

Principe fondamental : Pas de mesure sans référence. Dégradation = baisse significative du taux de réussite sous une empreinte inchangée — jamais "semble moins performant".

Architecture Multi-Hôte (skills vs plugins)

Un moteur central, des adaptateurs par hôte. La même logique d'empreinte / référence / régression / recommandation / suggestion de besoin s'exécute partout ; un adaptateur sait seulement où vivent les actifs et comment lire leur manifeste.

hôte	type	racine par défaut	manifeste
workbuddy	skill	racine des skills qui contient cette compétence	SKILL.md
claude-code	skill	~/.claude/skills	SKILL.md
deepseek	plugin	~/.dsh/profiles/desktop (lit les dépendances package.json)	package.json / plugin.json
generic	actif	passer --root	plugin.json / manifest.json / SKILL.md / package.json

• Chaque hôte conserve son propre registre : registry.<host>.json — pas d'écrasement inter-hôte.
• Les résultats de référence + les ensembles de référence sont partagés, indexés par nom d'actif.
• Exécutez avec --host <name> --root <path> ; ajoutez des hôtes personnalisés dans hosts.json.
• console.py hosts montre chaque profil, sa racine résolue et le nombre d'actifs détectés.

Donc dans WorkBuddy, vous évaluez les skills ; dans DeepSeek harness, vous évaluez les plugins — mêmes commandes, adaptateur différent. Ajouter un nouvel hôte est une entrée hosts.json (type + racine + noms de fichiers de manifeste), aucun changement de code.

Quand Utiliser

• Avant de déployer une nouvelle skill ou un nouveau plugin ("做个 skill，按评测流程走").
• Après une mise à jour de version de modèle, pour vérifier si les skills existantes ont régressé.
• Quand une skill "semble bizarre" — confirmez avec des données, pas avec des impressions.
• Quand vous décidez de conserver / réécrire / retirer une skill.
• Quand vous recommandez une skill ou un plugin à un utilisateur (adéquation + preuves).

Quand NE PAS utiliser : tâches uniques sans skill réutilisable ; documentation purement narrative.

Concept Clé : L'Empreinte de Version

L'empreinte est la ligne de la matrice de dépréciation.

fingerprint = hash(contenu des fichiers de surface de capacités + chemin relatif) # calibre v2-ability-surface

Ce qui constitue la surface de capacités (les fichiers dont la modification change réellement le comportement) :

• inclus : SKILL.md, scripts/*, lib/*, dist/*, package.json, plugin.json, cordis.patch.yml, templates
• exclus : README*, CHANGELOG*, LICENSE*, images/audio/fonts, *.map, lockfiles, node_modules/, test*/, docs/

Pourquoi exclure : une modification du README ne change pas la capacité, mais son hachage fait bouger l'empreinte et produit un faux FINGERPRINT-DRIFT ("l'actif a été modifié") alors que rien de fonctionnel n'a changé. Les plugins aggravent ce problème — un plugin installé peut transporter 16 Mo de sortie groupée plus un README de 57 Ko.

Règles :

• Empreinte inchangée ⇒ la ligne persiste ; une baisse du taux de réussite est une régression du modèle.
• Empreinte modifiée ⇒ le changement est de la responsabilité de la skill elle-même, pas du modèle. Les anciennes et nouvelles lignes coexistent, donc les modifications de skill ne sont jamais attribuées à tort à une dérive du modèle.

Exécutez python scripts/console.py scan pour calculer les empreintes et les stocker dans le registre. fingerprint.py est une enveloppe de rapport autonome ; elle ne touche pas au registre.

Surface de Capacité (pourquoi les plugins ont besoin d'un second axe)

L'empreinte indique "les fichiers ont-ils changé ?". Elle ne peut pas dire "offre-t-il toujours la même chose ?". scan enregistre donc également une surface de capacité par actif et la compare avec l'analyse précédente :

Type d'actif	Ce que la surface enregistre
plugin	patch (dsh.bundle.patch), main/module, bin, exports, deps, skills, mcp, hooks, insert (lignes cordis), scripts
skill	tools (nombre d'outils autorisés), scripts

Quand elle change, scan l'affiche explicitement :

[caps] 1 actif a une surface de capacité modifiée ("ce qu'il offre à l'extérieur a changé", sans rapport avec le taux de réussite) :
       plug-a                                   +bin

Pourquoi c'est important pour les plugins : un plugin se dégrade en n'enregistrant pas ses outils / en retournant des erreurs 404 sur ses routes / en n'exécutant pas ses hooks — pas en "répondant moins bien". Un ensemble de référence de prompts mesure la mauvaise chose pour un plugin. Le diff de surface détecte "la v1.1.0 a supprimé un point d'entrée" sans avoir besoin de démarrer l'hôte.

Limite connue (ne pas la masquer) : la surface est une capacité déclarée, pas une capacité observée. Pour un plugin dont le manifeste ment (déclare un correctif qui échoue à charger), cela ne peut pas le détecter.

Preuve d'Exécution (le troisième axe, et ce qu'il ne peut pas faire)

Il existe deux choses très différentes appelées "une sonde d'exécution". Ne les confondez pas :

	Sonde Active (active probe)	Preuve Passive (passive evidence) — implémentée
ce qu'elle fait	démarrer l'hôte, demander "quels outils avez-vous réellement enregistrés"	lire le journal que l'hôte écrit déjà
coût	Le profil desktop de DSH est exclusif à Electron — dsh --profile desktop --dump-config est refusé ; pas d'entrée sans tête → rétro-ingénierie de l'IPC ou pilotage de l'interface	une lecture de fichier, ~10 ms
détecte	tout, y compris un plugin dont le manifeste ment	tout ce que le plugin a journalisé
statut	non construite	console.py probe / skill_audit_probe

probe lit ~/.dsh/logs/*.log (configurable par hôte via "logs" dans hosts.json), analyse <iso> [niveau] [source] message, attribue les lignes dont la source correspond à un nom d'actif installé, et signale les lignes correspondant au vocabulaire d'échec (fail|error|ENOENT|unavailable|timeout|…).

Véritable détection, sur cette machine :

@wxg-prc-cpg/browser-skill-dsh-plugin   2 signes de dysfonctionnement
  échec de la sonde bsk (spawn bsk ENOENT) ; les outils navigateur signaleront des conseils d'installation…

Fichiers présents, manifeste valide, caps=4 — toutes les vérifications statiques réussissent. Le plugin est chargé et ses outils sont enregistrés, mais ils ne peuvent pas fonctionner : le CLI bsk auquel il délègue n'est pas dans le PATH. Aucune quantité de hachage de fichiers ne trouve cela.

Angles morts (les énoncer, ne jamais les cacher) : un plugin qui ne journalise rien est invisible ; la rotation des journaux efface les anciens défauts ; un plugin que personne n'a utilisé n'a aucune preuve ; les défauts de niveau info sont détectés par correspondance de mots-clés, donc les manquements et les faux positifs sont possibles. L'absence de preuve n'est pas une preuve de bonne santé — probe affiche cette phrase elle-même plutôt qu'un crochet vert.

Implémenté vs Méthodologie Seulement (ne pas brouiller cette ligne)

La méthodologie ci-dessous est plus large que le code. Les utilisateurs doivent savoir quelle moitié ils tiennent :

Domaine	Statut
Empreinte sur la surface de capacité, scan/status, diff de capacité	implémenté
Échafaudage de référence + ingestion de référence (fusion par actif, garde provisoire)	implémenté (baseline.py)
Matrice de taux de réussite, seuil ≥20pp + direction, FINGERPRINT-DRIFT	implémenté (regress.py)
Détection de changement de modèle (bump/check), horodatages par hôte	implémenté — mais la source de l'événement est manuelle ; un check programmé reste vert jusqu'à ce que quelqu'un fasse un bump
Panneau de recommandation/élimination, suggestion de besoin, brouillons extraits de l'historique	implémenté (heuristique ; les suggestions ne sont pas des preuves)
Preuve d'exécution à partir des journaux de l'hôte	implémentée (passive ; seulement ce que le plugin a journalisé)
Ablation, taux d'adoption en mode silencieux, valeur nette / télémétrie des jetons	méthodologie seulement — pas de code
Précision/rappel des déclencheurs, réconciliation d'environnement, référence de style	méthodologie seulement — pas de code
Rejeux K≥3, validation croisée par juge LLM	non implémenté ; les verdicts actuels sont une auto-évaluation K=1
colonne risque	proxy de surface de maintenance — pas la valeur

Si une affirmation dans ce fichier ne peut pas être attribuée à une ligne marquée "implémenté", traitez-la comme un conseil pour l'humain qui réalise l'audit, pas comme quelque chose que l'outil fera pour lui.

Jugement 1 — Dégradation des Capacités

Quatre étapes :

1. Construire l'ensemble de référence à partir de l'historique, pas à la main. Extraire les sessions passées : adoption par l'utilisateur sans opposition → rejeu positif ; opposition de l'utilisateur / demande de réécriture → négatif. Le rejeu EST la régression. L'historique d'utilisation propre de l'utilisateur est le corpus — pas d'ensemble de test inventé.
2. Exécuter les deux modèles sur le même ensemble de référence, K≥3 (cas de notation par juge LLM : K≥5, car le juge est bruyant). Enregistrer le taux de réussite par (empreinte, version de modèle).
3. Règle de décision : baisse ≥20pp ET cohérente dans la direction → signaler une dégradation ; en dessous du seuil → "surveillance de volatilité". Cela transforme "cette sortie est bizarre" en un critère reproductible.
4. Attribuer, ne pas seulement signaler. Inspecter les artefacts intermédiaires :
   • Erreur d'appel d'outil / format modifié → corriger la description de l'outil.
   • Structure de sortie correcte, contenu faux → réécrire les instructions.
   • Aurait dû se déclencher mais ne l'a pas fait → corriger la description du déclencheur.
   • Tous les intermédiaires corrects, seul le final est faux → régression interne du modèle ; marquer la skill "dépendante d'un seul modèle", attendre la correction du modèle.

La ligne "7 dégradées, 2 recommandées pour réécriture" est le sous-ensemble attribuable de la sortie de l'étape 4 — c'est ce qui rend le rapport exploitable.

Jugement 2 — Une Nouvelle Skill est-elle Bonne ?

Diviser en deux axes mesurables : efficacité (meilleurs résultats) et économie (coût réduit).

1. Ablation pré-déploiement. Même lot de tâches, deux bras : A sans la skill, B avec la skill. Enregistrer le taux de réussite, le nombre de corrections humaines, le coût en jetons. bénéfice net = augmentation_du_taux_de_réussite × fréquence_de_la_tâche − coût_marginal Une skill qui augmente le succès de 30% mais se déclenche 3×/an à +50k jetons chacun est un passif, pas un actif.
2. Mode silencieux post-déploiement. La nouvelle skill s'exécute en silence : produit des suggestions mais ne les exécute pas automatiquement ; journalise "ce qui se serait passé". Surveiller le taux d'adoption (accepté vs remplacé). Le taux d'adoption est le juge ultime du "bon", plus honnête que n'importe quelle métrique hors ligne. Limite : les skills d'opérations d'écriture (supprimer un fichier, envoyer un email) ne peuvent que simuler/annoter en mode silencieux, jamais réellement s'exécuter.
3. Fiche de valeur nette. Un tableau de bord par skill : nombre d'appels, taux de réussite, taux d'adoption, moyenne de jetons, bénéfice net cumulé. 90 jours nets négatifs → suggérer une réécriture ou un retrait. C'est le côté consommateur de la table de dépréciation.

Jugement 3 — Convient-elle À CET Utilisateur ?

"Vous convient" = déclencheurs précis + hypothèses vérifiées + style correspondant. Le tout automatisable :

1. Précision du déclencheur (affecte le plus la sensation, est le plus souvent ignoré). Échantillonner les positifs de l'historique (devrait se déclencher) et les négatifs (similaires, ne devrait pas — "corriger ce bug" vs "expliquer ce qu'est un bug"). Rejeu → précision/rappel. Faible précision = ennuyeux (sur-déclenchement) ; faible rappel = installation inutile. D'abord, étiqueter manuellement 10–20, puis semi-auto, zéro coût LLM.
2. Réconciliation d'environnement (installé ≠ s'exécute). Les métadonnées de la skill déclarent les dépendances : quels outils / MCP / autorisations / habitudes de chemin / langage, plus les hypothèses implicites de capacité du modèle (contexte long, exécution de code, multimodal). Réconcilier avec l'environnement réel de l'utilisateur ; manquant → drapeau rouge. "Suppose macOS", "produit en japonais", "nécessite 200k de contexte" — les hypothèses invisibles sont la raison n°1 pour laquelle une skill reste inutilisée. Cela alimente également le Jugement 1 : une hypothèse de capacité qui échoue = dégradation silencieuse.
3. Référence de style (poids le plus bas). Utiliser la sortie historique de l'utilisateur + USER.md comme référence ; le juge LLM compare le format, la langue, la verbosité. Utilisé uniquement pour départager des skills à score égal.

Flux de Travail Intégré (pour "créer une nouvelle skill")

Lorsque l'utilisateur demande de créer une skill, exécuter le protocole en ligne avant de la fournir :

1. Réconciliation d'environnement — l'environnement de l'utilisateur satisfait-il les dépendances déclarées + les hypothèses de capacité de la skill ?
2. Rejeu du déclencheur — rejouer 10 à 20 cas échantillonnés ; rapporter la précision/le rappel.
3. Ablation — sur un petit lot de tâches, mesurer l'amélioration par rapport au coût.
4. Entrer en surveillance — en cas de succès, enregistrer l'empreinte + l'ensemble de référence ; la console résidente réexécute à chaque mise à jour de modèle.

Suggestion Basée sur le Besoin (quand aucune skill ne correspond)

C'est le comportement "étagère vide" : un utilisateur (surtout celui qui a zéro skill/plugin) demande quelque chose qu'aucune skill installée ne couvre. Ne dites pas simplement "je ne peux pas" — mettez en évidence le manque et proposez de le combler.

1. Détecter le besoin à partir de la conversation : type de tâche + domaine (par exemple "rapport financier trimestriel" → finance/analyse ; "supprimer le ton IA" → humanisateur ; "construire un tableau de bord" → frontend/graphique).
2. Vérifier d'abord le registre — python scripts/console.py suggest --need "<besoin>". Il retourne soit :
   • ✓ Vous avez déjà une skill/plugin utilisable : <nom> → utilisez-la, n'installez rien ; ou
   • 💡 Suggestion de nouvel ajout : [install:<slug>] <titre> → pas de couverture, recommander la catégorie.
3. Si non couvert, rechercher sur le marché des candidats réels (skills/plugins/experts) et présenter une fiche avec preuves : ce qu'il fait, pourquoi il correspond à ce besoin, source. Ne jamais installer automatiquement — l'utilisateur choisit.
4. Sur insta…

…

[la suite du contenu est tronquée pour la traduction]