Parallel-Task-Orchestrator

Parallel-Task-Orchestrator (Paralleler Aufgaben-Orchestrator)

Wenden Sie diese Fertigkeit auf jede Aufgabe an, einschließlich Fragen, Schreiben, Überprüfung, Planung und Implementierung. Verwenden Sie den geladenen Einstiegspunkt innerhalb einer Sitzung wieder; lesen Sie nicht bei jeder Nachricht unveränderte Anleitungen erneut oder entdecken Sie Ressourcen neu. Der Arbeitsablauf ist „Verstehen, Bewerten, Planen, Leiten, Ausführen, Prüfen, Integrieren, Verifizieren, Berichten“, wobei Zerlegung und Parallelisierung nur dann erfolgen, wenn sie sinnvoll sind. Ein Hauptorchestrator besitzt das Arbeitsprotokoll, die Integration und die endgültige Antwort.

Bleiben Sie Ziel-agnostisch. Entdecken Sie das aktive Ziel, die Tools und Pfadkonventionen zur Laufzeit. Halten Sie Ressourcenlinks in dieser Fertigkeit relativ; lösen Sie operative Aufgabenpfade gegen das aktive Ziel auf, niemals gegen den Installationsort der Fertigkeit. Erstellen Sie ziel-lokale Orchestrierungsdaten nur, wenn die ausgewählte Persistenzstufe dies erfordert.

Die gleiche Richtlinie gilt in Codex, Claude Code, Cursor, Antigravity und anderen kompatiblen Agenten, unabhängig vom verwendeten LLM. Verwenden Sie die dokumentierten Steuerelemente des aktiven Hosts, nicht die Argumentnamen eines anderen Anbieters. Für die Installation auf mehreren Hosts oder Geräten verwenden Sie references/host-integration.md; laden Sie keine Installationsdetails während gewöhnlicher Aufgaben.

Leichte Bewertung bei jeder Aufgabe

Ermitteln Sie stillschweigend die Absicht, die angeforderte Stufe, den geschützten Umfang und eine ausreichende Verifizierung. Klassifizieren Sie die Aufgabe und jede Unteraufgabe separat als TRIVIAL, NIEDRIG, MITTEL, HOCH oder KRITISCH, unter Verwendung von Umfang, betroffenen Komponenten, Argumentationsschwierigkeit, Abhängigkeiten, Mehrdeutigkeit, architektonischer Auswirkung, Sicherheitsrisiko, Umkehrbarkeit, Forschungs- und Verifizierungsaufwand. Die Repository-Größe ist nur dann von Belang, wenn die Aufgabe diesen Kontext benötigt.

Für eine offensichtliche TRIVIAL oder NIEDRIG Anfrage verwenden Sie den aktuellen Agenten und deterministische Tools nach Bedarf und antworten Sie dann. Starten Sie keine Agenten, scannen Sie keine installierten CLIs, erstellen Sie keine Verwaltungsdateien, generieren Sie keinen formalen Graphen oder erzählen Sie die Bewertung nicht. Eine klare Anfrage benötigt keine Verfeinerungsschleife. Für substanzielle Arbeit zeichnen Sie einen kompakten Komplexitätsgrund und die Ressourcenentscheidung im bestehenden Plan oder Logbuch auf. Hohe Komplexität des übergeordneten Elements impliziert nicht hohen Aufwand für jedes Kind.

Wenden Sie vor jedem Dispatch eines Sub-Agenten, einschließlich eines solchen, der das übergeordnete Element erben würde, references/resource-routing.md an. Verwenden Sie diese Referenz nach dem Laden wieder. Wenn die Laufzeit Modell- und Aufwandssteuerungen bereitstellt, wählen Sie beide explizit für die einzelne Unteraufgabe aus und übergeben Sie sie; das Weglassen ist keine Optimierung. Bevorzugen Sie fokussierten Kontext und eine leichte, ausreichende Route. Ein stärkeres Modell oder hoher Aufwand benötigt einen aufgabenspezifischen Grund. Wenn Steuerungen nicht verfügbar sind, dokumentieren Sie die Einschränkung, anstatt eine Auswahl zu behaupten. Optimieren Sie zuerst die erforderliche Qualität, dann Latenz und gemessenen oder beobachtbaren Ressourcenverbrauch; erfinden Sie niemals Einsparungen.

Verfeinern Sie die Anfrage, bevor Sie handeln

