Méthode Fable : des skills pour tous les modèles

Ce que la méthode Fable affirme réellement

La méthode Fable est un petit ensemble de skills d’agent qui consignent les habitudes de travail d’un modèle sous la forme d’une procédure ordonnée, afin qu’un autre modèle puisse exécuter la même procédure. Le dépôt est Sahir619/fable-method, sous licence MIT. Sa propre description en une ligne est la suivante : « comment Claude Fable 5 fonctionnait, synthétisé en skills qu’un modèle peut exécuter, avec l’évaluation qui vérifie cette affirmation ». C’est la seconde moitié de cette phrase qui mérite d’être testée.

Personne en dehors d’Anthropic ne peut vérifier si un fichier texte décrit réellement la manière dont un modèle précis raisonne. En revanche, vous pouvez vérifier vous-même si un modèle moins coûteux se comporte différemment lorsqu’il lit ce fichier texte, sur un seul VPS, en une après-midi. C’est l’objectif de toute la procédure ci-dessous : exécuter deux fois la même tâche, avec et sans la méthode, puis compter les appels aux outils et le coût.

Si le terme skill vous est nouveau, commencez par ce qu’est réellement un skill d’agent : un dossier contenant un fichier SKILL.md dont la description en frontmatter indique à l’agent quand charger le contenu. Le modèle qui a donné son nom au dépôt est présenté dans le coût de Claude Fable 5 et les tâches pour lesquelles il est adapté.

Installer les skills et figer la version testée

Il existe deux méthodes d’installation. Dans Claude Code, la méthode avec le plugin se résume à deux commandes :

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

Sur un VPS, lorsque vous voulez une copie versionnée sur le disque, clonez d’abord le dépôt et basculez sur un tag :

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh n’a pas besoin de sudo, car il écrit uniquement sous $HOME/.claude/skills. Une fois l’installation terminée, ls ~/.claude/skills liste fable-judge, fable-loop et fable-method. Vérifiez ce qui n’y figure pas. Le dépôt fournit quatre skills, mais le shell installer en copie trois. Un utilisateur standalone n’obtient donc pas fable-domain, sauf s’il le copie manuellement :

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

Figez le tag et notez-le à côté des résultats obtenus. Ce dépôt a publié cinq releases entre 2026-07-06 et 2026-07-15, de v1.0.0 à v1.4.0. La version v1.4.0 a modifié la méthode elle-même en ajoutant une nouvelle étape de routage. En août 2026, v1.4.0 reste le tag le plus récent. Si votre exécution de contrôle lit une version des règles et votre exécution de test en lit une autre, vous n’avez rien mesuré.

Ce que chacune des quatre compétences demande au modèle de faire

Le fichier central est skills/fable-method/SKILL.md. Il contient deux garde-fous et sept étapes numérotées. Ses règles sont suffisamment précises pour être discutées.

Le garde-fou de trivialité vient en premier : agissez directement, sans formalités, lorsque la modification concerne un seul fichier, tient en environ 10 lignes ou moins, n’ajoute aucun nouveau comportement et que vous savez déjà exactement quoi changer. Une compétence distincte repose entièrement sur cette idée : Ponytail, qui oriente l’agent vers la plus petite modification fonctionnelle. Sa règle principale est assez courte pour être copiée dans vos propres instructions sans rien installer. Vient ensuite le garde-fou d’adéquation. Il oriente la demande selon l’emplacement de la réponse : des sources que vous pouvez consulter, une technique que vous devez d’abord rechercher ou votre propre déduction, qui doit être signalée comme peu fiable au lieu d’être présentée comme un fait. Cette branche intermédiaire ne fonctionne que si l’agent peut réellement accéder au Web. Sur un VPS verrouillé, cela signifie lui fournir son propre backend de recherche, par exemple une instance SearXNG auto-hébergée exposée comme outil de recherche JSON.

