Aufgabenaufteiler — kostengünstigste korrekte Ausführung

Was macht Aufgabenaufteiler — kostengünstigste korrekte Ausführung?

Ziel: Erledige die Hauptaufgabe mit den geringsten Gesamtkosten, die dennoch die Qualität erfüllt. Zwei Hebel: (1) Leite jede Arbeit an die günstigste geeignete Stufe weiter, (2) bezahle den Cold-Start-Kontext jedes Unter-Agenten nur einmal, indem gleichartige Arbeit in einen Thread gebündelt wird.

Lese references/routing-rubric.md vor der Bewertung und references/batch-brief-template.md vor dem Schreiben einer Batch-Anweisung.

Harte Regeln

• T0-Arbeit startet niemals einen Agenten. Deterministische Schritte (install, mkdir, mv, ein Konfigurationswert, Ausführen eines Generators) werden inline im Hauptthread ausgeführt. Ein Cold-Start-Unter-Agent kostet mehr als der Befehl.
• Verwende niemals subagent_type: "fork" für günstige Stufen. Ein Fork läuft immer mit dem übergeordneten Modell und ignoriert model. Verwende general-purpose (oder Explore für schreibgeschützte Suche) mit einem expliziten model und effort.
• Dieses Skill autorisiert ausdrücklich das Setzen von effort bei jedem Agentenaufruf, den es tätigt, unter Verwendung der Stufentabelle. Übergib immer sowohl model als auch effort.
• Verifikation durch Skripte, nicht durch Modelle. Tests, Lint, Typprüfung und Build werden vom Hauptthread ausgeführt. Gib kein Modell aus, um Code zu überprüfen, den ein Skript prüfen kann.
• Eskaliere nur die fehlschlagende Unteraufgabe, eine Stufe, einmalig. Nach einer Eskalation anhalten und den Benutzer fragen.
• **Bündele niemals zwei Unteraufgaben, die dieselbe Datei bearbeiten, in unterschiedliche Batches derselben Welle.

Stufentabelle (Standardeinstellungen — mit dem Routing-Protokoll kalibrieren)

Stufe	Punkte	Läuft als	Typische Arbeit
T0	0	Hauptthread, inline shell	Abhängigkeiten installieren, Verzeichnisse anlegen, umbenennen, env/config-Wert setzen
T1	1–3	model: haiku, effort: low	Boilerplate nach bestehendem Muster, Kopierarbeiten, einfaches CRUD-Verdrahten, Doku, Testdaten
T2	4–6	model: sonnet, effort: medium	Normaler Feature-Code, Komponenten, Endpunkte, Tests nach bestehenden Mustern
T3	7–8	model: sonnet, effort: high	Mehrdateien-Logik, State-Management, Integrationen, knifflige Bugs, Authentifizierung/Zahlungen/Sicherheit
T4	9–10	model: opus, effort: high	Architektur, bereichsübergreifendes Design, Datenmodell, schwieriges Debugging, Performance/Concurrency

Relative Kostengewichte für die Vorschau: haiku = 1, sonnet = 3, opus = 5; Aufwandsmultiplikator low = 1, medium = 1.5, high = 2.5. T0 = ~0.

Arbeitsablauf

Phase 0 — Erfassen & Speichern

1. Formuliere die Hauptaufgabe in ≤10 Zeilen neu: Ziel, Einschränkungen, Abnahmekriterien, Stack, nicht im Umfang enthalten.
2. Leite einen Slug ab. Suche nach einem vorhandenen Protokoll in <project>/.claude/task-splitter/ (ls .claude/task-splitter/ 2>/dev/null). Wenn eines zu dieser Aufgabe passt und unerledigte Unteraufgaben hat → damit fortfahren (springe zur ersten Phase, deren Arbeit nicht erledigt ist).
3. Andernfalls erstelle <project>/.claude/task-splitter/<YYYY-MM-DD>-<slug>.md aus templates/split-ledger.md und fülle den Abschnitt „Context“. Aktualisiere es nach jeder Phase. Im Plan-Modus, wenn das Schreiben von Dateien außerhalb der Planungsdatei nicht erlaubt ist, füge den Protokollinhalt unter einer Überschrift ## Ledger in die Planungsdatei ein und schreibe die echte Datei als ersten T0-Schritt nach der Genehmigung.