Behandeln Sie die Nachricht des Benutzers als rohe Absicht. Verwenden Sie für komplexe oder mehrdeutige Anfragen references/request-refinement.md, um das Protokoll intern zu verfeinern. Überprüfen Sie, um fehlende Details aufzulösen, und hören Sie mit der Verfeinerung auf, wenn die Anweisung ausreicht, um zu handeln und zu verifizieren. Führen Sie nur das endgültige Protokoll und die wesentlichen Annahmen weiter.

Führen Sie die Schleife standardmäßig stillschweigend aus; der Inspektionsschritt unten ist die Art und Weise, wie die meisten Vorschläge und Fragen beantwortet werden. Gehen Sie nur dann zum Benutzer, wenn er darum bittet, den Prompt zu sehen oder zu erstellen, oder wenn eine Frage die Inspektion und zwei Lesungen durchläuft und das Ergebnis wesentlich ändern würde, erforderliche Informationen nicht überprüft werden können, das Fortfahren ein erhebliches Risiko schafft oder eine irreversible Entscheidung seine Wahl erfordert. Verfeinerung klärt die Absicht. Sie ändert niemals das Ziel, erweitert den Umfang oder eskaliert die angeforderte Stufe, und eine Anfrage nach einem Prompt wird als Prompt geliefert, nicht ausgeführt.

Wählen Sie direkte oder delegierte Ausführung

Nach minimaler Inspektion delegieren Sie, wenn mindestens zwei nützliche Arbeitsströme abhängigkeitsbereit sind, ihre Schreibmengen disjunkt sind (schreibgeschützt none ist erlaubt) und der erwartete Nutzen den Dispatch- und Integrationsaufwand übersteigt. Explizite unabhängige Überprüfung oder spezialisierte Delegation kann einen begrenzten Arbeiter rechtfertigen. Bestätigen Sie, dass Delegation verfügbar und autorisiert ist. Andernfalls führen Sie direkt aus. Direkte Ausführung ist eine erfolgreiche Nutzung dieser Fertigkeit, kein abgelehnter Aufruf; es ist keine routinemäßige Erklärung erforderlich. Zustandsbehaftete direkte Arbeit kann dennoch einen Checkpoint benötigen, wenn Unterbrechung oder externe Effekte die Wiederherstellung wesentlich machen.

Bewahren Sie die Anfrage und die Stufe

Der abgeschlossene Überarbeitete Prompt ist das Arbeitsprotokoll. Es trägt das Ziel, den Umfang, Einschränkungen, geschütztes Verhalten, erwartetes Ergebnis, Nachweisauflagen, Akzeptanzkriterien und alle genannten Annahmen, und jeder spätere Schritt zerlegt, weist zu und verifiziert gegen dieses Protokoll, nicht gegen die ursprüngliche Nachricht. Bewahren Sie alle Grenzen für reine Überprüfung, reine Planung, Genehmigung, Implementierung oder Bereitstellung. Delegation erweitert keine Autorisierung.

Verwenden Sie parallele Agenten nicht nur, weil sie verfügbar sind. Delegation ändert niemals die angeforderte Stufe oder Berechtigungsgrenze des Benutzers.

Überprüfen Sie vor der Zerlegung

Der Hauptorchestrator überprüft zuerst die anwendbaren Repository-Anweisungen, die aktuelle Implementierung, den Arbeitsbaum-Zustand, relevante Tests und bereitgestellte Beweise. Lesen Sie genug, um architektonische Grenzen und gemeinsame Dateien zu identifizieren, bevor Sie Bearbeitungen zuweisen. Bitten Sie Sub-Agenten nicht, unabhängige architektonische Entscheidungen aus einem nicht überprüften Repository zu treffen.

Nach der anfänglichen Inspektion kann eine begrenzte schreibgeschützte Entdeckung parallel laufen, wenn verschiedene Bereiche unabhängig untersucht werden können. Geben Sie jedem Entdeckungs-Agenten einen expliziten Pfad oder eine Frage und fordern Sie Beweise an, keine breiten Repository-Zusammenfassungen.

Erstellen Sie den Aufgabengraphen

Erstellen Sie einen abhängigkeitsbewussten Graphen unter Verwendung der Felder in references/contracts.md. Lesen Sie diese Referenz beim Erstellen von Aufgabenpaketen, Akzeptieren von Ergebnissen, Auflösen von Konflikten, Verifizieren der Integration oder Vorbereiten des Abschlussberichts. Klassifizieren Sie jeden Knoten als:

• Parallel: keine unerfüllte Abhängigkeit und keine überlappende Schreibzuständigkeit.
• Sequentiell: hängt von einem anderen Ergebnis ab, ändert einen gemeinsamen Vertrag oder erfordert zuerst eine Integrationsentscheidung.
• Haupt-eigen: gemeinsame Dateien, Architektur, querschnittliche Konfiguration, riskante Migrationen, endgültige Integration oder jede Arbeit, die nicht sicher delegiert werden kann.

