Jamie-BitFlight/delegate

Delegieren

Der Kontext des Orchestrators ist das eine Fenster, das die gesamte Sitzung über bestehen bleibt. Jede Datei, die er liest, und jede Befehlsausgabe, die er speichert, ist ausgegebenes Urteilsbudget. Unter-Agenten erhalten ein neues Fenster pro Aufgabe, sodass der Orchestrator leitet, Erfolg definiert und beurteilt; die Agenten lesen, führen aus und schreiben.

Zwei Rollen

Jede Zuweisungsaufforderung beginnt mit Your ROLE_TYPE is sub-agent. Diese Zeile ist eine Anti-Rekursionsmarkierung: Ein Unter-Agent, der dieses Skill erbt, darf keine weiteren Aufgaben delegieren. Wenn deine Aufforderung so beginnt, höre hier auf und folge references/sub-agent-contract.md. Andernfalls bist du der Delegierer und der Rest dieser Datei gilt für dich.

Wann dies gilt

Jede Anfrage, die Dateien ändert, eine Ursache untersucht, Fakten sammelt, einen Fehler behebt oder Arbeit überprüft – unabhängig von der Größe – und jeder Moment, in dem du selbst Quellcode lesen oder ein Diagnosetool ausführen würdest, anstatt die Aufgabe zu übergeben. „Es sind nur zwei Zeilen“ wird delegiert. Die einzige Ausnahme: Eine Überprüfung, die auf eine einzelne Datei beschränkt ist, die du selbst in dieser Runde bearbeitet hast.

Gilt auch, sobald die Arbeit läuft: Beurteilen eines Berichts eines Unter-Agenten (siehe Adjudizieren), erneutes Zuweisen einer Phase oder Verallgemeinern einer benannten Musterinstanz (siehe Musterausweitung).

Antworte inline, wenn die Antwort bereits in deinem Kontext ist und keine Dateiänderungen erforderlich sind.

Zerlegen

Zerlege die Anfrage in Phasen. Behalte nur die Phasen, die Arbeit produzieren; füge niemals Füllphasen hinzu.

Phase	Produziert
lesen	Das Material, von dem die Arbeit abhängt, lokalisiert und gelesen
sammeln	Externe Fakten: Dokumentationen, Stand der Technik, aktueller Systemzustand
verarbeiten	Die Analyse und der gewählte Ansatz
verifizieren	Der Ansatz, überprüft gegen den echten Code und die Umgebung
schreiben	Die Änderung
validieren	Lint-, Typüberprüfungs-, Build-Ergebnisse
testen	Testläufe, plus neue Tests, die die Änderung abdecken
berichten	Was sich geändert hat, mit Beweisen
reviewen	Unabhängige Kritik des Ergebnisses

Einige Muster wiederholen sich und haben ihre eigene Behandlung:

• Fehlerbehebung → references/fix-cycle.md: Vor der Änderung reproduzieren.
• Gleiche Änderung an vielen Zielen → ein verarbeiten-Dispatch entscheidet die Änderung; N generische Dispatches wenden sie an; ein reviewen-Dispatch prüft. Siehe parallel-work.

Zuweisen

• Eine Phase pro Dispatch. Eine Phase kann sich auf N Ziele ausbreiten (N Dispatches, gleiche Phase); sie vermischt sich nie mit einer anderen Phase.
• Sende unabhängige Dispatches zusammen in einer Runde, damit sie parallel laufen. Serialisiere nur, wenn einer das Ergebnis eines anderen verbraucht, oder wenn zwei dieselbe Datei ohne Isolation schreiben würden.
• Ergebnisse von lesen/sammeln/verarbeiten gehen in eine Datei, nicht in deinen Kontext. Gib den Pfad an die nächste Phase weiter; leite den Inhalt nicht weiter.

Den Agenten auswählen

Klassifiziere nach dem, was die Aufgabe vom Agenten verlangt, nicht nach seinem Namen:

• Spezialist – jeder Agent, dessen Beschreibung zur Domäne der Phase passt. Erhält Beobachtungen, Erfolgskriterien und Kontext. Erhält niemals Implementierungsschritte.
• Generisch – general-purpose (oder die entsprechende Umgebung) und Explore. Erhält eine vorgeschriebene Implementierung: genaue Bearbeitung, genaue Dateien, genaue Verifizierung. Explore nur für exakte Suchbegriffe.
• Reviewer – für die reviewen-Phase ein anderer Agent als der, der geschrieben hat, wobei ein Agent vom Typ Reviewer oder Prüfer für die Domäne bevorzugt wird.

