juanmackie/juanskills

La Boucle Fable

Cette compétence orchestre la méthode fable-method : lisez d'abord son SKILL.md ; ses règles régissent chaque étape. Elle est installée aux côtés de cette compétence (dans le répertoire skills/fable-method/ de ce plugin, ou ~/.claude/skills/fable-method/ pour les installations manuelles). La méthode dit QUOI vérifier ; cette boucle dit QUI fait le travail : ce qui s'exécute dans le thread principal, ce qui est délégué aux sous-agents, et ce qui est attaqué avant la livraison.

La porte d'abord.

Tâche triviale selon la porte de trivialité de la méthode : faites-la simplement, vérifiez avec la seule vérification évidente, rapportez en deux phrases. Pas d'étapes, pas de sous-agents. Tout le reste exécute les quatre étapes ci-dessous dans l'ordre.

Étape 1 - PLANIFIER (le premier bookend)

1. Appliquez les étapes 0 à 3 de la méthode : classifiez la demande, définissez « fait » avec une vérification nommée, énoncez les hypothèses structurantes.
2. Délégation de preuves. Déclenchez les collecteurs de preuves en tant que sous-agents parallèles en UN SEUL message, jamais séquentiellement :
   • questions sur le code : un agent Explore par domaine distinct (« comment fonctionne X », « de quoi dépend Y »)
   • questions sur des bibliothèques ou des faits : un agent de recherche qui récupère la documentation actuelle ou effectue une recherche web
   • chaque sous-agent renvoie des conclusions distillées avec des citations, jamais des vidages de fichiers bruts
   • Un lot et un deuxième lot de suivi constituent le budget ; un troisième nécessite une raison justifiée
3. Produisez l'artefact du plan selon ce format :
   • classification
   • définition de « fait » et sa vérification
   • preuves trouvées (citées)
   • UNE approche recommandée (alternatives écartées en une ligne chacune)
   • le périmètre (les fichiers ou surfaces exacts que le travail touchera)
   • risques et hypothèses
   • et la liste de contrôle d'exécution
4. Porte de décision.
   • Forme de tâche et réversible : passez à l'étape 2 sans demander
   • Forme plan d'abord (périmètre ambigu, actions irréversibles ou tournées vers l'extérieur, ou l'utilisateur a demandé un plan) : présentez l'artefact du plan et ARRÊTEZ pour approbation

Étape 2 - EXÉCUTER

1. Travaillez la liste de contrôle dans le thread principal (utilisez l'outil todo si l'infrastructure en dispose ; cochez les éléments au fur et à mesure qu'ils sont terminés). Décider et éditer restent dans le thread principal ; seules la recherche et la vérification sont déléguées.
2. Chaque édition suit l'étape 4 de la méthode : porte d'intention avant les changements de comportement, porte de remémoration avant la première utilisation de quelque chose de non ouvert, plus petite modification correcte, modifications précises, ne jamais détruire sans regarder.
3. Les éléments mécaniques indépendants (même modification sur de nombreux fichiers, génération de fichiers isolés) peuvent être délégués à des sous-agents parallèles, en un seul message, avec isolation de l'arbre de travail s'ils peuvent toucher les mêmes fichiers.
4. Une surprise en cours d'exécution est redirigée selon la règle 7 de l'étape 2 de la méthode : dites-la, puis mettez à jour le plan ou revenez à l'étape 1. Ne forcez jamais le plan à travers une surprise.
5. L'ignorance en cours d'élément est une pause, pas une devinette : au moment où une modification s'appuierait sur un fait issu de la mémoire (une signature, une clé, un chiffre), arrêtez cet élément, déléguez un sous-agent de recherche selon la porte de remémoration de la méthode, et reprenez quand il revient.
6. Les éléments de la liste de contrôle tournés vers l'extérieur obéissent à la porte d'autorisation de la méthode : pas d'autorisation utilisateur citée, pas d'action ; l'élément se transforme en étape suivante proposée dans le rapport.
7. Points de contrôle du budget de tours. Limitez les itérations longues à ≤50 tours d'agent ; à chaque limite, écrivez un artefact de point de contrôle (ce qui a été terminé, chemins de preuves, action suivante exacte) et reprenez à partir de là. La vérification finale ne doit jamais être l'étape que la limite de tours tue — vérifiez dans le budget ou marquez-la explicitement comme en attente.

Étape 3 - VÉRIFIER (de manière adversaire)

1. Exécutez vous-même la vérification nommée, ses deux moitiés : le critère de « fait » observé (exécuté, rendu, compté), et le système environnant toujours sain (build, tests, lint pour la zone touchée).

2. Pour les changements conséquents, déclenchez des attaquants. 1 à 3 sous-agents parallèles, chacun invité à RÉFUTER le travail depuis un angle distinct, par exemple :

   • « Lis ce diff et prouve que le changement est faux ou incomplet »
   • « Exécute le comportement modifié au moment de l'exécution et trouve une entrée qui le casse »
   • « Vérifie cette affirmation par rapport aux spécifications/docs et trouve une contradiction »
   • « Diff l'ensemble complet des changements par rapport au périmètre déclaré du plan et prouve que quelque chose en dehors a changé »

   Des angles distincts valent mieux que des relecteurs identiques.

3. Un résultat qui survit à votre propre vérification retourne à l'étape 2 comme nouveau travail. Limite stricte selon la méthode : 3 cycles échoués de correction-vérification sur le même problème, ou tout blocage hors de votre contrôle, signifie arrêtez et rendez-vous avec le résultat et votre hypothèse.

Étape 4 - AUDITER ET RAPPORTER (le second bookend)

1. Auto-audit selon le mode d'audit de fable-method : pour chaque étape de la méthode, suivie, sautée, ou falsifiée. Corrigez ce qu'un passage peut corriger (généralement une affirmation non vérifiée : vérifiez-la maintenant ou requalifiez-la en réserve).
2. Livrez selon l'étape 6 de la méthode : résultat dans la première phrase, preuve de vérification montrée, réserves honnêtes, sujets de suivi seulement s'ils ont émergé du travail. Pas de noms d'étapes ni de numéros d'étapes dans le rapport ; les lignes INTENT et AUTH sont les seuls artefacts de la méthode qu'un rapport peut contenir.

Quand NE PAS utiliser cette boucle

• Tâches triviales (la porte les gère)
• Questions pures sans travail multi-étapes : la simple méthode fable-method couvre la forme
• À l'intérieur d'une phase GSD déjà orchestrée : GSD possède les étapes ici ; appliquez les règles de fable-method à l'intérieur de celles-ci au lieu d'imbriquer des boucles

Économie du modèle

La boucle est indépendante du modèle. Les sous-agents de preuve et d'attaque sont adaptés aux modèles bon marché ; conservez le thread principal (décision, édition) sur le modèle le plus fort disponible, et donnez aux attaquants plus d'effort qu'aux collecteurs lorsqu'un choix existe.

Utilisation

/fable-loop <tâche>   Lance la boucle intégralement orchestrée