Fanout – passage de divergence sélectif par idéation
Base empirique : l'évaluation en deux phases du mainteneur. Le fanout apporte un avantage faible mais constant sur les tâches de conception divergentes et rien sur le travail convergent de cause racine. Il vaut ~7x tokens uniquement lorsque la tâche est ouverte ET à enjeux élevés. Ce skill existe pour que ce levier soit disponible à la demande sans jamais se déclencher sur du travail routinier.
Étape 0 – porte avant exécution (obligatoire)
Vérifiez la tâche par rapport au sélecteur. Les deux conditions doivent être vraies :
- Ouverte ? Plusieurs réponses valables (« conception / nom / approche / hypothèses pour X »). Si la tâche est « pourquoi X a cassé », « le correctif a-t-il fonctionné », « quelle est la cause racine », ou tout ce qui a une seule réponse vérifiable -> c'est CONVERGENT. Dites à l'utilisateur que le coup unique est le meilleur outil ici, et demandez-lui s'il souhaite continuer avant d'exécuter. N'exécutez pas silencieusement sur des tâches convergentes.
- Assez d'enjeux pour ~7x tokens ? Une règle structurante / une forme d'API / un nom / une stratégie, pas un gadget. Si cela semble peu risqué, dites-le et confirmez.
Si la porte est ambiguë, exposez votre lecture et demandez. Une fois validée, passez à la suite.
Étape 1 – obtenir le problème
Acceptez l'énoncé du problème depuis : un fichier mentionné par @, un chemin de fichier, ou un texte collé dans le message de l'utilisateur. Si seul un sujet vague est donné, demandez une ou deux phrases de cadrage du problème d'abord – les trames ont besoin de quelque chose de concret.
Étape 1.5 – ORIENTER si la cible est un artefact du projet (obligatoire)
Un /fanout <chemin_fichier> semble pré-orienté, mais ce n'est PAS le cas : les trames
raisonnent uniquement à partir de l'artefact et contrediront avec confiance l'état vivant
du projet si vous ne le leur fournissez pas. Avant l'Étape 2, si le problème est (ou nomme)
un fichier dans un dossier de projet – une spec, un document de décision, un thread
CHECKPOINT, un fichier de code – lisez le CHECKPOINT.md de ce projet jusqu'à la fin
d'abord (et son CLAUDE.md si le hook ne l'a pas remonté). Le récépissé SessionStart
est un nombre d'octets/lignes, PAS le fichier – un aperçu n'est pas une lecture. Ensuite,
extrayez les contraintes structurantes (échéances, portes de financement/séquencement,
décisions en place, ce qui a déjà été essayé/rejeté, chiffres clés) et collez-les textuellement
dans CHAQUE instruction de trame ET celle du critique, de la même manière que le texte de
l'artefact. Une trame qui reçoit l'artefact mais pas l'état du projet est un échec documenté
(un vrai fanout sur une spec de coût a produit un cadrage « prématuré, à faire après le
seuil de rentabilité » que le CHECKPOINT du projet contredisait directement).
Sautez cette étape UNIQUEMENT lorsque le problème est vraiment sans projet (une question
abstraite collée, un exercice de nommage/surface API sans état vivant derrière).
Étape 2 – DIVERGENCE (5 appels Agent parallèles, un seul message)
Lancez 5 agents general-purpose EN PARALLÈLE (un seul message, 5 appels d'outil).
Donnez à chacun le même problème et UN point de vue distinct. L'instruction de chaque
agent :
« Analysez UNIQUEMENT depuis votre point de vue attribué. Générez 4 à 6 approches/idées
DISTINCTES ; pour chacune, nommez les modes de défaillance (pièges) qu'elle porte et
décrivez le mécanisme. Soyez précis, nommez les mécanismes, ne prenez pas de pincettes,
ne classez pas, n'évaluez pas vos propres idées. Restez concis (ceci alimente un passage
critique). » Renvoyez la sortie directement (pas d'écriture de fichier sauf si
l'utilisateur a demandé de sauvegarder).
Les 5 points de vue (textuellement) :
- ARCHITECTURE / SYSTÈMES – pensez en machines d'état, flux de données, et là où l'information est transformée ou perdue ; ce que le système fait à la couche en dessous du comportement visible ; comment il casse sous la concurrence, la panne ou le passage à l'échelle.
- ADVERSARIAL / AVOCAT DU DIABLE – supposez que chaque option a un défaut fatal et trouvez-le ; qu'est-ce que chacune suppose silencieusement ; que serait-il vrai si la réponse évidente était un leurre.
- PREMIERS PRINCIPES – réduisez au mécanisme sous-jacent, reconstruisez à partir des contraintes réelles, méfiez-vous des conventions ; ce qui est réellement requis vs simplement coutumier.
- PRATICIEN / OPÉRATEUR – vous avez exécuté cela en production et avez été appelé pour ça à 3h du matin ; souciez-vous des pannes terrain, des cas limites, de la charge opérationnelle, de l'observabilité, de l'écart entre la conception et la réalité d'astreinte.
- OUTSIDER GÉNÉRALISTE – aucun contexte de domaine ; ce qui a du sens intuitivement ; méfiance envers le jargon qui cache des raisonnements circulaires ; le piège « évident avec le recul » que les experts internes pourraient manquer.
Étape 3 – CRITIQUE (1 appel Agent)
Une fois les 5 résultats reçus, lancez UN agent general-purpose avec les 5 sorties
- le problème. Instruction : « 1) NOTEZ chaque approche sur la nouveauté/viabilité/adéquation (0-10).
- REGROUPEZ entre les trames par stratégie sous-jacente ; notez où 2+ trames ont convergé (cette convergence est un signal). 3) UNION DES PIÈGES : l'union dédupliquée des pièges distincts, exprimés mécanistiquement, issus des 5 trames, chacun avec son mécanisme.
- APPROFONDISSEZ LES 3 MEILLEURES : version plus affinée, mécanisme, pièges à éviter, l'hypothèse la plus risquée sur laquelle elle repose + le moyen le moins coûteux de tester cette hypothèse avant de s'engager, et une première étape concrète. Sections de sortie : ## Notées, ## Regroupements, ## Union des pièges, ## Top 3 approfondies,
Synthèse (4-6 phrases : la direction la plus forte + les pièges qui la menacent le plus). »
Étape 4 – présentation
Montrez à l'utilisateur les ## Top 3 approfondies, ## Union des pièges et ## Synthèse du critique dans le chat. Résumez la convergence (quelles directions des trames multiples ont atteintes indépendamment). Ne déversez PAS les 5 sorties brutes des trames sauf demande explicite.
Par défaut, ne persistez rien (les fichiers de travail résiduels sont un désordre en soi). Si l'utilisateur souhaite l'enregistrement complet, proposez de sauvegarder la sortie du critique + les trames dans un chemin qu'il nomme.
Notes
- Outil Agent natif uniquement – n'utilisez PAS un sous-shell
claude -pimbriqué pour les trames (les lancements CLI imbriqués ne sont pas fiables sous les couches de permissions/sécurité ; l'outil Agent est le chemin pris en charge). - Un seul passage par invocation (n=1). Si l'utilisateur souhaite une vérification de variance, il peut invoquer /fanout à nouveau – mais la faible taille d'effet le justifie rarement.
- Ne jamais déclencher automatiquement. Uniquement les formes de surface explicites décrites ci-dessus.