mission-control-v2/deploy/skills/orchestrator/SKILL.md

name, description, version, author, platforms, metadata

name	description	version	author	platforms	metadata
orchestrator	Orchestrieren wie ein Manager: einen groesseren Auftrag in Teil-Tasks zerlegen, jeden SERIELL an das passende Worker-Modell delegieren (worker.sh, Ein-Schuss via llama-swap), die Ergebnisse einsammeln + zusammensetzen, per Fremd-Kritiker gaten und als Telegram-Vorschlag zurueckgeben. NIE selbst mergen/deployen — der Commander ist das Gate.	1.0.0	MC2 (Autonomie — Orchestrator)	linux	hermes tags orchestrator delegation werkstatt mc2 fliessband

Orchestrator — du managst, du fuehrst nicht alles selbst aus

Nutze diesen Skill, wenn ein Auftrag zu gross fuer EINEN Rutsch ist, sich aber in wenige klar abgegrenzte Teil-Tasks zerlegen laesst (ueberwiegend Code-Bau). Du bist der Manager: du zerlegst, verteilst die Teile SERIELL an Worker-Modelle (die arbeiten), fuegst die Ergebnisse zusammen und lieferst am Ende einen Vorschlag — der Commander entscheidet.

Das ist die Verallgemeinerung der Werkstatt (wartung): dort delegierst du EINEN Schritt (Code-Review) an ein Fremdmodell. Hier delegierst du MEHRERE Bau-Schritte an Worker und behaeltst die Integration + das Gate.

Warum seriell (und warum das ok ist)

Mehrere grosse Modelle GLEICHZEITIG passen nicht in den Speicher. llama-swap ist seriell — ein Modell laden → arbeiten → tauschen → naechstes. Orchestrierung ist ein Fliessband, kein Schwarm. Langsamer (Swap-Latenz + einer nach dem anderen: Minuten), aber bei Hintergrund-/Telegram-Jobs egal.

Scope-Check zuerst (klein anfangen)

Passt: ein Auftrag, der in 2–4 abgegrenzte Teil-Tasks zerfaellt, jeder ein 1–2-Datei-Bau-Schritt (neues kleines Modul + Test, kleine neue Funktion + Verdrahtung, zusammenhaengender Refactor in wenigen Dateien). Zu gross (viele Module, echte Architektur-Entscheidungen, breite API-Aenderung): dann NUR einen Plan als Text im Telegram-Vorschlag liefern, KEINEN Code — der Commander schneidet dann kleiner.

Leitplanken (nicht verhandelbar)