Frieren Sie Schnittstellen und Akzeptanzkriterien vor der parallelen Implementierung ein. Verwenden Sie absolute Pfade für jede Datei und jeden Anweisungsumfang. Wenn zwei Aufgaben dieselbe Datei benötigen oder widersprüchliche Architekturentscheidungen treffen könnten, weisen Sie einen Eigentümer zu oder serialisieren Sie sie. Exklusives Eigentum wird durch Zuweisung und Diff-Prüfung durchgesetzt, nicht durch einen Dateisystemsperre.

Skalieren Sie die Parallelität auf die nützliche unabhängige Arbeit und die verfügbare Sub-Agenten-Kapazität. Lassen Sie Kapazität für Koordination, wenn die Plattform den Hauptorchestrator auf das Limit anrechnet. Verwenden Sie Wellen, wenn Abhängigkeiten oder Kapazität einen einzelnen Start verhindern.

Lesen Sie references/state-and-resume.md vor Delegation, persistenter direkter Arbeit oder einer fortgesetzten Ausführung. Es definiert Persistenzstufen, Checkpoints, Sperren, Wiederherstellung nach Unterbrechung und Beweis-Hygiene. Behalten Sie einfache direkte Aufgaben nur im Gespräch.

Weisen Sie begrenzte Arbeit zu

Verwenden Sie den Standard-Zuweisungsvertrag in references/contracts.md. Jede Zuweisung muss angeben:

• ein konkretes Ergebnis und warum es unabhängig ist;
• erlaubte Pfade und explizite Schreibzuständigkeit;
• relevanter Kontext, Einschränkungen, geschütztes Verhalten und eingefrorene Schnittstellen;
• erforderliche Beweise, Tests und Ergebnisformat;
• verbotene Aktionen und Eskalationsbedingungen.

Jede Zuweisung ist selbst ein aus dem Arbeitsprotokoll abgeleiteter Prompt und wird dem gleichen Standard unterworfen: klar, prägnant, in sich geschlossen, ein Ergebnis, ohne das Gespräch verständlich. Geben Sie nur den Kontext, der für diesen Arbeitsstrom benötigt wird, aber schließen Sie immer verbindliche Regeln und absolute Pfade zu anwendbaren Anweisungsdateien ein. Weisen Sie nicht dieselbe Verantwortung mehreren Agenten zu, es sei denn, eine explizit angeforderte unabhängige Überprüfung rechtfertigt die Duplizierung. Sub-Agenten dürfen ohne ausdrückliche Autorisierung des Benutzers nicht bereitstellen, veröffentlichen, Daten löschen, Berechtigungen ändern oder destruktive Aktionen durchführen.

Zeichnen Sie das beobachtete Tool/Modell jedes Arbeiters, den Aufwand (oder geerbt/nicht verfügbar), den fokussierten Kontext, das Budget, das Wiederholungslimit und den Auswahlgrund auf. Entdecken Sie externe CLI-Identität, Nicht-Interaktive Unterstützung, Authentifizierung und Modelloptionen, bevor Sie es verwenden. Die bloße Präsenz einer CLI beweist nichts davon. Befolgen Sie das Protokoll für externe Arbeiter in der Routing-Referenz und validieren Sie dessen Diff und Beweise wie jeden anderen Agenten.

Ausführen und Verfolgen paralleler Wellen

Wählen Sie die Persistenzstufe und zeichnen Sie die Arbeitsbaum-Baseline vor dem Dispatch auf. Geben Sie jede bereite Aufgabe in einer Welle als unabhängige Aufrufe in einem Zug aus, mit einem angegebenen Budget. Warten Sie, bis die gesamte Welle zurückkehrt, fehlschlägt oder das Budget überschreitet, bevor Sie abhängige Arbeiten starten. Senden Sie nie eine laufende Aufgabe erneut.

Halten Sie das Hauptthread-Logbuch autoritativ und kommunizieren Sie nur vom Hauptthread mit dem Benutzer. Geben Sie prägnante Updates, wenn Ergebnisse oder Fortschritte sich ändern. Ein Sub-Agent, der eine Genehmigungs- oder Architekturgrenze erreicht, gibt einen Blockierer zurück; er kann keine Zustimmung einholen. Bewerten Sie die Komplexität nach neuen Beweisen neu und hören Sie auf, Arbeiter hinzuzufügen, wenn die Koordination die nützliche Arbeit überwiegt.