Phase 1 — Leichte Erkundung

Lies nur, was für die Aufteilung benötigt wird: Manifest (package.json, pyproject usw.), Einstiegspunkte, die Dateien, die das Feature berührt, vorhandene Hilfsprogramme zur Wiederverwendung. Wenn eine breite Suche erforderlich ist, verwende EINEN Explore-Agenten mit model: haiku, effort: low und frage nur nach Pfaden + einzeiligen Ergebnissen. Zeichne wiederverwendbare Hilfsprogramme und genaue Dateipfade im Protokoll auf — sie werden zu den Kontextpaketen, die günstige Agenten davon abhalten, erneut zu erkunden.

Phase 2 — Aufteilen

Zerlege die Arbeit in atomare Unteraufgaben. Jede Unteraufgabe hat: id (S1, S2…), goal (ein Satz), files (genaue Pfade, neu oder vorhanden), depends_on (IDs), done_check (ein Befehl wie pnpm test foo oder ein genaues Kriterium), type (kurzes Tag: install, scaffold, component, endpoint, test, migration, refactor, config, docs, debug, design…). Atomar = Ein Agent kann sie abschließen, ohne Entscheidungen zu treffen, die zu einer anderen Unteraufgabe gehören. Ziehe Designentscheidungen in eine eigene frühe Unteraufgabe (oft T4) heraus, damit spätere Unteraufgaben mechanisch und günstig sind.

Phase 3 — Bewerten & Weiterleiten

Bewerte jede Unteraufgabe mit dem 5-Dimensionen-Bewertungsschema in references/routing-rubric.md (Mehrdeutigkeit, Argumentationstiefe, Auswirkungsradius, benötigter Kontext, Neuheitsgrad; 0–2 pro Dimension), wende die Überschreibungsregeln an und ordne dann Punktzahl → Stufe zu. Überprüfe dann ~/.claude/task-splitter/routing-log.md (falls vorhanden): Wenn ein type in ≥2 seiner letzten 3 Läufe auf einer Stufe eskaliert wurde, starte ihn eine Stufe höher; wenn er ≥3 Mal hintereinander beim ersten Versuch auf einer Stufe niedriger als gewählt bestanden hat, erwäge, eine Stufe herabzustufen.

Phase 4 — Bündeln

1. Baue Abhängigkeitswellen: Welle 1 = Unteraufgaben ohne unerfüllte Abhängigkeiten; Welle N = jene, deren Abhängigkeiten alle in früheren Wellen sind.
2. Gruppiere innerhalb jeder Welle nach (model, effort), dann nach Codebereich (gleicher Feature-Ordner / Modul), damit ein Agent verwandte Dateien einmal lädt.
3. Grenzen pro Batch: ≤6 Unteraufgaben oder ein zusammenhängender Bereich; keine Datei, die von zwei Batches in derselben Welle bearbeitet wird (verschiebe die konfligierende Unteraufgabe in denselben Batch oder die nächste Welle).
4. Füge winzige Batches zusammen: Eine einzelne T1-Unteraufgabe gesellt sich zu einem anderen T1-Batch in derselben Welle, falls vorhanden; eine einzelne T1-Unteraufgabe, die fast mechanisch ist, kann stattdessen inline erledigt werden.
5. T0-Unteraufgaben werden in einem einzigen Inline-Schritt zu Beginn ihrer Welle gruppiert.

Phase 5 — Kostenübersicht (Genehmigungsschritt)

Schreibe in die Planungsdatei (oder zeige sie dem Benutzer, außerhalb des Plan-Modus):

