0xVoidw/subagent-allocator

Sub-Agent-Zuteiler

Wandelt eine plan.md in eine ausführbare Aufgabentabelle um: Wer macht was, mit welchem Modell, mit welcher Denkintensität und wie wird bei Fehlern eskaliert.

Das Prinzip der Kontingent-Einsparung ist einfach: Der Großteil der Arbeit in einem Plan besteht aus dem Lesen von Dateien, der Code-Suche, dem Ausführen von Tests und dem Ändern von Code nach Spezifikation. Diese Aufgaben benötigen nicht das teuerste Modell. Teure Modelle sollten nur dort eingesetzt werden, wo wirklich Urteilsvermögen gefragt ist. Die Aufgabe dieses Skills ist es, diese beiden Kategorien zu trennen.

Eingabe

1. Pfad zur plan.md. Wenn nicht angegeben, wird im aktuellen Verzeichnis nach plan.md / PLAN.md / PLANS.md gesucht. Wird nichts gefunden, wird nachgefragt.
2. Zielplattform: claude (Claude Code), codex (OpenAI Codex) oder both. Wenn nicht angegeben, wird basierend auf der aktuellen Ausführungsumgebung entschieden; ist eine Entscheidung nicht möglich, wird einmal nachgefragt.
3. Ausrichtung (optional): sparen, ausgewogen (Standard) oder sicher. Beeinflusst nur, in welche Richtung bei Unsicherheit im Schritt 4 tendiert wird.

Nach der Bestimmung der Plattform werden die entsprechenden Referenzdateien gelesen. Diese enthalten die plattformspezifischen Modellnamen, Preisverhältnisse und Effort-Stufen:

• Claude → references/claude.md
• Codex → references/codex.md
• both → Beide werden gelesen, die Ausgabe enthält zwei Konfigurationssätze nebeneinander

Modellnamen und Preise können veralten. Die Referenzdateien sind die einzige Quelle der Wahrheit. Modellnamen nicht aus dem Gedächtnis eintragen.

Ablauf

1. Plan lesen, in Aufgabeneinheiten zerlegen

Die Schritteinteilung der plan.md wird beibehalten, nur in zwei Fällen angepasst:

• Aufteilen: Ein Schritt enthält sowohl "viel Lesen/Suchen" als auch "Urteilen/Code ändern". Der Leseteil wird als separate Aufgabe an einen günstigen Sub-Agenten ausgelagert, der nur eine Zusammenfassung zurückgibt.
• Zusammenfassen: Mehrere aufeinanderfolgende kleine Schritte bearbeiten dieselben Dateien und benötigen denselben Kontext. Sie werden zu einer Aufgabe zusammengefasst, um ein erneutes Laden des Kontexts zu vermeiden.

Nicht übermäßig aufteilen. Jeder Sub-Agent hat Startkosten (erneutes Lesen des Kontexts, Schreiben von Übergabeanweisungen). Kleine Aufgaben, die in wenigen Minuten erledigt sind, sollte der Haupt-Agent direkt ausführen. Im Dokument wird dies mit "Haupt-Agent führt direkt aus" markiert.

2. Jede Aufgabe mit fünf Markern versehen

Marker	Frage	Werte
Klarheit	Ist die Spezifikation bereits festgelegt und kann einfach befolgt werden?	klar / teilweise / offen
Fehlerkosten	Sind Fehler leicht zu finden und rückgängig zu machen?	niedrig / mittel / hoch
Überprüfbarkeit	Gibt es Tests, Builds, Linter oder Skripte, die automatisch über Erfolg/Misserfolg entscheiden?	vorhanden / ergänzbar / keine
Lesemenge	Wie viel Material muss gelesen werden, bevor die Arbeit beginnt?	wenig / viel
Auswirkungsbereich	Ist die Änderung lokal oder modulübergreifend/architekturrelevant?	lokal / modulübergreifend / architekturell

Wenn die plan.md etwas nicht klar beschreibt, wird nach der wahrscheinlichsten Situation geurteilt und dies in der Spalte "Annahmen" der Ausgabe vermerkt. Nicht anhalten und jede einzelne Frage stellen.

3. Vier Leistungsstufen zuordnen

Die plattformspezifischen Modelle finden sich in den Referenzdateien. Hier werden nur die Stufen festgelegt:

Stufe	Verwendung	Typische Aufgaben
T0 Leicht	klar + niedrige Kosten + Ergebnis leicht überprüfbar	Dateien durchsuchen, Logs lesen, Tests ausführen und berichten, Klassifizieren, Extrahieren, Zusammenfassen
T1 Standard	klar + lokal + überprüfbar	Funktion nach Spezifikation implementieren, lokalisierten Bug beheben, Tests schreiben, Dokumentation schreiben, UI-Umsetzung
T2 Haupt	teilweise klar, oder modulübergreifend, oder erfordert Debugging-Urteilsvermögen	Mehrdateien-Funktionen, Fehler unklarer Ursache beheben, Code-Review, Ergebnisse von Sub-Agenten integrieren
T3 Flaggschiff	offen + architekturell, oder hohe Fehlerkosten und nicht automatisch überprüfbar	Architekturentscheidungen, Plan für großes Refactoring, Abwägung mehrerer widersprüchlicher Einschränkungen, Steuerung mehrerer Sub-Agenten