• Du delegierst, du baust NICHT selbst. Jedes Bau-Artefakt MUSS aus einem worker.sh-Aufruf stammen. Schreibst du den Code selbst (auch wenn der Teil-Task „einfach genug" wirkt), statt ihn vom Worker zu holen, ist der Lauf GESCHEITERT — sag das ehrlich, statt Eigenbau als Orchestrierung auszugeben. Belege jeden Teil-Task im Vorschlag mit dem worker.sh-Aufruf UND den ersten Zeilen seiner Roh-Ausgabe. (Warum so streng: das Manager-Modell kann kleine Tasks selbst — genau dann faellt Delegation aus Bequemlichkeit weg; das ist der haeufigste Orchestrierungs-Fehler.)
• Die Helfer EXISTIEREN. ~/.hermes/scripts/worker.sh und ~/.hermes/scripts/fremdblick.sh sind installiert, aber NICHT auf deinem PATH → immer mit vollem Pfad aufrufen (nie bloss worker.sh). Glaubst du, sie fehlen, IRRST du dich: erst ls -la ~/.hermes/scripts/worker.sh ausfuehren und den Pfad lesen, dann nutzen. „Skript fehlt" ist KEIN gueltiger Grund, den Schritt selbst zu machen.
• Propose-only. Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der Commander. NIEMALS auf main committen, NIEMALS mergen, NIEMALS deployen oder Dienste neu starten.
• Nur im Worktree arbeiten. Die Live-Instanz ~/mission-control-v2 bleibt unberuehrt.
• Warm-Set-Schutz (harte Speicher-Falle). Worker nur ueber worker.sh und nur Modelle, die KLEIN neben dem Warm-Set laden — v1 = Qwen3-Coder-Next (Default in worker.sh). NIEMALS heavy/gpt-oss-120b als Worker (60 GB → stirbt neben dem VL-30B-Warm-Set, gefaehrdet Lucys ~1-s-Sprech-Latenz). Planung/Zerlegung/Integration machst DU (Hermes, schon warm) selbst.
• Fremd-Kritiker ist Pflicht-Gate. Der zusammengesetzte Diff MUSS von fremdblick.sh (anderes Modell) gegengelesen werden, bevor du vorschlaegst. Ein Manager, der Worker-Output blind zusammenklebt, produziert leisen Muell.
• Security-Config ist TABU: keine Tokens, approvals, ufw, sudoers, ssh-Keys anfassen.
• Gate rot oder Kritiker dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschoenigen.

Ablauf

1. Zerlegen (der Manager denkt)

Brich den Auftrag in eine geordnete, nummerierte Liste von Teil-Tasks. Fuer jeden Teil-Task entscheide: (a) was ist das Artefakt (welche Datei, was tut sie), (b) welches Worker-Modell + welche Rolle (build/refactor), (c) welchen Kontext braucht der Worker (siehe Abschnitt „Kontext-Uebergabe"). Halte die Liste kurz. Reihe die Teile so, dass spaetere auf fertige fruehere aufbauen koennen.

2. Worktree anlegen (Slug = kurzer Kebab-Case-Name des Auftrags)

cd ~/mission-control-v2 && git fetch -q origin \
  && git worktree add /tmp/orch-<slug> -b orchestrator/<slug> origin/main
mkdir -p /tmp/orch-<slug>-work   # Ablage fuer rohe Worker-Ausgaben

3. Routen — je Teil-Task ein Worker-Ein-Schuss (seriell)

Fuer jeden Bau-Teil-Task:

1. Baue die Eingabe: genau der noetige Kontext + der praezise Auftrag (siehe unten). Bereits fertige Artefakte aus frueheren Schritten als Kontext mitgeben, wenn der Worker sie braucht.
2. Ruf den Worker auf und fang die Ausgabe roh ab:

   printf '%s' "$eingabe" | WORKER_ROLE=build ~/.hermes/scripts/worker.sh > /tmp/orch-<slug>-work/<n>.out
   

   (Default-Modell ist Qwen3-Coder-Next. Fuer einen bewusst anderen Worker WORKER_MODEL=<echte-id>.)
3. Pruefe die Ausgabe, bevor du sie verwendest: Beginnt sie mit FEHLT:, hast du zu wenig Kontext gegeben → nachliefern und erneut rufen. Hat der Worker versehentlich einen ```-Codezaun oder Prosa drumherum gesetzt, entferne ihn. Dann schreibe das saubere Artefakt mit deinen Datei-Tools an seinen Platz im Worktree (/tmp/orch-<slug>/...). Der Worker hat KEINE Datei-Haende — das Schreiben machst DU.

4. Integrieren + Self-Gate (nach jedem Schritt bzw. am Ende)

Die Worker liefern Bausteine — DU sorgst dafuer, dass sie zusammenpassen (Imports, Verdrahtung, Namen). Dann das Selbst-Gate, was zutrifft:

• Python geaendert → python3 -m py_compile <dateien> (und wenn ein Test dabei ist und ohne schwere Deps laeuft: den Test im Worktree ausfuehren).
• Shell geaendert → bash -n <dateien>
• Frontend (frontend/src/...) → auf der Box gibt es KEIN Node. Im Vorschlag ausweisen: „Gate eingeschraenkt: tsc/Build laeuft erst beim Merge auf dem PC."
• Live-Checkout unberuehrt (PFLICHT, zwei Beweise):
  • git -C ~/mission-control-v2 status --porcelain -uno muss LEER sein (Beweis, dass du wirklich nur im Worktree gearbeitet hast — ein gruener Health-curl allein reicht NICHT, weil der laufende Dienst den alten Code im RAM haelt und eine schmutzige Datei auf der Platte nicht bemerkt).
  • curl -sf http://127.0.0.1:9001/api/health muss gruen bleiben.
  • Ist git status NICHT leer: die fremden Aenderungen im Live-Checkout mit git -C ~/mission-control-v2 checkout -- <datei> zuruecknehmen (deine Arbeit liegt sicher im Worktree) und im Vorschlag ehrlich erwaehnen.

5. Zwei-Kritiker-Gate ueber den GESAMTEN Diff (Pflicht)

Zwei Zweitgutachter mit je anderer Staerke lesen den zusammengesetzten Diff gegen — aus demselben Grund wie in der Werkstatt („wer seine eigenen Hausaufgaben benotet, stimmt sich selbst zu"). NICHT delegate_task (laeuft ueber heavy → 64K-Floor + Warm-Set-Kollision).

Zuerst ALLES stagen — sonst fehlen NEUE Dateien im Diff (haeufigste Falle: git diff ignoriert untracked Dateien, die Kritiker bekaemen einen LEEREN Diff und wuerden alles blind ablehnen):

git -C /tmp/orch-<slug> add -A

Dann die Eingabe EINMAL bauen (mit --cached, damit die neuen Dateien drin sind):

EINGABE="AUFTRAG (im Wortlaut):
<der urspruengliche Auftrag>

ZERLEGUNG (deine Teil-Tasks, je 1 Zeile):
<1..n>

GIT-DIFF des Worktrees:
$(git -C /tmp/orch-<slug> diff --cached origin/main)"

Ist dieser Diff LEER, hast du nicht gestaged (oder nichts gebaut) → NICHT weiter, erst beheben. Kritik A — Kompetenz (Qwen3-Coder-Next, starker Coder, vom Bauen noch geladen → KEIN Swap):

printf '%s' "$EINGABE" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh

Kritik B — Fremd-Blick (GLM-4.6V-Flash, andere Modellfamilie, andere blinde Flecken):

printf '%s' "$EINGABE" | FREMDBLICK_MODE=code FREMDBLICK_MODEL=GLM-4.6V-Flash FREMDBLICK_MAXTOK=3000 ~/.hermes/scripts/fremdblick.sh

Reihenfolge bewusst: erst A (Coder-Next ist noch warm), dann B (ein Swap zu GLM). Beide beginnen mit URTEIL: <ABGELEHNT | FREIGABE-MIT-VORBEHALT | FREIGABE>. Warte auf beide.

Gate-Regel (streng): Sagt AUCH NUR EINER ABGELEHNT → nachbessern (max. 2 Runden: den betroffenen Teil-Task neu an den Worker, integrieren, BEIDE Kritiker erneut). FREIGABE-MIT-VORBEHALT → die Vorbehalte adressieren oder im Vorschlag ehrlich ausweisen (NICHT wegdiskutieren). Nur wenn BEIDE tragen → Vorschlag. Beide Urteile KONKRET in den Vorschlag (welcher Kritiker was sagte). Faellt ein Kritiker technisch aus (FEHLGESCHLAGEN/ABGESCHNITTEN) → einmal wiederholen, sonst „⚠ Kritik X fiel aus" vermerken (NICHT als Freigabe zaehlen).

Der schwere Chef-Gutachter (gpt-oss) laeuft NICHT in diesem heissen Pfad — er muesste 60 GB kalt laden und Lucys Warm-Set stoeren. Er prueft separat NACHTS im Leerlauf ueber die offenen Orchestrator-Vorschlaege (eigener Cron), wo Ladezeit + Warm-Set-Umbau verkraftbar sind.

• ABGELEHNT / berechtigte FREIGABE-MIT-VORBEHALT → nachbessern (max. 2 Runden: den betroffenen Teil-Task neu an den Worker geben, integrieren, erneut gaten). Bleibt es kritisch: Kritik in den Vorschlag schreiben, Branch bleibt liegen, Entscheidung dem Commander.
• FREMDBLICK FEHLGESCHLAGEN/ABGESCHNITTEN → einmal wiederholen; sonst im Vorschlag ehrlich „⚠ Fremd-Review fiel aus — UNGEPRUEFT" vermerken (NICHT als Freigabe behandeln).

6. Telegram-Vorschlag (in LUCYS Stimme)

bash ~/mission-control-v2/deploy/notify.sh -s "[Orchestrator]" "<text>" — an den Commander, nicht als anonymer Job: erst 1–2 Saetze, was gebaut wurde und was er jetzt entscheiden soll; dann knapp:

• die Zerlegung (welcher Teil-Task an welches Worker-Modell ging),
• geaenderte/neue Dateien · Kern des Diffs,
• Self-Gate-Ergebnis · Kritiker-Urteil KONKRET ausgeschrieben (nicht nur „ok"),
• Branch-Name · Frage „merge oder verwerfen?"

7. Nichts loeschen

Worktree + Branch + rohe Worker-Ausgaben bleiben liegen, bis der Commander entschieden hat.

Kontext-Uebergabe — hier geht Orchestrierung am ehesten schief

Jeder Worker startet frisch und zustandslos: kein Gedaechtnis der bisherigen Schritte, kein Zugriff aufs Repo. Er sieht NUR, was du ihm auf stdin gibst. Deshalb:

• Gib ihm den relevanten Ausschnitt mit — die betroffene Datei (oder den betroffenen Block), benachbarte Muster zum Nachahmen, die genaue Signatur/den Namen, den er treffen muss, und bei Folge-Schritten die bereits fertigen Artefakte, auf die er aufbaut.
• Sei praezise beim Zielartefakt: „Gib den VOLLSTAENDIGEN Inhalt der neuen Datei X aus" bzw. „Gib einen unified Diff gegen den folgenden Stand von Y aus".
• Zu wenig Kontext → der Worker raet oder meldet FEHLT:. Zu viel unnoetiger Kontext → er verliert den Fokus. Ziel: das kleinste, das den Teil-Task eindeutig macht.

Nach dem Commander-Entscheid (kommt als neuer Auftrag)

• „verwerfen" → git worktree remove /tmp/orch-<slug> --force && git branch -D orchestrator/<slug> (+ rm -rf /tmp/orch-<slug>-work; Remote-Branch loeschen, falls gepusht).
• „merge" → das Mergen nach main + Deploy macht der PC/Claude (Frontend-Builds gibt es nur dort). Du pushst NIE nach main.