<img src="banner.png" width="100%" alt="choose-your-orchestrator banner">

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

Baustein	Aufgabe im Vertrag	Nicht seine Aufgabe
orchestrator	Arbeitspakete, Scopes, Evidenz und Abnahme	Modellwahl oder Schwarmmuster erfinden
swarm-operations	Schwarmmuster, Kosten-Gate und optionale Matruschka-Staffelung	Einzelaufgaben künstlich parallelisieren
model-strategy	Fähigkeits- und modellbezogene Route anhand der Live-Verfügbarkeit	feste Modellversionen oder Berechtigungen vorgeben
clutch	optionaler externer Routingvorschlag	alleinige Autorität für Dispatch oder Scope
decision-avatar	optionales autorisiertes Präferenzsignal bei reversiblen Unsicherheiten	Nutzerfreigaben ersetzen oder Autorität erweitern
budgetierung	ausgehandelte Kontingente je Zeitfenster für teure Modelle/Reviewer/Advisor, Konto und Vorverfahren vor Eskalationen	Modelle fachlich auswählen (das tut model-strategy) oder Kontingente eigenmächtig festlegen

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 (bei mehrstündigen Läufen oder knappen/teuren Modellen über budgetierung aushandeln und als Konto führen),
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

Aufgabentyp	Empfehlung	Default-Zuschnitt
Audit / Sweep	orchestrator + swarm-operations; model-strategy bei unterschiedlichen Fähigkeitsklassen	unabhängige Bereiche, kleine parallel-chunks- oder specialist-Gruppe, zentraler Merge
Bauprogramm	orchestrator + model-strategy; Schwarm nur für wirklich unabhängige Stränge	Chef plant und nimmt ab, Worker bauen in disjunkten Bereichen
Einzelbau	Einzelfahrt; optional model-strategy oder clutch für die Route	kein Schwarm- oder Hierarchie-Overhead
Ticket-Betrieb	Ticket-System bleibt führend; orchestrator ergänzt Arbeitsverträge und Evidenz	vorhandenes Router-/Score-Regime nicht ersetzen, Ticket-Lifecycle respektieren

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; Budget/Konto: <budgetierung-Konto, Pfad>>
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.1.0 (2026-10-03)

• budgetierung als Baustein für ausgehandelte Modellkontingente/Konto ergänzt (Bausteine-Tabelle, Modell-/Budgetslots im Vertragsdialog, Vertragsformat-Zeile Worker-Slots).

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.