Vient ensuite la boucle : classer la demande, définir le résultat attendu, recueillir les éléments de preuve, décider, agir, vérifier et rendre compte. L’étape 2 demande de commencer par lister le répertoire avant de choisir les fichiers, de préférer les sources primaires aux souvenirs et de s’arrêter après deux recherches consécutives qui ne renvoient rien de nouveau. L’étape 4 demande d’écrire une ligne INTENT: avant toute modification. Cette ligne doit indiquer ce que fait le code, ce que le contrôle en échec attend et ce que dit la spécification. Il ne faut effectuer aucune modification lorsque ces trois éléments divergent, car cette divergence constitue le véritable résultat de l’analyse. L’étape 5 limite les nouvelles tentatives : après trois cycles de correction et de vérification ayant échoué sur le même problème, arrêtez-vous et renvoyez la sortie réelle.

La partie la plus facile à tester du fichier est constituée de ses quatre marqueurs de rapport. Une modification de comportement doit produire une ligne INTENT:. Une action externe doit produire AUTH: user said "<exact words>", avec une citation de l’utilisateur, car le dépôt indique clairement que la documentation ne constitue pas une autorisation. Une action prescrite mais non exécutée doit produire une ligne PENDING:. Un défaut corrigé doit produire TWINS: searched <pattern> - found <N> other sites. Il n’est pas nécessaire d’adhérer à la méthode pour vérifier si ces quatre chaînes apparaissent lorsqu’elles sont requises. C’est ce qui rend l’ensemble mesurable plutôt que subjectif.

fable-loop applique la même méthode sous forme d’une orchestration en quatre étapes : planifier avec des sous-agents de collecte de preuves exécutés en parallèle, exécuter sur le fil principal, vérifier avec un à trois sous-agents attaquants qui adoptent chacun un angle différent, puis auditer et rendre compte. Cette approche suppose l’utilisation de modèles peu coûteux pour les rôles de collecte de preuves et d’attaque, et d’un modèle plus puissant pour les décisions et les modifications.

fable-judge est la partie qui mérite d’être installée même si vous abandonnez tout le reste. Son principe est le suivant : « un rapport est un ensemble d’affirmations, pas une preuve ». Il extrait les affirmations d’un rapport terminé, établit la vérité de référence à partir de git diff et git status, réexécute chaque vérification que le rapport indique avoir effectuée et recherche une liste nommée de fraudes : contrôles affaiblis, achèvement fictif, dérive du périmètre, action non autorisée, trahison de la spécification et résidus. Il renvoie VERIFIED, VERIFIED WITH CAVEATS ou REFUTED. Tout ce qu’il ne peut pas reproduire est marqué UNVERIFIABLE au lieu d’être considéré comme réussi. La dernière ligne de l’installateur le résume : « Essayez : ouvrez Claude Code et saisissez /fable-judge après qu’un agent a indiqué que son travail était terminé. » Si vous préférez intégrer ce contrôle au travail plutôt que l’exécuter après coup, la compétence Old Coder demande à l’agent de produire une SPEC que vous approuvez et un rapport EVIDENCE que vous pouvez réexécuter vous-même. Les tests par mutation remplacent alors la couverture comme preuve qu’un test détecterait réellement une régression.

fable-domain génère des ensembles d’adaptation par domaine avec des fixtures de pièges et des évaluations smoke. Huit adaptateurs sont fournis : marketing, recherche, analyse de données, gestion et opérations, finance, droit et conformité, design et UX, et devops. Les travaux médicaux et cliniques en sont délibérément exclus.

Quelles parties peuvent être portées vers un autre modèle, et lesquelles ne le peuvent pas

Le dépôt répond directement à cette question avec AGENTS.md, qui commence ainsi : « Version portable pour tout agent ou harness de programmation (Codex, Cursor, aider, simple system prompt). Méthode identique à celle de SKILL.md ; collez ce fichier dans les instructions de votre agent ou placez-le à la racine du dépôt sous le nom AGENTS.md. » Le fichier fait environ 2,600 mots et reprend les mêmes contrôles, étapes et modes. Si vous utilisez déjà des fichiers d’instructions à la racine du dépôt, la convention AGENTS.md et HUMAN.md indique où placer ce fichier et qui le lit.

Deux parties se portent facilement. Le texte de la méthode est un prompt structuré, sans code propre à un modèle. Tout modèle qui suit des instructions peut donc l’appliquer. La thèse du dépôt est que l’effort de portage est inversement proportionnel au niveau du modèle. Le judge se porte également sans difficulté, à condition que l’agent dispose d’un shell et d’un dépôt, car toutes ses opérations consistent à exécuter git diff, puis à relancer des commandes que le lecteur peut lui aussi exécuter.

