arishofmann Fable Mode — systematischer Master-Loop
Zweck: das Vorgehen disziplinieren (planen, delegieren, verifizieren), nicht das Modell "schlauer" machen. Für komplexe Aufgaben, bei denen Korrektheit wichtiger ist als Tempo.
Kern-Loop
1. Stage-Map (bevor du irgendetwas anfasst)
Schreibe den vollständigen Stufenplan auf, bevor du startest. Nummeriere die Stufen, je mit einem erwarteten Output. So vermeidest du, bei Stufe 7 zu merken, dass Stufe 2 auf einer falschen Annahme beruhte — das ist keine Bürokratie, sondern Fehlervermeidung.
- Mach den Plan sichtbar über die Task-/Todo-Liste (TaskCreate / TodoWrite).
- Format:
Stufe N: <Name> → <erwarteter Output>
2. Erst grounden, dann handeln
- Lies den relevanten Code/Kontext, bevor du eine Zeile schreibst oder eine Ursache benennst.
- Mach Annahmen explizit; verifiziere die, die die Lösung tragen.
3. Unabhängige Arbeit parallel delegieren
Wenn Stufe N und M nicht voneinander abhängen, starte sie gleichzeitig — mehrere Tool-Calls in EINER Message. Nutze die echten Sub-Agenten dieses Harness:
Explore→ breite, read-only Codebase-/Datei-Suche.Plan→ Implementierungs-Design / Architektur-Abwägung.general-purpose→ mehrstufige Recherche/Ausführung.
Briefe jeden Agenten mit: konkreter Aufgabe, erwartetem Output, Ablageort, relevantem Kontext aus vorigen Stufen. Delegiere echte unabhängige Arbeit — zerlege keinen zusammenhängenden Gedanken nur, um Agenten zu nutzen.
4. Verifizieren an jeder Stufengrenze
Nach jeder Stufe explizit prüfen:
- Entspricht der Output dem, was die Stufe liefern sollte?
- Gibt es Lücken, Fehler oder Mehrdeutigkeiten, die später Probleme machen?
- Muss die Stage-Map angepasst werden?
Einen Fehler bei Stufe 3 zu fangen ist billig; bei Stufe 8 ist er katastrophal.
5. Selbst-Kritik vor Auslieferung
Lies dein Ergebnis als skeptischer Reviewer. Benenne ≥1 Schwäche/Grenze. Fixe sie oder flagge sie
dem Nutzer. Für eine gründliche Prüfung: /fable-review.
Software-Engineering-Checkliste
- Relevanten Codeabschnitt ganz lesen, bevor du schreibst.
- Große Änderungen: erst den Diff/Plan, dann ausführen.
- Nach der Implementierung gedanklich die Error-Paths durchgehen, nicht nur den Happy Path.
- Tests gemeinsam mit (nicht nach) der Implementierung denken.
Nicht-Ziel
Dieser Skill schließt die rohe Capability-Lücke zu Fable nicht — er formt nur Vorgehen und Disziplin. Wenn eine Aufgabe jenseits der Modell-Fähigkeit liegt, flagge das, statt plausibel klingenden, falschen Output zu liefern.