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é.

Installez les skills et figez la version testée

Il existe deux méthodes d’installation. Dans Claude Code, la méthode avec le plugin tient en deux commandes :

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

Sur un VPS, si vous voulez conserver une copie versionnée sur le disque, clonez d’abord le dépôt, puis 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’opération terminée, ls ~/.claude/skills liste fable-judge, fable-loop et fable-method. Vérifiez ce qui manque. Le dépôt contient quatre skills et l’installateur shell de v1.4.0 en copie trois. Un utilisateur autonome 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. Le changelog répertorie cinq versions entre 2026-07-06 et 2026-07-15, de 1.0.0 à 1.4.0, mais quatre seulement ont été taguées (v1.0.0, v1.1.0, v1.2.0 et v1.4.0), et seules v1.2.0 et v1.4.0 ont été publiées comme releases GitHub. Le tag v1.3.0 n’existe pas ; les notes de version de v1.4.0 indiquent qu’elles intègrent tout le contenu de v1.3.0, qui n’a jamais été publiée. v1.4.0 a modifié la méthode elle-même en ajoutant une nouvelle règle de routage. En octobre 2026, v1.4.0 reste le tag le plus récent, mais main l’a dépassé : un commit du 2026-10-03 a ajouté une cible d’installation Codex et fait en sorte que install.sh copie les quatre skills, et aucun tag n’intègre encore cette modification. Si votre exécution de contrôle lit une version des règles et votre exécution de test une autre, vous n’avez rien mesuré.

Ce que chacune des quatre skills demande au modèle de faire

Le fichier central est skills/fable-method/SKILL.md. Il contient deux gates et sept étapes numérotées. Ses règles sont assez précises pour être vérifiées et contestées.

La triviality gate intervient en premier : agissez directement, sans procédure superflue, lorsque la modification concerne un seul fichier, tient en environ 10 lignes au maximum, n’ajoute aucun nouveau comportement et que vous savez déjà exactement quoi modifier. Une skill distincte repose entièrement sur cette approche : 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. La fit gate intervient ensuite. Elle oriente la demande selon l’emplacement de la réponse : des sources que vous pouvez ouvrir, une technique à rechercher d’abord, ou votre propre déduction. Cette dernière doit être signalée comme peu fiable et non 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 implique de 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 probants, décider, agir, vérifier, rendre compte. L’étape 2 demande de commencer par lister le répertoire avant de choisir les fichiers, de privilégier les sources primaires plutôt que la mémoire, 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 qui change le comportement. 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 pas modifier le code si ces trois éléments ne concordent pas, car ce désaccord constitue le véritable constat. L’étape 5 limite les 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 facilement testable du fichier est constituée de ses quatre tokens de compte rendu. Une modification de comportement doit comporter une ligne INTENT:. Une action externe doit comporter AUTH: user said "<exact words>" et citer l’utilisateur, car le dépôt indique clairement que la documentation ne constitue pas une autorisation. Une action prescrite mais non effectuée doit comporter une ligne PENDING:. Un défaut corrigé doit comporter TWINS: searched <pattern> - found <N> other sites. Il n’est pas nécessaire de faire confiance à la méthode pour vérifier si ces quatre chaînes apparaissent lorsqu’elles sont requises. C’est ce qui rend l’ensemble mesurable, au lieu de reposer sur une impression.

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

fable-judge est l’élément qui mérite d’être installé, 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, relance chaque vérification indiquée dans le rapport et recherche une liste nommée de fraudes : contrôles affaiblis, achèvement fictif, dérive du périmètre, action non autorisée, non-respect de la spécification et résidus inutiles. Il renvoie VERIFIED, VERIFIED WITH CAVEATS ou REFUTED, et marque comme UNVERIFIABLE tout élément qu’il ne peut pas reproduire au lieu de supposer qu’il est validé. La dernière ligne de l’installateur le résume ainsi : « Essayez : ouvrez Claude Code et saisissez /fable-judge après qu’un agent a déclaré le travail terminé. » Si vous préférez intégrer ce contrôle au travail plutôt que l’exécuter ensuite, la skill Old Coder demande à l’agent de produire une SPEC que vous approuvez ainsi qu’un rapport EVIDENCE que vous pouvez relancer vous-même. Les tests par mutation remplacent la couverture comme preuve qu’un test détecterait réellement une régression.