Reihenfolge der Beurteilung: Zuerst T1 annehmen, dann prüfen, ob es Gründe für eine niedrigere oder höhere Stufe gibt.

• Grund für eine niedrigere Stufe (T0): Die Aufgabe besteht im Wesentlichen darin, etwas zu "finden und zu berichten", ohne Code zu produzieren, der zusammengeführt werden muss.
• Grund für eine höhere Stufe (T2): Die Klarheit ist nicht "klar", oder der Auswirkungsbereich ist nicht "lokal".
• Grund für die höchste Stufe (T3): Es müssen gleichzeitig "offen oder architekturell" UND "Fehler kosten viel" zutreffen. Wenn nur eines zutrifft, wird T2 mit hohem Effort verwendet.

In einem normalen Plan gibt es in der Regel 0 bis 2 T3-Aufgaben. Wenn die Hälfte der Aufgaben T3 ist, muss die Aufteilung überprüft werden. Meist wurden "Lesen" und "Urteilen" miteinander verbunden.

4. Denkintensität (Effort) festlegen

Effort ist ein feinerer Regler als der Modellwechsel. Zuerst wird dieser eingestellt.

• Start: Immer mit dem Standard-Startwert aus der Referenzdatei für die entsprechende Stufe.
• Überprüfbarkeit = vorhanden: Startwert beibehalten, sogar eine Stufe niedriger. Wenn das Modell sich selbst durch Tests überprüfen kann, bringt hoher Effort wenig Nutzen.
• Überprüfbarkeit = keine UND Fehlerkosten ≥ mittel: Eine Stufe höher.
• Jemand wartet in Echtzeit auf das Ergebnis: Eine Stufe niedriger, Geschwindigkeit priorisieren.
• Ausrichtung sparen: Bei Unsicherheit den niedrigeren Wert nehmen; bei sicher den höheren.

Jenseits von high sind die Kosten für eine weitere Erhöhung des Efforts oft ähnlich hoch wie der direkte Wechsel zum Modell der nächsthöheren Stufe mit niedrigem Effort. Daher wird die Eskalationsleiter wie folgt definiert:

1. Zuerst Überprüfungsmittel ergänzen (ihm einen ausführbaren Test- oder Prüfbefehl geben)
2. Effort um eine Stufe erhöhen, maximal bis high
3. Zum Modell der nächsthöheren Stufe wechseln, Effort mit dem niedrigsten Startwert dieser Stufe beginnen

Ausnahme: Codex T0. Hier ist das Preis-Leistungs-Verhältnis auch bei hohem Effort sehr gut, siehe references/codex.md für Details.

5. Qualitätssicherung

Kontingent-Einsparung darf nicht auf Kosten von Nacharbeit gehen. Nacharbeit ist teurer als das anfängliche Verwenden des richtigen Modells. Die folgenden Maßnahmen gewährleisten, dass die Qualität nicht spürbar nachlässt:

• Jede Aufgabe muss ein Erfolgskriterium haben. Kriterien, die als Befehl formuliert werden können (z. B. pytest tests/x, npm run build), werden als solche formuliert. Aufgaben ohne formulierbares Erfolgskriterium werden um eine Stufe höher eingestuft.
• Code-Änderungen und kritische Entscheidungen bleiben ab T1. T0 liest nur oder schreibt Dinge, die nicht in den Hauptzweig gelangen (Berichte, Checklisten).
• Nach Abschluss durch ein günstiges Modell wird der Diff von einem Modell der nächsthöheren Stufe geprüft. Die Diff-Prüfung liest nur die geänderten Teile, verbraucht wenig Tokens, verhindert aber die meisten Probleme. Sie wird als separater Review-Aufgabe am Ende jeder Phase in der Zuteilungstabelle aufgeführt.
• Sub-Agenten geben nur Schlussfolgerungen zurück. In der Rollenbeschreibung werden das Rückgabeformat und die Längenbegrenzung festgelegt (z. B. "Zusammenfassung von maximal 200 Zeichen + Liste der relevanten Dateipfade"), um lange Ausgaben zu vermeiden, die den Kontext des Haupt-Agenten überfluten.

6. Ausführungsreihenfolge festlegen

