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 pour agents. Il décrit 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 a fonctionné, synthétisé dans des skills que n’importe quel modèle peut exécuter, avec l’évaluation qui le vérifie ». La seconde moitié de cette phrase est l’affirmation 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 particulier 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. Un seul VPS et un après-midi suffisent. 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 pour agent : un dossier contenant un fichier SKILL.md dont la description dans le 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, si vous voulez une copie figé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 ne nécessite pas sudo, car il écrit uniquement sous $HOME/.claude/skills. Après son exécution, ls ~/.claude/skills liste fable-judge, fable-loop et fable-method. Vérifiez ce qui manque. Le dépôt fournit quatre skills, mais l’installateur shell 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. 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 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 suffisamment précises pour être discuté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 ou moins, n’ajoute aucun nouveau comportement et que vous savez déjà exactement quoi changer. Une skill distincte repose entièrement sur ce principe : Ponytail, qui pousse l’agent vers la plus petite modification fonctionnelle. Sa règle principale est suffisamment 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 consulter, une technique que vous devez d’abord étudier, 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 qu’il faut 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 : classifier la demande, définir le résultat attendu, réunir les éléments de preuve, décider, agir, vérifier, puis rendre compte. L’étape 2 demande de s’orienter en listant 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. Cette ligne doit indiquer ce que fait le code, ce qu’attend le contrôle en échec et ce que dit la spécification. Il ne faut effectuer aucune modification si ces trois éléments sont contradictoires, car cette contradiction constitue le véritable résultat de l’analyse. 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 retournez la sortie réelle.

La partie la plus facile à tester dans ce 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 exécuté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 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 fondé sur une impression.

fable-loop applique la même méthode sous forme d’orchestration en quatre étapes : planifier avec des subagents chargés de réunir des éléments de preuve en parallèle, exécuter sur le thread principal, vérifier avec un à trois subagents 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 le composant 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 collecte 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 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. Il renvoie VERIFIED, VERIFIED WITH CAVEATS ou REFUTED. Tout élément 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 recommande explicitement : « Essayez : ouvrez Claude Code et saisissez /fable-judge après qu’un agent a affirmé que le travail était terminé. »

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, activités et opérations, finance, droit et conformité, design et UX, et devops. Le travail médical et clinique est volontairement laissé sans adaptateur.

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 ouvre sur : « Version portable pour n’importe quel agent ou harness de code (Codex, Cursor, aider ou une simple invite système). La méthode est 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 garde-fous, étapes et modes. Si vous conservez 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 une invite structurée, sans code spécifique à un modèle. Tout modèle capable de suivre des instructions peut donc l’appliquer. La thèse du dépôt est que le gain est inversement proportionnel au niveau du modèle. Le judge se porte également facilement, à condition que l’agent dispose d’un shell et d’un dépôt, car tout ce qu’il fait consiste en git diff et en une nouvelle exécution de commandes que le lecteur peut lui aussi lancer.

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 sur un seul modèle. Il perd ainsi le parallélisme et la réduction des coûts qui justifiaient cette conception. Il ne reste alors que fable-method avec un vocabulaire supplémentaire.

Deux autres éléments 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 invoquez donc la méthode en la décrivant. La description de frontmatter SKILL.md permet à un agent de charger le corps uniquement lorsque la tâche correspond. Une skill installée ne coûte ainsi presque rien tant qu’elle n’est pas déclenchée. Si vous collez AGENTS.md dans une invite système, ces 2,600 mots sont inclus dans chaque requête que vous envoyez, qu’il s’agisse d’une correction typographique d’une ligne ou d’un refactoring. La différence de coût est réelle. C’est la principale raison d’être du packaging sous forme de skill.

Comment comparer 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 le texte au lieu des résultats.

Exécutez le groupe témoin avec --bare. Cette option désactive la découverte automatique des hooks, des skills, des plugins et de CLAUDE.md. C’est ce qui en fait un témoin : les skills installés précédemment ne peuvent pas intervenir. Le mode bare n’utilise pas votre connexion d’abonnement ; définissez donc d’abord 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 arborescence de départ. Une seule option diffère. C’est la seule manière de rendre la comparaison pertinente.

Cette conception mesure le texte de la méthode. Elle ne mesure pas le packaging du skill, qui est une question distincte. Pour mesurer le packaging, supprimez --bare, installez les skills comme indiqué plus haut, puis placez le nom du skill dans la chaîne de l’invite, 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ûts 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 seule fois et examinez-la avant d’écrire un script qui l’exploite, 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 se trouve dans 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 s’obtient en comptant les appels d’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 une méthode qui lit davantage de fichiers et effectue moins de modifications suit les exigences de cette méthode. C’est le compromis que vous choisissez. Une exécution avec une 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 de output_tokens dans les transcriptions de session sous ~/.claude/projects/ en la considérant comme le total : ces blocs d’utilisation par message sont des instantanés pris pendant le streaming, et des rapports indiquent qu’ils sous-estiment parfois les valeurs. La ligne result est la valeur de référence. Deuxièmement, une seule exécution par méthode ne constitue qu’une anecdote. Exécutez chaque méthode trois ou quatre fois sur la même tâche avant de considérer un écart comme significatif, car deux exécutions du même agent sur la même tâche produisent déjà des résultats différents. Pour suivre 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 décomptes bruts.

