breakdown – konvergente, handlungsorientierte Zerlegung
Die konvergente Ergänzung zu /fanout. /fanout öffnet ein Problem (viele gültige Antworten); /breakdown schließt es ab (ein Knoten → ein nächster Schritt). Einzelschritt, keine Unteragenten, ~1× Kosten. Basierend auf dem Session-Transkript-Crawl des Maintainers: Die lauteste Reibung war „Hör auf zu erklären, mach es einfach“, daher ist dieser Skill bewusst HANDLUNGSORIENTIERT und minimal formuliert. Wenn deine Ausgabe wie eine sanfte Erklärung klingt, ist sie falsch – kürze sie.
Schritt 1 – Den Knoten erfassen
Nimm das Problem per @-Erwähnung, Pfad oder eingefügtem Text entgegen. Ist es wirklich vage, frage einmal nach ein oder zwei Sätzen. Lies jede referenzierte Datei bis zum Ende, bevor du zerlegst. Wenn der Knoten ein Projektartefakt ist (oder darauf verweist), lies AUCH die dazugehörige CHECKPOINT.md bis zum Ende (Empfangs-/Vorschau ist kein Lesen) – das „echte Ziel“ und die „blockierende Entscheidung“ hängen vom aktuellen Projektstatus ab (Deadlines, Sequenzierungsentscheidungen, bereits Getroffenes). Eine Zerlegung ohne diesen Kontext zeigt auf den falschen nächsten Schritt. Überspringe diesen Schritt nur, wenn es sich garantiert nicht um ein Projekt handelt.
Schritt 2 – Genau diese fünf Blöcke ausgeben, knapp und in Reihenfolge
Keine Einleitung. Kein „Ich habe Zugriff auf …“. Die Frage nicht ausführlich wiederholen.
- Echtes Ziel (ein Satz). Was „erledigt“ wirklich bedeutet. Weicht das genannte Ziel vom tatsächlichen ab, sag es in einem Satz.
- Kleinster nächster Schritt (ein konkreter, physischer Schritt, der in einer Sitzung erledigt werden kann – z. B. „Öffne X und schreibe die drei Feldnamen“), nicht „Entwerfe das Schema“. Biete DANN an, es jetzt gleich zu erledigen. Erkläre nicht vorher lang und breit.
- Die eine blockierende Entscheidung – die einzelne Weggabelung, die das meiste freigibt, oder „keine – fang einfach an.“
- Gesamtplan (komprimiert) – die vollständige Checkliste unter einer einzeiligen Zusammenfassung, ausdrücklich abgeschwächt: „Ignorieren, bis Schritt 2 erledigt ist.“
- Erste Falle – der häufigste Fehlermodus und sein frühestes Signal.
Regeln
- Ein einziger Strang auf dem kritischen Pfad. Keine parallelen Arbeitsstränge auflisten.
- Klare Sprache, keine erfundenen Codes (übersetze alle Ablagekürzel in normale Worte).
- Starte die Arbeit erst, wenn der Benutzer wählt. /breakdown plant; es führt nicht aus.
- Standardmäßig nichts speichern. Falls es sich lohnt, biete an, es in die Zeile „Nächster Schritt“ der CHECKPOINT zu schreiben.