Une partie ne se porte pas facilement. fable-loop suppose que le harness peut lancer des sous-agents en parallèle et les affecter à différents modèles. Un agent sans sous-agents exécute ces étapes en série avec un seul modèle. Cela supprime le parallélisme et les économies qui justifiaient cette conception. Il ne reste alors que fable-method avec du vocabulaire supplémentaire.

Deux autres éléments, plus limités, dépendent du harness et sont faciles à manquer. Le déclencheur /fable-method est une commande slash de Claude Code. Sur un autre harness, vous lancez donc la méthode en la décrivant. La description du frontmatter SKILL.md permet à un agent de ne charger le corps que lorsque la tâche correspond. Une skill installée ne coûte ainsi presque rien tant qu’elle ne se déclenche pas. Si vous insérez AGENTS.md dans un system prompt, ces 2,600 mots sont présents dans chaque requête envoyée, qu’il s’agisse de corriger une faute sur une ligne ou de réaliser un refactoring. La différence de coût est réelle. C’est la raison principale pour laquelle le packaging sous forme de skill existe.

Comment réaliser un test A/B sur un VPS : la même tâche, deux fois

Configurez deux copies de travail identiques afin qu’aucune exécution ne puisse voir les modifications de l’autre. Remplacez YOUR_ORG/YOUR_REPO par le dépôt que vous voulez tester ; les deux clones doivent provenir du même commit.

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

Choisissez une tâche dont le résultat peut être observé sans interprétation : un test en échec qui doit réussir, ou un script qui doit se terminer avec le code 0. Une tâche vague produit une comparaison vague, car vous finissez par évaluer du texte au lieu des résultats.

Lancez le groupe témoin avec --bare. Cette option désactive la découverte automatique des hooks, skills, plugins et CLAUDE.md. C’est cette option qui en fait un groupe témoin : les skills installés précédemment ne peuvent pas intervenir. Le mode bare n’utilise pas votre identifiant d’abonnement. Vous devez donc d’abord définir une clé API depuis la Claude Console.

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

Le groupe testé utilise la même commande avec une option supplémentaire. Celle-ci charge la méthode portable comme ajout à l’invite système :

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

Même binaire, même modèle, mêmes outils, même arbre de départ. Une seule option diffère. C’est la seule façon d’obtenir une comparaison exploitable.

Cette conception mesure le texte de la méthode. Elle ne mesure pas le packaging du skill, qui constitue une question distincte. Pour mesurer le packaging, supprimez --bare, installez les skills comme indiqué précédemment et placez le nom du skill dans la chaîne de prompt, car les skills invoqués par l’utilisateur sont développés en mode print : claude -p "/fable-method $task". Attendez-vous à un profil de coût différent de celui du groupe utilisant l’invite système, même si le comportement visible semble identique.

Compter les étapes et le coût

Les deux exécutions ont écrit un flux d’événements JSON. La dernière ligne est un message result qui contient le texte final, le coût et les métadonnées de session. Affichez-la une fois et lisez-la avant d’écrire un script autour de cette sortie, car les noms de champs changent selon les releases de Claude Code.

tail -1 ~/ab/control.jsonl | jq .

Le coût de chaque exécution provient de cette ligne. C’est cette valeur qu’il faut comparer :

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

Le nombre d’étapes se calcule en comptant les appels aux outils dans le même fichier :

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

Faites ce calcul pour les deux fichiers. La forme de l’écart est plus instructive que les totaux. Une exécution avec méthode qui lit davantage de fichiers et en modifie moins respecte ce que demande la méthode : c’est le compromis que vous acceptez. Une exécution avec méthode qui effectue les mêmes modifications pour un coût supérieur de quarante pour cent ne vous a rien apporté sur cette tâche.

Deux précautions concernant ces chiffres. Premièrement, ne faites pas la somme des output_tokens dans les transcriptions de session sous ~/.claude/projects/ pour l’appeler le total : ces blocs d’utilisation par message sont des instantanés pris pendant le streaming, et des rapports indiquent qu’ils peuvent sous-estimer les valeurs. La ligne result est la valeur de référence. Deuxièmement, une seule exécution par configuration reste anecdotique. Exécutez donc chaque configuration trois ou quatre fois sur la même tâche avant de tirer une conclusion d’un écart, car deux exécutions du même agent sur la même tâche peuvent déjà donner des résultats différents. Pour analyser les dépenses sur une période plus longue, les outils qui suivent les dépenses de Claude Code et la façon dont Claude Code compte les tokens expliquent pourquoi les lignes de cache dominent les comptes bruts.

