fable-method : transformer une méthode d'agent en skills exécutables et évaluées

Le problème : des consignes qui disent quoi valoriser, pas quoi faire

La plupart des fichiers d'instructions d'agent demandent au modèle d'être prudent et de vérifier son travail. C'est un objectif, pas une procédure. Un modèle de milieu de gamme ne peut pas exécuter un objectif : il lui faut un ordre d'actions et des seuils. Le README de fable-method pose exactement ce diagnostic et propose l'inverse : des règles qui disent quoi faire, dans quel ordre, avec des bornes numériques. Le public visé n'est donc pas l'utilisateur d'un modèle frontière, mais celui qui fait tourner des modèles plus faibles sur des tâches où une erreur silencieuse coûte cher. Le dépôt est publié sous licence MIT, en Python, avec une structure de skills destinée à Claude Code (le badge du README pointe vers .claude-plugin/plugin.json).

Quatre skills, une boucle en sept étapes

L'architecture se lit dans l'arborescence : skills/fable-method/SKILL.md pour la réflexion, fable-loop pour l'action, fable-judge pour la preuve, fable-domain pour générer de nouveaux adaptateurs de domaine. Le README résume la philosophie en trois verbes : think, act, prove. La boucle détaillée enchaîne sept étapes numérotées : classer la demande (question, tâche, ou plan à construire), définir ce que signifie terminé avec une vérification nommée, rassembler des preuves en parallèle depuis des sources primaires, s'engager sur une seule recommandation, agir par modifications chirurgicales, vérifier par observation, puis rapporter le résultat en commençant par l'issue et en exposant les réserves honnêtement. Chaque flèche possède des bornes explicites : trois cycles de vérification échoués déclenchent un arrêt et une restitution, deux recherches infructueuses arrêtent la recherche, et l'incapacité à nommer une vérification impose une question ciblée. Le fichier SKILL.md fait environ 110 lignes selon le README, et l'auteur affirme que chaque phrase y est porteuse.

Le fit gate et le twin check : les garde-fous de la v1.4.0

La version 1.4.0 ajoute quatre éléments nommés dans les notes de version : le fit gate, le twin check, l'artifact gate et le maker avec red-lines. Le fit gate intervient avant toute action et pose une question unique : où vit la réponse ? Si elle est dans des sources accessibles, on passe à la classification de la demande. Si elle est inconnue mais recherchable, on lance d'abord la recherche prévue à l'étape 2. Si elle ne vit que dans l'inférence du modèle lui-même, la consigne est de le dire sans déguisement, de poser une question ou de signaler une confiance faible. C'est une distinction utile : elle empêche un agent de présenter une supposition comme un fait établi. Le README mentionne aussi une porte d'autorisation, née d'un run documenté où Fable 5 lui-même a déployé sur un environnement de staging alors que le README du fixture le prescrivait, dans un cas sur deux. Le dépôt garde ce run comme origine de la règle, ce qui est cohérent avec sa méthode : chaque règle existe parce qu'un test a échoué sans elle.

L'eval : des juges qui exécutent et comparent, pas qui lisent

Le point le plus intéressant du dépôt est son protocole d'évaluation. Le README décrit des juges LLM aveugles qui vérifient en comparant des diffs et en exécutant du code, jamais en lisant un rapport. Quinze tours d'eval et plus de 260 exécutions d'agent sont revendiqués, avec un cas d'étude par scénario dans eval/cases/ et les sorties brutes des juges dans eval/results/. Le README insiste sur un point méthodologique : les résultats nuls sont publiés avec les gains. La dernière ligne du tableau l'assume, les tâches ordinaires sur des modèles capables ne montrent aucun gain. C'est ce qui rend le reste lisible. Un tableau de résultats qui ne contiendrait que des victoires ne vaudrait pas la confiance qu'on lui accorde. Je ne peux pas vérifier ces chiffres ici, mais leur structure est vérifiable dans le dépôt : chaque ligne renvoie à un fichier JSON de tour précis.

Des gains concentrés sur les pièges, pas partout

Le README est explicite : la valeur de la méthode se concentre sur les traps, à savoir les conflits d'autorité, les fausses déclarations de complétion, les exécuteurs faibles et les exécutions sans surveillance. Sur le piège du conflit entre spécification et test, le tableau annonce Haiku passant de 0 sur 4 à 4 sur 4, et Sonnet atteignant l'action idéale sur 8 sur 8. Sur la détection de fraudes plantées dans un rapport mensonger, Haiku passe de 4 et 3 sur 5 à 5 sur 5 sur deux exécutions. Mais une ligne du même tableau est un échec : sur le scénario s9, Haiku ne remonte la décision de déploiement sauté qu'une fois sur douze, après trois formulations de règle différentes, et le README note que Sonnet et Opus le font nativement sur 8 sur 8. Autrement dit, la méthode compense partiellement la faiblesse du modèle, et pas toujours. Le README formule cela comme sa thèse : le gain est inversement proportionnel au niveau du modèle.

Mise en route et coût de maintenance

Le dépôt s'installe comme un plugin Claude Code, d'après le badge du README et le fichier .claude-plugin/plugin.json. Les skills se lisent ensuite dans skills/fable-method/SKILL.md et les skills voisins. Aucune commande d'installation n'est donnée dans l'extrait du README dont je dispose, donc je ne peux pas en citer une sans l'inventer. Le coût réel se situe ailleurs. Les skills sont des fichiers texte que vous devrez relire quand votre modèle change de version, parce que les seuils numériques et les formulations de règles ont été calibrés contre des comportements observés. La v1.4.0 a modifié quatre mécanismes d'un coup, ce qui suggère un rythme de révision soutenu. Si vous forkez, la licence MIT vous laisse libre de redistribuer et de modifier, à condition de conserver l'avis de licence. Je ne donne pas d'avis juridique : lisez LICENSE pour les termes exacts.

Face à un fichier d'instructions classique

L'alternative la plus directe est un fichier d'instructions unique, du type CLAUDE.md, qui énonce des valeurs et laisse le modèle improviser la procédure. La différence n'est pas la longueur mais la forme : un CLAUDE.md décrit un état d'esprit, fable-method décrit une séquence avec des points d'arrêt. Un fichier d'instructions ne vous dira pas d'arrêter après trois cycles de vérification échoués, ni de poser une question ciblée quand aucune vérification ne peut être nommée. En contrepartie, fable-method impose une surcharge : sept étapes, des portes, des bornes, et un harnais d'eval séparé pour savoir si tout cela tient. Si votre problème est qu'un agent bâcle une tâche simple, ce dépôt ne vous aidera pas, et son propre tableau le confirme. Si votre problème est qu'un agent affirme avoir terminé sans l'avoir fait, la structure de preuve par exécution vaut la lecture.

Conclusion éditoriale

À adopter si vous faites tourner des agents sur des tâches à pièges (conflits d'autorité, rapports de complétion mensongers, exécuteurs de faible capacité) et que vous acceptez de lire les transcripts d'eval avant de faire confiance aux chiffres. À éviter si votre usage se limite à des tâches simples sur des modèles capables : le README indique lui-même qu'il n'y a aucun gain dans ce cas. Avant tout, ouvrez eval/cases/s2-surprise-trap.md et vérifiez comment le juge note, car toute la crédibilité du dépôt repose sur ce protocole.

Sources officielles

1. Issues
2. License: MIT
3. README
4. Releases
5. Sahir619/fable-method on GitHub