Skill Doctor
Diagnostiquer et améliorer tout SKILL.md. Une boussole, pas un manuel — les standards concrets sont dans references/, consultés à la demande.
Flux de diagnostic après déclenchement (chaque étape doit produire une sortie visible)
Une étape sans sortie visible est ignorée silencieusement (Expérience Seleznov, 2026). Affichez une ligne de confirmation par étape. Drapeau d'auto-révision : si cette session a déjà Édité/Écrit le SKILL.md cible, préfixez chaque ligne de diagnostic avec
[self-review], et ajoutez une ligne à la fin de l'Étape 3 : « conclusion auto-évaluée, recommandez une re-révision avec un sous-agent frais. »
Étape 1 : Lire le SKILL.md cible, annoncer le début du diagnostic
Lisez l'intégralité du SKILL.md en cours d'édition, exécutez python3 <dossier-de-ce-skill>/scripts/check_listing_budget.py "<racine_du_projet>" (notez les guillemets — les espaces sont courants), affichez deux lignes :
[skill-doctor] Audit : <chemin> corps=<N> lignes description=<M> caractères
[skill-doctor] Budget (<plateforme>) : <K> compétences, <T> caractères vs ≈<B> → <ADAPTE | DÉPASSEMENT ×N.N>
Détecte automatiquement la plateforme (CC / Codex / Hermes / OpenClaw). Sortie : 0 = adapté ; 1 = dépassement ; 2 = indisponible (pas de plateforme / contexte inconnu → demandez la plateforme + la fenêtre de l'utilisateur). Le dépassement est un AVIS au niveau de la population, pas un défaut contre la compétence auditée : affichez les chiffres pour que l'utilisateur le sache, mais NE raccourcissez PAS la description de cette compétence pour des raisons de budget — la réduction est une opération globale, jamais une correction unique.
Étape 2 : Juger selon les dimensions
Choisissez les dimensions à charger depuis l'index des références (section Dimensions) — lisez uniquement les entrées dont le quand-lire se déclenche. Après le chargement, affichez une ligne :
[skill-doctor] Chargé : <liste> ; Ignoré : <liste avec raison en un mot>
Étape 2.5 : Parcours à sec (uniquement si le corps contient un workflow)
En suivant references/effect-dry-run.md, prenez l'invite la plus typique et parcourez-la à travers les étapes du corps, en vérifiant si entrée/instruction/sortie sont connectées.
Tout lien cassé ou ambiguïté → marquez P0 (problème d'effet) et placez-le dans la section ❌ de l'Étape 3.
Affichez une ligne :
[skill-doctor] Parcours à sec : invite="<invite>" liens cassés=<N>
Si le corps n'a pas de workflow (compétence de règle pure / de type référence), affichez :
[skill-doctor] Parcours à sec : ignoré (pas de workflow)
Étape 2.6 : Vérification d'injection en direct (uniquement si la compétence cible est dans le périmètre de la session en cours)
Vérifiez si la cible apparaît dans la liste des compétences disponibles de cette session avec sa description (pas seulement le nom). Les 3 cas (injectée / budget-drop par nom / ignorée hors périmètre) et la règle d'avis de population sont dans references/live-injection-check.md. Affichez une ligne :
[skill-doctor] Injection en direct : <INJECTÉE | SUPPRIMÉE (nom-seul) | ignorée (<raison>)>
Étape 3 : Afficher le rapport de diagnostic
Formatez strictement comme ci-dessous, affichez dans la conversation :
[skill-doctor] Diagnostic
❌ À corriger impérativement (trié P0→P3, définitions dans references/priority-tiers.md)
[P0 rupture d'effet] <problème> : <pourquoi> → <correctif>
[P1 structure] <problème> : <pourquoi> → <correctif>
[P2 spécificité] <problème> : <pourquoi> → <correctif>
[P3 affecte l'exécution] <problème> : <pourquoi> → <correctif>
⚠️ Améliorations suggérées (y compris purement cosmétiques / P3 verbeux)
- <problème> : <pourquoi> → <correctif>
✅ Vérifications réussies
- <liste>
Règle de placement P3 : demandez-vous « si ce n'est pas corrigé, le prochain LLM exécutant cette compétence fera-t-il quelque chose de faux ? » — oui → ❌ ; simplement moche/verbeux → ⚠️. Voir references/priority-tiers.md.
Chaque problème doit donner un numéro de ligne ou champ spécifique — pas de vague. Lorsque le même type de violation apparaît à plusieurs endroits, listez-les séparément — par exemple, un contenu mal catégorisé dans trois sous-répertoires doit donner 3 problèmes, pas 1 entrée fusionnée.
Nommez le mode d'échec le cas échéant (voir references/predictability-glossary.md) : préfixez la constatation avec [no-op] / [sediment] / [premature-completion] / [weak-leading-word] / [duplication] / [sprawl]. Le nom dit de quel type ; le niveau P dit toujours à quel point — orthogonaux, donc le préfixe ne remplace jamais le niveau.
Étape 4 : Appliquer avec Édition après confirmation de l'utilisateur
Ne jamais Éditer sans confirmation. Attendez que l'utilisateur dise « corrige-le » avant d'agir.
Avant d'agir, appliquez la barrière de taille et la vérification pré-suppression ; ensuite, bouclez la correction — procédure complète dans references/apply-safety.md.
Après la correction, affichez une ligne :
[skill-doctor] Appliqué <N> corrections à <chemin> corps : <ancien>→<nouveau> lignes (<+X%>)
Règles strictes : aide-mémoire
Les règles strictes quantifiées (une violation est une erreur, pas une suggestion) sont dans references/hard-rules.md — consultez à chaque audit.
Gestion des exceptions
Lorsqu'un chemin est manquant, que le YAML ne s'analyse pas, ou qu'un script fourni (scripts/check_listing_budget.py + scripts/detect_platform.py / scripts/check_routes.py / scripts/eval_retrieval.py / scripts/check_desc_slim.py) est manquant ou se termine avec le code 2 — gérez selon references/exception-fallback.md. Annoncez l'exception à l'utilisateur en premier ; ne l'ignorez jamais silencieusement.
Sortie et langue
Le texte du rapport suit references/output-style.md (clair, compatible terminal, conclusion en premier). Corps/références : anglais par défaut ; signalez tout non-anglais injustifié ⚠️ — politique + les deux exceptions justifiées dans references/language-policy.md.
Hors périmètre de cette compétence
- La fonctionnalité réelle est-elle correcte (c'est un bug logique, pas un problème de forme de compétence)
- Les conventions spécifiques au projet (elles vont dans CLAUDE.md, pas dans une compétence)
- Les scripts de correction ponctuels (jetés après une exécution, ne devraient pas être une compétence)
Pourquoi cette compétence existe
Pourquoi les LLM écrivent mal SKILL.md comme un manuel, et comment cette compétence sépare les vérifications mécaniques du jugement : references/rationale.md.