Vérifiez que l’agent ne peut pas accéder à ce qui vous importe pendant son exécution unattended. exécuter Claude Code en toute sécurité sur un VPS présente le compte utilisateur et les flags de permissions.

L’évaluation du dépôt, lue avec recul

Le titre du README est « Fifteen eval rounds, more than 260 agent runs, blind LLM judges that verify by diffing and executing. » Cela constitue davantage d’éléments probants que pour presque tous les dépôts de skills, et eval/RESULTS.md est documenté tour par tour, avec les échecs conservés. Mais l’ensemble est moins étoffé que ne le laisse penser le nombre affiché dans le titre, dès que l’on examine les cellules individuelles derrière les lignes récapitulatives.

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

La plus importante de ces 4 lignes repose sur 4 exécutions. Les trois autres reposent chacune sur 2 exécutions. Le dépôt le dit lui-même, dans les limitations permanentes en haut du journal : « Small n throughout (1-4 runs per cell), LLM judges (blind where multiple outputs are compared, but built on the same frontier model that appears as a baseline), synthetic fixtures, research ground truth only as current as its run date. » Et plus directement : « This log exists so method edits are tested, not so anyone mistakes it for a benchmark. »

Il faut lui en donner crédit. Un auteur qui publie son propre n et signale que son juge repose sur le même modèle que celui utilisé comme baseline est plus honnête que la norme dans cette catégorie. Considérez ces chiffres comme la preuve que l’auteur a réellement exécuté les tests et conservé les échecs. Seul votre propre test A/B vous indiquera ce qu’il en est pour votre codebase.

Le README explique tout aussi clairement les cas où la méthode n’apporte rien, et c’est son paragraphe le plus utile. Il ne relève aucun gain pour les petites tâches ordinaires exécutées sur des modèles performants. Il indique que « the method cannot make a model's facts fresher; bare frontier wins knowledge-heavy research ». Il situe la valeur dans les « traps (authority conflicts, false completion claims, weak executors, unattended runs), not everywhere ». Si votre agent effectue de petites modifications sur un modèle performant et que vous le surveillez, attendez-vous à ne mesurer aucun effet. S’il s’agit d’un modèle moins coûteux qui s’exécute sans surveillance, c’est là qu’un écart devrait apparaître ; le choix entre Opus, Sonnet et Haiku fait donc partie de la même décision.

Quand l’empaquetage relève du cargo cult

Quatre critiques méritent d’être formulées, et aucune ne justifie de délaisser le dépôt.

La présentation va au-delà des éléments disponibles. « Comment Claude Fable 5 fonctionnait » est une affirmation sur les mécanismes internes d’un modèle que personne en dehors d’Anthropic ne peut vérifier, et la phrase centrale du dépôt lui-même la contredit : « La qualité réside dans la structure, les éléments probants et l’honnêteté, pas dans le modèle. » Si la qualité réside dans la structure, le récit de provenance est décoratif. La procédure se suffit à elle-même et n’a pas besoin d’un mythe fondateur.

Quatre compétences représentent davantage de surface que le contenu n’en nécessite. fable-loop reprend une grande partie de fable-method en y ajoutant une couche d’orchestration, et sur un harness sans sous-agents, cela revient à fable-method. Lisez les deux fichiers côte à côte avant d’installer les deux.

Huit adaptateurs de domaine donnent une couverture que l’évaluation ne vérifie pas. Deux des huit apparaissent quelque part dans le journal : marketing à la round 9, devops à la round 12. Les adaptateurs finance, juridique, design et données sont fournis sans round correspondant. L’adaptateur de votre domaine peut néanmoins être bon. Il s’agit toutefois d’un brouillon d’auteur, pas d’un élément ayant résisté à une fixture de test conçue pour piéger le système.