| Welle | Batch | Modell / Aufwand | Unteraufgaben | Geschätzte Kosten |
|-------|-------|-----------------|---------------|-------------------|
| 1     | inline| main / shell    | S1, S2        | ~0                |
| 1     | B1    | haiku / low     | S3, S4        | 2                 |
| 1     | B2    | sonnet / medium | S5            | 4.5               |
| 2     | B3    | opus / high     | S6            | 12.5              |
Gesamt ≈ 19 Einheiten  (Basislinie alles opus / high ≈ 75 Einheiten → ~75% günstiger)

Geschätzte Kosten = Anzahl der Unteraufgaben × Modellgewicht × Aufwandsmultiplikator. Füge die Basislinie alles opus/high ein, damit die Ersparnis sichtbar ist. Im Plan-Modus beende mit ExitPlanMode; führe vor der Genehmigung nicht aus.

Phase 6 — Ausführen

Für jede Welle in der Reihenfolge:

1. Führe den T0-Inline-Schritt der Welle aus.
2. Starte alle Batches der Welle in EINER Nachricht (parallele Agentenaufrufe): Agent(subagent_type: "general-purpose", model: <Stufenmodell>, effort: <Stufenaufwand>, description: "<Welle>/<Batch>: <kurz>", prompt: <kurz>). Erstelle jede Kurzanweisung aus references/batch-brief-template.md. Die gemeinsame Präambel muss byte-identisch über alle Batches hinweg sein (prompt-cache-freundlich) — setze variablen Inhalt danach.
3. Warte, bis jeder Batch der Welle Bericht erstattet hat, bevor du mit der nächsten Welle beginnst. Schreibe niemals das Ergebnis eines ausstehenden Agenten zusammen oder mutmaße es.
4. Aktualisiere das Protokoll mit dem Status jedes Batches und den gemeldeten Dateien.

Phase 7 — Verifizieren & Eskalieren

1. Nach jeder Welle führt der Hauptthread die done_check-Befehle der Unteraufgaben sowie die günstigen globalen Prüfungen des Projekts (Typcheck / Lint / betroffene Tests) aus.
2. Eine fehlschlagende Unteraufgabe wird allein (oder mit anderen Fehlschlägen derselben neuen Stufe) eine Stufe höher erneut ausgeführt, wobei die fehlschlagende Ausgabe und der Bericht des vorherigen Agenten beigefügt werden.
3. Maximal eine Eskalation pro Unteraufgabe. Wenn sie immer noch fehlschlägt, anhalten und den Benutzer mit einer kurzen Diagnose fragen. T4-Fehlschläge gehen direkt zum Benutzer.

Phase 8 — Aufzeichnen & Lernen

1. Markiere das Protokoll als abgeschlossen: pro Unteraufgabe die endgültige Stufe, bestanden/eskaliert, geänderte Dateien.
2. Füge pro Unteraufgabe eine Zeile an ~/.claude/task-splitter/routing-log.md an (erstelle den Ordner/die Datei, falls nicht vorhanden; niemals innerhalb des Skill-Git-Repos): YYYY-MM-DD | <Projekt> | <Typ> | <Startstufe> | <Endstufe> | first-pass|escalated|failed
3. Berichte dem Benutzer in ≤10 Zeilen: Was erledigt wurde, endgültige Kosteneinheiten vs. Basislinie, etwaige Eskalationen, etwaige offene Punkte.

Ausgabekonventionen

• Halte den Hauptthread schlank: Agenten geben kurze Berichte zurück, keine Dateiinhalte.
• Gib dem Benutzer Tabellen, keine Prosa, für die Aufteilung und die Kostenübersicht.
• Wenn die gesamte Aufgabe ≤3 Punkte ergibt oder ≤2 Unteraufgaben hat, sage dies und erledige sie einfach direkt — eine Aufteilung würde mehr kosten, als sie spart.