Fanout – selektiver divergenter Denk-Durchlauf
Empirische Grundlage: die Zwei-Phasen-Evaluierung des Maintainers. Das Fanout bietet einen kleinen, aber konsistenten Vorteil bei divergenten Designaufgaben und keinerlei Vorteil bei konvergenter Ursachenanalyse. Es ist nur dann ~7x Tokens wert, wenn die Aufgabe offen UND folgenreich ist. Dieses Skill existiert, damit der Nutzen auf Abruf verfügbar ist, ohne jemals bei Routinearbeit ausgelöst zu werden.
Schritt 0 – Gate vor der Ausführung (obligatorisch)
Überprüfe die Aufgabe am Selektor. Beides muss zutreffen:
- Offen? Mehrere gültige Antworten („Design / Name / Ansatz / Hypothesen für X“). Wenn die Aufgabe „warum ist X kaputtgegangen“, „hat die Lösung funktioniert“, „was ist die Ursache“ oder irgendetwas mit einer überprüfbaren Antwort ist -> das ist KONVERGENT. Sag dem Benutzer, dass der Einzelschuss hier das bessere Werkzeug ist, und frage, ob trotzdem fortgefahren werden soll, bevor du es ausführst. Führe kein Fanout stillschweigend bei konvergenten Aufgaben durch.
- Folgenreich genug für ~7x Tokens? Eine tragende Regel / API-Form / Name / Strategie, kein Wegwerfprodukt. Wenn es nach geringer Tragweite aussieht, sag das und bestätige.
Wenn das Gate mehrdeutig ist, teile deine Einschätzung mit und frage. Sobald es bestanden ist, fahre fort.
Schritt 1 – das Problem erfassen
Akzeptiere die Problemstellung aus: einer per @ erwähnten Datei, einem Dateipfad oder eingefügtem Text in der Nachricht des Benutzers. Wenn nur ein vages Thema angegeben wird, bitte zuerst um ein oder zwei Sätze Problembeschreibung – die Frames brauchen etwas Konkretes.
Schritt 1.5 – ORIENTIERUNG, wenn das Ziel ein Projekt-Artefakt ist (obligatorisch)
Ein /fanout <Dateipfad> sieht vororientiert aus, ist es aber NICHT: Die Frames argumentieren allein auf Basis des Artefakts und werden selbstbewusst dem aktuellen Zustand des Projekts widersprechen, wenn du sie nicht damit fütterst. Vor Schritt 2, wenn das Problem eine Datei (oder benennt) in einem Projektordner ist – ein Pflichtenheft, Entscheidungsdokument, CHECKPOINT-Thread, Code-Datei – lies zuerst das CHECKPOINT.md dieses Projekts bis zum Ende (und dessen CLAUDE.md, falls der Hook es nicht bereitgestellt hat). Die SessionStart-Quittung ist eine Byte-/Zeilenanzahl, NICHT die Datei – eine Vorschau ist kein Lesen. Extrahiere dann die tragenden Randbedingungen (Fristen, Finanzierungs-/Sequenzierungs-Gates, bestehende Entscheidungen, was bereits versucht/verworfen wurde, harte Zahlen) und füge sie wörtlich in JEDEN Frame-Prompt UND den des Kritikers ein, genauso wie den Artefakttext. Ein Frame, der das Artefakt, aber nicht den Projektzustand erhält, ist ein dokumentierter Fehler (ein echtes Fanout zu einer Kostenspezifikation lieferte eine „verfrühte, mach es nach dem Break-even“ Rahmung, die das CHECKPOINT des Projekts direkt widersprach). Überspringe diesen Schritt NUR, wenn das Problem wirklich projektfrei ist (eine eingefügte abstrakte Frage, eine Namens-/API-Form-Übung ohne dahinterstehenden lebendigen Zustand).
Schritt 2 – DIVERGENZ (5 parallele Agent-Aufrufe, eine Nachricht)
Feuere 5 general-purpose-Agenten PARALLEL (eine Nachricht, 5 Tool-Aufrufe). Gib jedem das gleiche Problem und EINE eindeutige Perspektive. Die Anweisung für jeden Agenten:
„Analysiere NUR aus deiner zugewiesenen Perspektive. Generiere 4-6 UNTERSCHIEDLICHE Ansätze/Ideen; nenne für jeden die Fehlermodi (Fallstricke), die er mit sich bringt, und benenne den Mechanismus. Sei spezifisch, benenne Mechanismen, schwafle nicht, bewerte nicht, bewerte deine eigenen Ideen nicht. Halte es knapp (dies fließt in einen Kritiker-Durchlauf).“ Gib die Ausgabe direkt zurück (keine Datei-Schreibvorgänge, es sei denn, der Benutzer hat darum gebeten, zu speichern).
Die 5 Perspektiven (wörtlich):
- ARCHITEKTUR / SYSTEME – denke in Zustandsautomaten, Datenflüssen und wo Informationen transformiert oder verloren gehen; was das System auf der Ebene unterhalb des sichtbaren Verhaltens tut; wie es unter Parallelität, Ausfall oder Skalierung bricht.
- ADVERSARIAL / TEUFELSANWALT – nimm an, jede Option hat einen fatalen Fehler, und finde ihn; was nimmt jede stillschweigend an; was wäre wahr, wenn die offensichtliche Antwort eine Täuschung ist.
- ERSTE PRINZIPIEN – reduziere auf den zugrunde liegenden Mechanismus, baue aus echten Randbedingungen neu auf, misstraue Konventionen; was ist tatsächlich erforderlich vs. bloß üblich.
- PRAKTIKER / OPERATOR – du hast dies in Produktion betrieben und wurdest um 3 Uhr morgens deswegen alarmiert; kümmere dich um Feldausfälle, Randfälle, betrieblichen Aufwand, Beobachtbarkeit, die Lücke zwischen Design und der On-Call-Realität.
- ALLGEMEINER AUSSENSTEHENDER – kein Domänenkontext; was intuitiv Sinn ergibt; misstraue Jargon, der Zirkelschlüsse verbirgt; die im Nachhinein offensichtliche Falle, die die internen Experten übersehen könnten.
Schritt 3 – KRITIKER (1 Agent-Aufruf)
Sobald alle 5 zurück sind, feuere EINEN general-purpose-Agenten mit allen 5 Ausgaben + dem Problem. Anweisung: "1) BEWERTE jeden Ansatz hinsichtlich Neuheit/Durchführbarkeit/Passung (0-10). 2) GRUPPIERE über die Frames hinweg nach zugrunde liegender Strategie; notiere, wo 2+ Frames konvergiert sind (diese Konvergenz ist ein Signal). 3) FALLSTRICK-VEREINIGUNG: die deduplizierte Vereinigung unterschiedlicher, mechanistisch genannter Fallstricke über alle 5 Frames hinweg, jeder mit seinem Mechanismus. 4) VERTIEFE DIE TOP 3: schärfere Version, Mechanismus, zu vermeidende Fallstricke, die riskanteste Annahme, auf der sie ruht + der billigste Weg, diese Annahme zu testen, bevor man sich festlegt, und ein konkreter erster Schritt. Ausgabeabschnitte: ## Bewertet, ## Cluster, ## Fallstrick-Vereinigung, ## Top 3 vertieft, ## Synthese (4-6 Sätze: stärkste Richtung + die Fallstricke, die sie am meisten bedrohen)."
Schritt 4 – präsentieren
Zeige dem Benutzer im Chat die ## Top 3 vertieft, ## Fallstrick-Vereinigung und ## Synthese des Kritikers an. Fasse die Konvergenz zusammen (welche Richtungen mehrere Frames unabhängig erreicht haben). Gib NICHT alle 5 rohen Frame-Ausgaben aus, es sei denn, der Benutzer fragt danach.
Standardmäßig nichts speichern (übrig gebliebene Scratch-Dateien sind ihr eigenes Chaos). Wenn der Benutzer den vollständigen Datensatz möchte, biete an, die Kritikerausgabe + Frames in einem von ihm benannten Pfad zu speichern.
Hinweise
- Nur natives Agent-Tool – führe KEIN verschachteltes
claude -pfür die Frames aus (verschachtelte CLI-Starts sind unter Berechtigungs-/Sicherheitsebenen unzuverlässig; das Agent-Tool ist der unterstützte Pfad). - Dies ist ein einmaliger Schuss pro Aufruf (n=1). Wenn der Benutzer eine Varianzprüfung wünscht, kann er /fanout erneut aufrufen – aber die geringe Effektgröße rechtfertigt dies selten.
- Niemals automatisch auslösen. Nur die expliziten Oberflächenformen in der Beschreibung.