Vérifiez que l’agent ne peut pas accéder aux ressources auxquelles vous tenez pendant son exécution sans surveillance. exécuter Claude Code en toute sécurité sur un VPS présente le compte utilisateur et les flags de permissions.

Lire honnêtement l’évaluation du dépôt

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 de preuves que ce que publie presque n’importe quel dépôt de skills, et eval/RESULTS.md est documenté tour par tour, avec les échecs conservés. Le contenu est toutefois moins riche que ne le laisse penser le nombre du 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 limites affichées en tête 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 le reconnaître. Un auteur qui publie son propre n et qui signale que son judge repose sur le même modèle que celui utilisé comme baseline fait preuve de davantage d’honnêteté que la norme dans cette catégorie. Considérez ces chiffres comme la preuve que l’auteur a réellement effectué les tests et conservé les échecs. Seul votre propre test A/B vous renseignera sur votre codebase.

Le README indique aussi clairement dans quels cas la méthode n’apporte rien. C’est son paragraphe le plus utile. Il ne constate aucun gain pour les tâches courantes de petite taille sur des modèles performants. Il précise 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. Si vous utilisez un modèle moins coûteux en mode unattended, c’est là qu’un écart devrait apparaître. Cela fait aussi le choix entre Opus, Sonnet et Haiku 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 de passer à côté du 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 n’est qu’un habillage. La procédure se suffit à elle-même et n’a pas besoin d’un mythe fondateur.

Quatre skills constituent une surface plus large que nécessaire au vu du contenu. fable-loop reprend une grande partie de fable-method en y ajoutant une orchestration, et sur un harness sans subagents, il se réduit à nouveau à fable-method. Lisez les deux fichiers côte à côte avant d’installer les deux.

Huit adapters de domaine donnent une couverture que l’évaluation n’examine pas. Deux des huit apparaissent dans les logs : marketing à la round 9 et devops à la round 12. Les adapters finance, legal, design et data sont fournis sans aucune round correspondante. L’adapter correspondant à votre domaine peut malgré tout être bon. Il s’agit toutefois d’un brouillon d’auteur, pas d’un composant ayant résisté à une fixture de test conçue pour révéler ses faiblesses.

Et l’installer ne correspond pas au dépôt sur ce qu’il fournit : il copie trois des quatre skills dans ~/.claude/skills. Ce point est mineur. C’est aussi le genre d’écart qui indique que le packaging a évolué plus vite que les revues, ce qu’il faut garder à l’esprit lorsque vous décidez de la quantité à adopter en une seule fois.

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

Supprimez l’identité visuelle : quatre règles restent valables à elles seules, quel que soit l’agent utilisé.

• La citation d’autorisation. Une action irréversible ou tourné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 vérification en miroir. Après avoir corrigé un défaut, recherchez dans l’ensemble du projet la même construction incorrecte et indiquez le nombre d’occurrences, y compris lorsque ce nombre est nul.
• La vérification par observation. Un contrôle ciblé au vert exécuté sur un build défaillant constitue une vérification en échec, pas une validation.
• Le compte rendu axé sur le résultat, en indiquant comme réserve 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 contrôler leur respect avec grep. Commencez par là, mesurez les résultats avec le harness ci-dessus, puis déterminez si le reste du dépôt mérite une part de votre budget de contexte. Si vous souhaitez fournir à un agent un contexte permanent du projet plutôt qu’une méthode de travail, un fichier DESIGN.md que les agents lisent avant toute modification constitue l’approche 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 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 lancer 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. La quantité dépend de la manière dont vous les chargez. Lorsqu’elles sont installées comme skills, leur contenu ne se charge que si la description correspond à la tâche. Une requête sans rapport n’ajoute donc presque aucun coût. Si vous les collez 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 é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 était encore le plus récent en août 2026. Le dépôt a 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. Si vous suivez main pendant vos mesures, l’exécution de contrôle et l’exécution de test peuvent utiliser des instructions différentes. La comparaison n’a alors plus de valeur. 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 au début du fichier : 1 à 4 exécutions par cellule, des fixtures synthétiques et des juges LLM basés sur le même modèle de pointe que celui utilisé comme baseline. Les rounds sont réels et les expériences échouées sont conservées, ce qui est déjà plus que ce que publient la plupart des dépôts. Cela ne mesure toutefois pas ce qui se produira dans votre codebase. Effectuez donc vous-même la comparaison à deux bras.