ingo-eichhorst/der-agent-tickt-anders/3-task-splitter

Task-Splitter (Phase 3: Implementieren, vor dem ersten Edit zerlegen)

Dritte Phase des Betriebsmodells aus Kapitel 4. Die Zerlegung geschieht, bevor die erste Codeaenderung beginnt, nicht waehrend der Generierung. Ein einzelner grosser Implementierungsauftrag bündelt zu viele Entscheidungen im selben Kontext und Denkbudget. Der Splitter verkleinert den jeweiligen Auftrag, bis jeder Teil fuer sich unter der Kapazitaet sitzt.

Wann der Splitter laeuft

Sobald ../2-approach-router einen Zerlegungsauftrag ausgibt, also wenn die effektive Stufe den 80-Prozent-Horizont des gewaehlten Modells ueberschreitet (Stufe 7-8 je nach Modell, ab 9-10 zwingend). Unter dem Horizont bleibt die Aufgabe ein Lauf und der Splitter ruht.

Was ein Subtask enthaelt

Jeder Subtask ist ein vollstaendiges kleines Arbeitspaket, nicht ein Listenpunkt:

• Verhalten: was der Subtask beobachtbar aendert.
• Akzeptanzkriterium: das Orakel, an dem der Empfaenger (Kapitel 5) den Erfolg

misst.

• Beruehrungspunkte: die erwarteten Dateien, Module und Vertraege.
• Rueckrollpunkt: wie sich der Subtask im Fehlerfall zuruecknehmen laesst.

Abhaengigkeiten zwischen den Paketen stehen in der Tasktabelle, mit Reihenfolge, statt erst zur Laufzeit entdeckt zu werden.

Vorgehen

1. Schnittkanten finden. Entlang von Verhalten und Vertraegen schneiden, nicht

entlang von Dateien. Ein guter Schnitt trennt Ziele, die je ein eigenes Orakel haben.

1. Tasktabelle bauen. Subtask, Akzeptanzkriterium, Beruehrungspunkte,

Rueckrollpunkt, Abhaengigkeiten, Reihenfolge.

1. Rekursiv pruefen. Ein Paket, das erneut mehrere unabhaengige Ziele oder

Vertraege umfasst, wird weiter zerlegt.

1. Zurueck in die Kette. Jeder Subtask laeuft durch ../1-complexity-scout

(neu schaetzen) und ../2-approach-router (neu routen). So sitzt jeder Teil einzeln unter der Kapazitaet.

Die Falle

Der teuerste Fehler ist eine Zerlegung, die nur optisch teilt: ein grosser Auftrag zerfaellt in viele Listenpunkte, die einzeln nicht ausfuehrbar sind. Der Pruefstein ist hart: Jeder Subtask muss fuer sich ausfuehrbar, pruefbar und im Fehlerfall zurueckrollbar sein. Wo das nicht gilt, ist der Schnitt falsch gelegt.

Werkzeug ist austauschbar

Die Struktur kann eine TODO-Liste, Task-Masters expand, die tasks-Phase von Spec Kit, die Story-Zerlegung von BMAD oder Git-Issues tragen. Der Splitter definiert den Vertrag (was ein Subtask enthaelt), nicht das Speicherformat.

Grenzen

• Ein guter Schnitt braucht Verstaendnis der Vertraege. Bei unklaren Grenzen erst

../1-complexity-scout und ggf. 03-quellenkodierung-transmitter/spec-signal nachschaerfen.

• Zu feine Schnitte erzeugen Uebergabekosten. Ziel ist der groebste Schnitt, bei

dem jeder Teil noch unter dem Horizont liegt.

Quellen

• Anthropic, Building Effective Agents (Orchestrator-Worker, Prompt Chaining).

https://www.anthropic.com/engineering/building-effective-agents

• Task-Master (analyze-complexity und expand).

https://github.com/eyaltoledano/claude-task-master

• GitHub, Spec Kit (getrennte Phasen Specify, Plan, Tasks, Implement).

https://github.com/github/spec-kit

• BMAD-METHOD (Zerlegung eines PRD in Stories und Subtasks).

https://github.com/bmad-code-org/BMAD-METHOD

• Jesse Vincent, Superpowers (kleine Arbeitspakete, zweistufiges Review).

https://github.com/obra/superpowers