• Voneinander unabhängige Aufgaben werden als parallel ausführbar markiert.
• Aufgaben mit demselben Modell werden nach Möglichkeit gruppiert. Der Modellwechsel erfolgt an natürlichen Bruchstellen zwischen Phasen. Häufige Modellwechsel unterbrechen den Cache und zahlen die Kontextkosten erneut.
• Plattformspezifische Hinweise (Cache-Zugehörigkeit, Aufschläge für lange Kontexte usw.) finden sich in den Referenzdateien. Wenn zutreffend, werden sie in der Ausgabe unter "Hinweise" aufgeführt.

Ausgabe

Im selben Verzeichnis wie die plan.md wird plan.dispatch.md mit der folgenden Struktur erstellt. Bei vielen Aufgaben enthält die Tabelle alle Aufgaben. Rollenkarten werden nur für Sub-Agenten-Aufgaben geschrieben.

# Sub-Agent-Zuteilung: <Planname>

Quelle: <Pfad zur plan.md>　Plattform: <claude / codex / both>　Ausrichtung: <sparen / ausgewogen / sicher>

## Übersicht

| # | Aufgabe | Ausführender | Stufe | Modell | effort | Abhängigkeit | Parallel |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | … | Sondierer | T0 | … | … | keine | mit 2 |

Stufenverteilung: T0 ×n, T1 ×n, T2 ×n, T3 ×n
Haupt-Agent: <Modell> / <effort>, zuständig für <Koordination, Integration, Endabnahme usw.>

## Ausführungsphasen

### Phase 1: <Name> (Modell: …)
- Aufgaben 1, 2 parallel
- Phasenende-Review: <Wer reviewt, was>

## Rollenkarten

### Aufgabe 1: <Name>
- **Rolle**: <Ein-Satz-Beschreibung, z. B. "Nur-Lese-Sondierer: Alle Aufrufstellen der alten Schnittstelle lokalisieren">
- **Modell / effort**: … / …
- **Ziel**: …
- **Eingabe**: <Zu lesende Dateien, Verzeichnisse, Fehlermeldungen>
- **Einschränkungen**: <Was nicht geändert werden darf, welche Konventionen einzuhalten sind>
- **Erfolgskriterium**: <Befehl oder überprüfbarer Zustand>
- **Rückgabeformat**: <Inhalt und Längenbegrenzung>
- **Eskalationsleiter**: Überprüfung ergänzen → effort auf … erhöhen → zu … / … wechseln
- **Begründung der Auswahl**: <Ein Satz, der die fünf Marker widerspiegelt>

## Annahmen und Hinweise
- <Stellen, die die plan.md nicht klar beschreibt und die vom Skill abgeleitet wurden>
- <Plattformspezifische Kostenfallen>

## Geschätzte Einsparung
Grober Schätzwert relativ zur Standardkonfiguration "Alle Aufgaben mit Hauptmodell": <z. B. "Etwa die Hälfte der Aufgaben wird auf T0/T1 reduziert, wobei die Kosten pro Aufgabe auf 1/2 bis 1/20 sinken">

Die Felder "Ziel", "Eingabe", "Einschränkungen" und "Erfolgskriterium" der Rollenkarte sind die Prompt-Vorlagen, die direkt an den Sub-Agenten übergeben werden können. Sie werden so formuliert, dass sie unabhängig verständlich sind, da der Sub-Agent den Rest der plan.md nicht sieht.

"Geschätzte Einsparung" gibt nur die Größenordnung und die Begründung an. Es werden keine genauen Prozentzahlen erfunden. Der tatsächliche Verbrauch hängt von der Aufgabe selbst ab. Dem Benutzer wird empfohlen, nach dem Durchlauf die Verbrauchsstatistiken zu überprüfen und die Einstellungen entsprechend anzupassen.

Beispiel

Die plan.md enthält einen Schritt:

3. Ersetze alle Verwendungen von oldLogger im Verzeichnis utils/ durch newLogger. Beachte, dass an einigen Stellen ein benutzerdefinierter Formatter übergeben wird.

Verarbeitung: Dieser Schritt mischt "alle Aufrufstellen finden" (hohe Lesemenge, nur lesend) und "Ersetzen und Umgang mit Formatter-Ausnahmen" (Code-Änderung, Ausnahmen erfordern Urteilsvermögen). Aufteilen in zwei Aufgaben:

#	Aufgabe	Ausführender	Stufe	effort	Begründung
3a	Alle Aufrufstellen von oldLogger auflisten, die mit benutzerdefiniertem Formatter markieren	Sondierer	T0	Startwert	Nur lesend, Fehler werden durch den grep von 3b erkannt
3b	Ersetzung gemäß Liste durchführen, Formatter-Ausnahmen einzeln anpassen	Implementierer	T1	Startwert	Spezifikation klar, Erfolgskriterium ist grep -r oldLogger utils/ ist leer und Tests bestehen

Wenn kein Test das Verhalten des Formatters abdeckt, wird der Effort von 3b um eine Stufe erhöht und dies in "Annahmen und Hinweise" vermerkt.