Et l’installer ne correspond pas au dépôt sur ce qu’il fournit : il copie trois des quatre compétences dans ~/.claude/skills. Ce point est mineur. C’est aussi le genre d’écart qui montre que l’empaquetage a évolué plus vite que sa vérification, ce qu’il faut garder à l’esprit lorsque vous décidez dans quelle mesure l’adopter dès maintenant.

Ce qu’il faut conserver si vous ne conservez rien d’autre

Retirez la marque et quatre règles restent valables, quel que soit l’agent utilisé.

• La citation d’autorisation. Une action irréversible ou exposée vers l’extérieur nécessite les propres mots de l’utilisateur, écrits sur une ligne AUTH:. Un agent qui ne trouve aucune citation n’agit pas.
• La double vérification. Après avoir corrigé un défaut, recherchez dans tout le projet la même construction incorrecte et indiquez le nombre trouvé, y compris lorsque ce nombre est zéro.
• La vérification par observation. Un contrôle ciblé au vert exécuté sur un build défaillant constitue une vérification échouée, pas une réussite.
• Le compte rendu axé sur le résultat, en indiquant comme réserve tout ce qui a été ignoré ou n’a pas été vérifié, plutôt que de le supprimer discrètement.

Ces quatre règles ne coûtent rien à adopter et vous pouvez vérifier leur respect avec grep. Commencez par là, mesurez les résultats avec le harness ci-dessus, puis décidez si le reste du dépôt mérite sa part de votre budget de contexte. Si vous voulez fournir à un agent un contexte permanent sur le projet plutôt qu’une méthode de travail, un fichier DESIGN.md que les agents lisent avant de modifier le projet constitue l’étape complémentaire.

FAQ

La méthode Fable fonctionne-t-elle avec des modèles autres que Claude ?

Le texte de la méthode, oui. Il s’agit d’un prompt ordonné qui ne contient aucun code spécifique à un modèle, et le dépôt fournit AGENTS.md comme copie portable pour Codex, Cursor, aider ou un prompt système brut. Deux éléments ne sont pas transposables. Les déclencheurs /fable-method et /fable-judge sont des commandes slash de Claude Code ; ailleurs, vous lancez la méthode en la décrivant. Et fable-loop suppose un harness capable de lancer des sous-agents en parallèle sur différents modèles ; sans cela, l’exécution est séquentielle et vous obtenez fable-method avec des étapes supplémentaires.

L’exécution de ces skills consomme-t-elle davantage de tokens ?

Oui, et la quantité dépend de la façon dont vous les chargez. Lorsqu’ils sont installés comme skills, leur contenu n’est chargé que si la description correspond à la tâche ; une demande sans rapport ne coûte donc presque rien. S’ils sont copiés dans un prompt système, les quelque 2,600 mots de AGENTS.md sont inclus dans chaque requête. L’exécution elle-même coûte aussi davantage, car la méthode demande une phase d’orientation avant la modification, des éléments probants avant la décision et une vraie vérification ensuite. Mesurez la différence : exécutez la même tâche avec --output-format json dans les deux conditions, puis comparez le champ total_cost_usd.

Quelle version de fable-method dois-je installer, et pourquoi la figer ?

Exécutez git checkout v1.4.0 avant l’installation. Ce tag est daté du 2026-07-15 et était toujours le plus récent en août 2026. Le dépôt avait publié cinq releases au cours des neuf jours précédents, et v1.4.0 a modifié les règles de routage elles-mêmes. Suivre main pendant vos mesures signifie que l’exécution de contrôle et l’exécution de test peuvent utiliser des instructions différentes, ce qui rend la comparaison inutile. Notez le tag avec vos résultats.

L’eval du dépôt est-elle un benchmark fiable ?

Considérez-la comme un journal des modifications de la méthode, ce que son auteur indique lui-même : « Ce journal existe pour tester les modifications de la méthode, pas pour que quiconque le prenne pour un benchmark. » Les limites sont indiquées en haut du fichier : 1 à 4 exécutions par cellule, des fixtures synthétiques et des évaluateurs LLM basés sur le même modèle frontier qui sert également de référence. Les rounds sont réels et les expériences échouées sont conservées, ce que la plupart des dépôts publient rarement. Il ne s’agit toutefois pas d’une mesure de ce qui se produira sur votre codebase. Exécutez donc vous-même la comparaison en deux conditions.