Wenn kein Spezialist passt, weise generisch mit einer vorgeschriebenen Aufgabe zu.

Beide Aufforderungen beginnen mit denselben zwei Zeilen – kopiere sie wörtlich in die erste Zeile der jeweiligen Vorlage: Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <absoluter Pfad zu references/sub-agent-contract.md>.

Aufforderung – Spezialistenmodus

PHASE: <einer der Phasennamen>
TASK: <ein Satz>

OBSERVATIONS:
- <bereits in deinem Kontext befindliche Fakten: Benutzeraussagen, vorherige STATUS-Berichte, wörtliche Fehler, Datei:Zeile falls bekannt>

DEFINITION OF SUCCESS:
- <messbares Ergebnis>
- <Akzeptanzkriterien>
- <wie es verifiziert wird – ein Befehl und sein erwartetes Ergebnis, oder der Reviewer, der es prüft>

DELIVERY:
- Schreibe alles, was länger als eine Zeile ist, nach .tmp/scratch/reports/<YYYYMMDD>-<slug>.md und gib den Pfad zurück.

CONTEXT:
- Location: <wo suchen>
- Scope: <Grenzen>
- Constraints: <vom Benutzer vorgegebene Anforderungen; bestehende Muster, denen zu folgen ist>
- Commands: <die Qualitätstore des Projekts für Validieren/Testen, oder „entdecke die, die dieses Projekt definiert“>

ECOSYSTEM CONTEXT:  (Abschnitt weglassen, wenn leer)
- <Sitzungsfakten, die der Agent nirgendwo lesen kann: authentifizierte CLIs, ein PR in Überprüfung, ein anderer Agent, der live an denselben Dateien arbeitet>

YOUR TASK:
<die Zeile der Phase aus der Tabelle unten, wörtlich>

Phasen-Zeilen für YOUR TASK:

Phase	Zeile
lesen	Lokalisiere und lies das Material, von dem diese Arbeit abhängt. Schreibe genaue Pfade und zitierte Inhalte in die Lieferdatei; fasse keine Details zusammen, die eine spätere Phase benötigt. Bearbeite nichts.
sammeln	Sammle die im CONTEXT genannten externen Fakten. Zeichne jede mit ihrer Quelle in der Lieferdatei auf. Bearbeite nichts.
verarbeiten	Analysiere das Material an den in OBSERVATIONS angegebenen Pfaden. Wähle einen Ansatz; zeichne ihn und die Gründe auf, warum Alternativen ausgeschlossen wurden. Bearbeite nichts.
verifizieren	Überprüfe den gewählten Ansatz gegen den echten Code und die Umgebung im CONTEXT. Zeichne auf, wo er zutrifft und wo er scheitert. Implementiere nichts.
schreiben	Nimm die Änderung aus DEFINITION OF SUCCESS vor. Berühre nur Dateien innerhalb des CONTEXT Scope.
validieren	Führe die Befehle aus CONTEXT Commands aus oder entdecke die Lint-/Typ-/Build-Tore dieses Projekts und gib an, welche du ausgeführt hast. Berichte genaue Ausgabe, bestanden und nicht bestanden. Ein zum Schweigen gebrachter Fehler ist ein Fehler.
testen	Führe den Testaufruf aus CONTEXT Commands aus oder entdecke ihn und gib an, welchen du ausgeführt hast. Füge Tests hinzu, die die Änderung abdecken. Berichte genaue Ausgabe.
berichten	Gib an, was sich geändert hat, und die Beweise dafür: Dateien, Befehle, Ausgaben. Mache keine Behauptung, die die Beweise nicht stützen.
reviewen	Kritisiere das Ergebnis am Pfad in OBSERVATIONS anhand von DEFINITION OF SUCCESS. Berichte Lücken, Widersprüche, nicht belegte Behauptungen. Behebe nichts.

Regeln zum Ausfüllen:

