Choose Your Orchestrator

Choose Your Orchestrator

Zweck

Kläre vor komplexer Multi-Agent-Arbeit die Randbedingungen, empfehle die kleinste wirksame Kombination vorhandener Skills und gib einen verbindlichen Session-Orchestrierungsvertrag aus. Lade die ausgewählten Skills über den Skill-Mechanismus der aktuellen Runtime und folge ihren Live-Anleitungen. Kopiere ihre Verfahren nicht in diesen Skill.

Delegation erweitert niemals die Autorität. Externe oder irreversible Aktionen wie Veröffentlichen, Senden, Löschen, Bezahlen oder produktive Änderungen bleiben beim Nutzer gegatet, sofern der aktuelle Auftrag sie nicht ausdrücklich autorisiert.

Bausteine

Nutze clutch route "<kurze Aufgabenbeschreibung>" --json nur, wenn clutch tatsächlich verfügbar ist. Behandle die JSON-Antwort als Vorschlag und gleiche sie gegen verfügbare Runtime-Slots, Budget, Projektregeln und Nutzergrenzen ab. Ist clutch nicht verfügbar oder seine Ausgabe unlesbar, nutze model-strategy und die Live-Fähigkeiten der Runtime. Hardcode keine aktuellen Modellnamen oder -versionen in den Vertrag.

Empfehlungsdialog

1. Aufgabe einordnen

Ermittle Ziel, Aufgabentyp, Erfolgskriterien, negative Scopes, aktuelle Berechtigungen, vorhandene Locks und unabhängige Arbeitspakete. Wähle zunächst den kleinsten passenden Routenvorschlag aus der Tabelle unten.

2. Vertrag vorschlagen

Zeige einen kompakten Entwurf mit:

1. Bausteinen und Rollen,
2. Modell-/Budgetslots,
3. maximaler Parallelität und Spawn-Tiefe,
4. Schreibgrenzen und Locks,
5. Abnahme und Evidenz,
6. Eskalation und Nutzerfragen,
7. Autoritätsgrenze.

Empfehle konkrete Werte und nenne in einem Satz den wichtigsten Trade-off. Frage nur nach Entscheidungen, die das Ergebnis materiell ändern. Bündele offene Fragen in höchstens drei klar getrennte Gruppen; stelle die empfohlene Option jeweils zuerst. Sind alle Dimensionen bereits ausdrücklich festgelegt, frage nicht erneut.

3. Bestätigen oder reduzieren

Beginne keinen Multi-Agent-Dispatch, solange eine materielle Budget-, Schreib- oder Autoritätsfrage offen ist. Ist nur der Nutzen von Parallelität unklar, reduziere auf Einzelfahrt. Ein explizit autorisierter Auftrag darf mit den sicheren Defaults starten, wenn keine materielle Nutzerentscheidung fehlt.

4. Vertrag ausgeben

Gib den bestätigten Vertrag im Chat aus. Ist ein usmc-Befehl verfügbar, prüfe zuerst dessen Hilfe und schreibe zusätzlich über einen dort dokumentierten Note-/Write-Befehl eine privacy-neutrale Session-Notiz. Erfinde keinen Subcommand und speichere keine Rohprompts, Secrets oder privaten Inhalte. Ohne verfügbaren USMC-Schreibweg ist der Chatvertrag autoritativ.

Routingtabelle

Sichere Defaults

Verwende diese Werte, sofern Nutzer, Runtime oder Projektregeln nichts Strengeres vorgeben:

• maximal zwei aktive Worker; starte zunächst einen und belege den Nutzen des zweiten,
• Matruschka aus, maximale Spawn-Tiefe 0,
• keine Worker-eigenen Subagenten ohne explizite Freigabe,
• ein Schreiber pro Repository oder klar abgegrenztem Bereich,
• disjunkte Datei-Claims und projektübliche Locks vor jedem Write,
• Chef/Orchestrator prüft Artefakte, Diffs und Tests selbst,
• Fertigmeldungen gelten erst nach Evidenzabnahme,
• irreversible oder externe Aktionen bleiben nutzergegatet,
• Unsicherheit wird gebündelt statt als viele Einzelunterbrechungen gemeldet.

Aktiviere Matruschka nur, wenn der Nutzer sie ausdrücklich bestätigt und der Vertrag pro Ebene Modell-/Fähigkeitsklasse, aktive Slotgrenze, erlaubte Unteraufgaben und maximale Tiefe nennt. Zähle aktive, nicht lediglich vorhandene Agenten. Auch dann bleibt genau ein Schreiber pro Bereich bestehen.

Vertragsformat

SESSION-ORCHESTRIERUNGSVERTRAG
Ziel und Typ: <Ergebnis; Audit/Bauprogramm/Einzelbau/Ticket-Betrieb>
Bausteine: <geladene Skills und optionale Router>
Chef: <Planung, Denkarbeit, Integration, Evidenzabnahme>
Worker-Slots: <Rolle/Fähigkeitsklasse je Slot; Budgetgrenze>
Parallelität: <maximal aktiv>; Spawn-Tiefe: <0..N>; Matruschka: <aus/an>
Schreibgrenzen: <ein Schreiber je Bereich; Claims; Locks; negative Scopes>
Abnahme: <Artefakte, Tests, Diffs, Quellen; wer prüft>
Eskalation: <Stopps; höchstens drei gebündelte Nutzerfragen>
Autorität: <zulässige Aktionen; extern/irreversibel user-gegatet>
Persistenz: <Chat autoritativ; USMC-Notiz ja/nein und privacy-neutral>

Beispiel

Auftrag: Drei unabhängige Komponenten prüfen und einen Fix integrieren.
Empfehlung: orchestrator + swarm-operations; zwei aktive Read-only-Reviewer,
danach genau ein Integrationsschreiber. Matruschka aus, Tiefe 0. Der Chef prüft
Fundstellen, Diff und Gesamttests. Push oder Veröffentlichung nur im ausdrücklich
autorisierten Scope.
Offene Frage: Ist die zweite parallele Review-Spur den zusätzlichen Verbrauch wert?
Empfehlung: ja, weil die Komponenten unabhängig sind.

Stop-Bedingungen

Stoppe oder reduziere die Orchestrierung, wenn Scopes überlappen, Locks unklar sind, die Runtime den empfohlenen Slot nicht anbietet, das Budget nicht bestätigt ist oder die Abnahme nicht unabhängig belegt werden kann. Frage den Nutzer statt eine neue Produkt-, Datenschutz- oder Autoritätsentscheidung zu erraten.

Changelog

1.0.0 (2026-08-20)

• Empfehlungsdialog, Routentabelle und kompakter Session-Vertrag eingeführt.
• Sichere Defaults für Parallelität, Matruschka, Schreibgrenzen, Evidenz und externe Aktionen festgelegt.
• Optionale Integration von clutch und einem autorisierten Präferenzmodell ohne feste Modellbindung oder Autoritätserweiterung beschrieben.