fable-domain génère des bundles d’adaptation par domaine avec des fixtures de pièges et des smoke evals. Huit adaptateurs sont fournis : marketing, recherche, analyse de données, gestion et opérations, finance, droit et conformité, design et UX, et devops. Le travail médical et clinique en est volontairement dépourvu.

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 le packaging relève du cargo cult

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

La présentation va plus loin que les éléments disponibles. « How Claude Fable 5 worked » est une affirmation sur le fonctionnement interne d’un modèle que personne en dehors d’Anthropic ne peut vérifier, et la phrase centrale du dépôt la contredit elle-même : « The quality lives in the structure, the evidence, and the honesty, not in the model. » 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 skills représentent davantage de surface que nécessaire au vu du contenu. fable-loop reprend une grande partie de fable-method en y ajoutant une couche d’orchestration, et sur un harness sans subagents, il se réduit à fable-method. Lisez les deux fichiers côte à côte avant d’installer les deux.

Huit adapters par domaine représentent une couverture que l’eval ne vérifie pas. Deux des huit apparaissent dans les logs : marketing au round 9 et devops au round 12. Les adapters finance, legal, design et data sont livrés sans aucun round correspondant. L’adapter de votre domaine peut malgré tout être bon. Il s’agit toutefois d’un brouillon d’auteur, pas d’un composant qui a résisté à un jeu de tests piégeux.

Enfin, l’installer du tag v1.4.0 ne correspond pas au dépôt concernant ce qu’il livre : il copie trois des quatre skills dans ~/.claude/skills. Un commit sur main daté du 2026-10-03 a corrigé ce problème, près de trois mois plus tard, et aucune release taguée n’intègre encore cette correction. Ce problème est mineur. Il montre aussi le type d’écart qui indique que le packaging a évolué plus vite qu’il n’a été relu. Gardez-le à l’esprit lorsque vous déciderez quelle part de cet ensemble adopter en une seule fois.

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é, sans code spécifique à un modèle, et le dépôt fournit AGENTS.md sous forme de copie portable pour Codex, Cursor, aider ou un prompt système brut. Deux éléments ne sont pas portables. Les déclencheurs /fable-method et /fable-judge sont des commandes slash de Claude Code ; ailleurs, vous devez donc invoquer 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 manière 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 requête sans rapport ne coûte donc presque rien. Si vous les collez dans un prompt système, les quelque 2,600 mots de AGENTS.md sont transmis avec chaque requête. L’exécution elle-même coûte également davantage, car la méthode demande une phase d’orientation avant la modification, des éléments probants avant la décision et une véritable vérification ensuite. Mesurez-le : exécutez la même tâche avec --output-format json dans les deux bras, 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 reste le plus récent en octobre 2026. Trois tags l’ont précédé (v1.0.0, v1.1.0 et v1.2.0, v1.2.0 étant la seule release GitHub antérieure), une version v1.3.0 qui n’a jamais été publiée y a été intégrée, et v1.4.0 a modifié les règles de routage elles-mêmes. main continue également d’évoluer, avec une modification de l’installer en octobre qu’aucun tag ne contient encore. Suivre main pendant vos mesures signifie que l’exécution de contrôle et l’exécution de test peuvent lire des instructions différentes, ce qui rend la comparaison inutilisable. 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 changements de la méthode, ce que son auteur indique lui-même : « Ce journal existe pour que les modifications de la méthode soient testées, et non pour que quelqu’un le prenne pour un benchmark. » Les limites sont indiquées au début du fichier : 1 à 4 exécutions par cellule, des fixtures synthétiques et des juges LLM fondés sur le même modèle de pointe que celui qui sert également de baseline. 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 toujours pas d’une mesure de ce qui se produira sur votre codebase. Exécutez donc vous-même la comparaison à deux bras.