• Ein Abschnitt, den du nicht aus dem bereits in deinem Kontext Befindlichen füllen kannst, wird weggelassen, nicht erfunden. Leere OBSERVATIONS oder ECOSYSTEM CONTEXT sind ein gültiger Zustand; eine Vermutung ist es nicht.
• OBSERVATIONS ist eine Durchleitung: nur das, was bereits in deinem Kontext ist. Lesen, Grepen oder Ausführen von Befehlen, um es zu füllen, ist ein Vor-Sammeln; der Agent erledigt das mit einem neuen Fenster.
• Gib Beobachtungen als Fakten an („exit code 1“, „der Fehlertext ist: …“). Wo du eine Hypothese hast, kennzeichne sie: Hypothese zu verifizieren: ….
• Constraints sind Ergebnisse und Grenzen, niemals Schritte. Das Benennen des eigenen Tores des Projekts in Commands ist eine Einschränkung, kein Schritt.
• Sage nichts, was der Agent erbt: Repository-Konventionen, Toolchain, „frei erkunden“, „verfügbare Skills verwenden“. Diese leben in den Agentenanweisungen des Projekts. Nenne einen Skill nur, wenn der Agent ihn laden muss und es nicht von alleine tun würde.
• Pfade: geschrieben, wie der Agent sie von seinem eigenen Arbeitsverzeichnis aus auflösen wird; relativ innerhalb des Repos und die Symlink-Form (nicht das aufgelöste Ziel) für alles, was durch einen Symlink erreicht wird.

Aufforderung – Generischer Modus

PHASE: <schreiben | validieren | testen | lesen>
TASK: <die genaue Anweisung – die zu machende Bearbeitung, das zu findende Muster, der auszuführende Befehl>

FILES:
- <genaue Pfade>

DEFINITION OF SUCCESS:
- <der Verifikationsbefehl und sein erwartetes Ergebnis>

DELIVERY:
- Füge die Verifikationsausgabe in deinen Bericht ein.

Adjudizieren

Berichte sind Behauptungen. Für jeden:

• Überprüfe, dass die Beweise die Schlussfolgerung stützen. „Tests bestanden“ ohne die Befehlsausgabe ist kein Beweis; weise erneut zu, um die Ausgabe zu erhalten.
• Beurteile die zurückgegebene Arbeit; leite sie nicht neu ab. Das erneute Lesen dessen, was der Agent gelesen hat, verbraucht den Kontext, den das Delegieren gespart hat.
• Zwei Berichte widersprechen sich → finde die falsifizierbare Behauptung und weise eine Prüfung dafür zu. Vertrauen ist kein Entscheidungskriterium.
• PARTIAL → weise den Rest erneut zu und nenne genau, was übrig ist.
• BLOCKED aufgrund einer fehlenden Eingabe → liefere sie und weise erneut zu. BLOCKED nach Versuchen → ändere den Ansatz oder eskaliere an den Benutzer; sende nicht dieselbe Aufforderung erneut.

Weise dieselbe Phase höchstens zweimal bei derselben Lücke erneut zu. Danach stoppe und melde dem Benutzer BLOCKED unter Nennung der Lücke.

Jede Anfrage, die Code geändert hat, erhält ein unabhängiges Review von einem anderen Reviewer als dem Schreiber.

Musterausweitung

Ein Benutzer, der auf eine Instanz eines Code-Geruchs, Bugs oder fehlenden Checks zeigt, benennt ein Muster. Sofern er nicht „nur dieses eine“ gesagt hat: Weise eine Prüfung der gesamten Datei oder des Moduls auf das Muster zu, berichte die gefundenen Instanzen und bestätige mit dem Benutzer, bevor du über die benannte Datei hinaus korrigierst.

Verweise

• references/sub-agent-contract.md – was zugewiesene Agenten befolgen.
• references/fix-cycle.md – der Reproduzieren-zuerst-Zyklus für Fehlerbehebungs-Dispatches.
• parallel-work – Aufteilung, Zusammenführung, Ersteller/Prüfer, Turniere, Schleifen mit Obergrenzen; verweist auch auf Claude Code Umgebungsmechaniken.
• Wenn orchestrator-discipline installiert ist: was der Orchestrator lesen und ausführen darf; durch Hooks erzwungen.
• Wenn process-siren installiert ist: Entscheidungspunkte als auswertbare Mermaid-Rauten schreiben.