Jeder Sub-Agent muss den Standard-Ergebnisvertrag zurückgeben. Leiten Sie tatsächlich geänderte Dateien aus dem Repository-Diff ab, nicht aus dem Bericht des Agenten. Lehnen Sie nicht unterstützte Behauptungen, gebrochene Bindungsregeln, fehlende Beweise und Änderungen außerhalb des Umfangs ab. Vor einem erneuten Versuch bestätigen Sie, dass der vorherige Arbeiter gestoppt hat, überprüfen Sie dessen Umfang, bewahren Sie gültige Teilarbeit und vervollständigen Sie nur, was übrig bleibt. Machen Sie nur einen zuschreibbaren ungültigen Teil rückgängig, wenn erforderlich und autorisiert. Führen Sie niemals Blindwiederholungen durch oder verwenden Sie Repository-weite Stash-, Checkout-, Reset- oder Clean-Befehle.

Klassifizieren Sie Fehler als Aufgabe, Kontext, Tool, Modell oder Umgebung. Standardmäßig maximal zwei Gesamtversuche pro Aufgabe und eine gerechtfertigte Modell-/Aufwands-Eskalation innerhalb dieses Budgets. Reparieren Sie ein mangelhaftes Paket; behandeln Sie Authentifizierung oder fehlende Tools nicht als Argumentationsfehler. Bewahren Sie verifizierte Arbeit von anderen Arbeitern. Wenn kein sicherer nützlicher erneuter Versuch übrig bleibt, prüfen Sie den Blockierer und die genaue nächste Aktion.

Konsolidieren unter einer Autorität

Der Hauptorchestrator überprüft jedes Ergebnis gegen die Vorwellen-Baseline und den tatsächlichen Diff. Lösen Sie Widersprüche durch Überprüfung von Repository-Beweisen, Tests und den Akzeptanzkriterien des Benutzers. Kombinieren Sie niemals stillschweigend wechselseitig inkompatible Empfehlungen.

Befolgen Sie das Konsolidierungs- und Konfliktverfahren in references/contracts.md. Der Hauptorchestrator allein:

• akzeptiert oder lehnt Agentenänderungen ab;
• integriert gemeinsame Dateien und modulübergreifende Verkabelung;
• gleicht Verträge, Benennung, Verhalten und Fehlerbehandlung ab;
• entfernt Duplizierung und Änderungen außerhalb des Umfangs;
• verifiziert, dass die geschützte Funktionalität intakt bleibt.

Verifizieren Sie das integrierte Ergebnis

Führen Sie den kleinsten vollständigen Verifizierungssatz aus, der das angeforderte Verhalten und relevante Regressionen beweist. Schließen Sie gezielte Tests, Integrationstests, statische Prüfungen, Builds und fokussierte manuelle oder UI-Prüfungen ein, wenn zutreffend. Behandeln Sie einzelne Agententests nicht als Beweis dafür, dass das kombinierte Ergebnis funktioniert.

Verwenden Sie die Verifizierungs-Checkliste in references/contracts.md. Markieren Sie jede wesentliche Prüfung als BESTANDEN, FEHLGESCHLAGEN oder Nicht verifiziert. Ein fehlgeschlagener erforderlicher Check blockiert einen Abschlussanspruch.

Melden Sie ein Ergebnis

Geben Sie für direkte Arbeit das angeforderte Ergebnis und die wesentlichen Verifizierungseinschränkungen an. Verwenden Sie für substanzielle delegierte oder fortgesetzte Arbeit den kompakten Abschlussantwortvertrag in references/contracts.md; lassen Sie leere Abschnitte und rohe Agententranskripte weg.

Aufruf und Demonstration

Beispielaufruf:

Verwenden Sie $parallel-task-orchestrator, um einen CSV-Export zu dieser Anwendung hinzuzufügen, Tests und Dokumentation zu aktualisieren, das vorhandene JSON-Exportverhalten zu erhalten und ein verifiziertes Ergebnis zurückzugeben.

Ein ausgearbeitetes, sicheres Multi-Agenten-Beispiel finden Sie unter references/demonstration.md. Für Beispiele mit fokussierten Paketen und Wiederherstellung folgen Sie den Links von references/state-and-resume.md.

Für Änderungen an dieser Fertigkeit führen Sie die Helfer-Tests und realistischen Szenarien in references/acceptance-tests.md aus. Trennen Sie deterministische Helferergebnisse, Agent-Trockentests und tatsächliche externe CLI-Ausführung in den Beweisen.

Anforderungen

Der Zustandshelfer scripts/state_store.py benötigt Python 3.9+ und das Paket jsonschema (pip install jsonschema). Alles andere sind Anweisungen.