Specialist Team Orchestrator
Koordiniere komplexe Arbeit als kleines, spezialisiertes Team, während ein Lead für Integration und Verifikation verantwortlich bleibt.
Wann verwenden
Aktiviere diese Fähigkeit, wenn eine Anfrage mindestens zwei sinnvolle Arbeitsstränge enthält, die unabhängig voneinander bearbeitet werden können, wie z. B.:
- Produkt-Recherche und technische Discovery;
- UX-Ausrichtung und Implementierungsplanung;
- Frontend- und Backend-Arbeit mit einer stabilen Schnittstelle;
- Implementierung und unabhängige QA;
- Migrationsanalyse über getrennte Dienste hinweg.
Bleibe beim Einzel-Agenten für triviale Änderungen, eng sequenzielle Arbeit oder Aufgaben, bei denen die Koordination mehr kosten würde, als sie einspart.
Delegationsschwelle
Vor der Implementierung:
- Zerlege das angeforderte Ergebnis in konkrete Arbeitsstränge.
- Markiere Abhängigkeiten zwischen ihnen.
- Zähle die Arbeitsstränge, die unabhängig voneinander fortgesetzt werden können.
- Wenn mindestens zwei unabhängige Arbeitsstränge existieren und Worker verfügbar sind, delegiere.
- Falls Delegation nicht verfügbar ist, führe sequenziell aus, während dieselben Rollengrenzen eingehalten werden.
- Behalte einen Lead bei, der für Umfang, Integration, Verifikation und endgültige Auslieferung verantwortlich ist.
Das vom Benutzer ausgewählte Modell ist standardmäßig der Lead. Es ist nicht automatisch der einzige Worker.
Rollen nach Aufgaben wählen
Erstelle nur die Rollen, die die Aufgabe benötigt:
- Produkt/Recherche — Anforderungen, Referenzen, Domänenrecherche, Inhalte und Risiken.
- Design — Informationsarchitektur, UX-Ausrichtung, Designsystem, responsives Verhalten und visuelle Akzeptanzkriterien.
- Build — Komponenten, Interaktionen, Implementierung und Performance.
- Systeme — Datenmodell, Authentifizierung, APIs, Integrationen und Bereitstellungsbeschränkungen.
- QA/Audit — unabhängige Überprüfung, Barrierefreiheit, Regression, Randfälle und End-to-End-Flussverifikation.
Weise den Modellen Rollen zu, sobald die Rollen definiert sind:
- verwende starkes visuelles Urteilsvermögen für Design;
- verwende starke Repository- und Codierungsfähigkeiten für Build und Systeme;
- verwende Langzeit-Kontext-Recherchefähigkeiten für Produkt/Recherche;
- bevorzuge ein anderes Modell oder einen frischen Kontext für QA;
- reserviere kleine oder lokale Modelle für begrenzte, risikoarme Extraktion, Klassifikation, Zusammenfassung oder Entwürfe.
Leite keine produktionskritischen Entscheidungen, autonome Aktionen mit hohen Auswirkungen oder die endgültige QA an ein unerprobtes, schwaches Modell weiter.
Verträge vor paralleler Arbeit definieren
Jeder delegierte Arbeitsstrang muss angeben:
- Ziel;
- erlaubte Dateien oder Umfang;
- erforderliche Eingaben;
- genaues Ausgabe-Artefakt;
- Akzeptanzkriterien;
- Abhängigkeiten und Blockierer;
- Verbot von nicht zusammenhängenden Änderungen.
Bevorzuge Artefakte, die andere Rollen direkt konsumieren können:
- Anforderungsdokument;
- Design-Tokens oder DESIGN.md;
- Komponenten- oder API-Vertrag;
- Schema- oder Migrationsplan;
- Test-Checkliste mit Nachweisen.
Bitte nicht mehrere Worker darum, dieselbe vollständige Funktion zu bauen, es sei denn, die Aufgabe fordert explizit konkurrierende Prototypen an.
In Phasen koordinieren
- Lead-Framing — inspiziere das Projekt, formuliere das Ergebnis neu, identifiziere Einschränkungen und definiere Arbeitsstränge.
- Parallele Discovery — führe unabhängige Recherche, Design-Erkundung, Repository-Inspektion oder Risikoanalyse gleichzeitig durch.
- Vertrags-Checkpoint — gleiche Konflikte aus und friere gemeinsame Schnittstellen ein, bevor abhängige Implementierungen beginnen.
- Implementierung — gib Workern nach Möglichkeit sich nicht überlappende Dateieigentümerschaft.
- Unabhängige QA — verwende einen frischen Worker, wenn verfügbar; der Builder darf nicht der alleinige finale Reviewer sein.
- Lead-Integration — löse Konflikte und führe End-to-End-Verifikation gegen die Akzeptanzkriterien durch.
Die Meldung eines Workers über den Abschluss ist kein Beweis dafür, dass das integrierte Ergebnis funktioniert. Der Lead muss das zusammengesetzte Ergebnis verifizieren.
Team skalieren
- Kleine isolierte Änderung: nur Lead, oder Lead plus ein Spezialist.
- Mittlere multi-Domänen-Aufgabe: Lead plus zwei Spezialisten.
- Großer Build oder Neugestaltung: Lead plus drei Spezialisten, wobei nur hinzugefügt wird, wenn Kapazität vorhanden ist und die Arbeit unabhängig bleibt.
Erzeuge niemals Agenten nur, um eine Zielzahl zu erreichen.
Sicherheit
Delegation erweitert die Autorisierung nicht. Alle Worker müssen bewahren:
- benutzereigene Änderungen;
- Repository- und Arbeitsbereichsgrenzen;
- Genehmigungsschwellen;
- Produktionssicherheitsregeln;
- Geheimnisse und private Daten;
- Einschränkungen der externen Kommunikation.
Der Lead bleibt verantwortlich für jede externe Aktion und jede destruktive Änderung.
Beispiele
Web-Feature
- Produkt/Recherche: kläre den Benutzerfluss und die Randfälle.
- Design: definiere responsive Zustände und Interaktions-Akzeptanzkriterien.
- Build: implementiere gegen den eingefrorenen Vertrag.
- QA: teste Tastatur, Mobilgeräte, Fehler und den gesamten Fluss.
Datenmigration
- Recherche: inventarisiere aktuelle Daten und Einschränkungen.
- Systeme: entwerfe Mapping, Rollback und Validierungsplan.
- Build: implementiere sich nicht überlappenden Migrationscode.
- QA: vergleiche Anzahlen, Stichproben, Fehler und Rollback-Verhalten.
Forschungsbericht
- Forscher: untersuche unabhängige Evidenzströme.
- Kritiker: hinterfrage unbegründete Schlussfolgerungen.
- Lead: gleiche Evidenz ab, zitiere Quellen und schreibe die endgültige Entscheidung.
Abschlussbericht
Berichte:
- verwendete Rollen;
- von jeder Rolle erstellte Artefakte;
- vom Lead durchgeführte Verifikation;
- Einschränkungen oder verbleibende Arbeiten;
- für jede Rolle verwendete Modelle.
Falls keine Delegation stattfand, gib an, warum die Aufgabe die Delegationsschwelle nicht passiert hat.