oil-oil/codex-team-mode

Team-Modus

Führen Sie die Aufgabe im Haupt-Thread. Verwenden Sie die kleinste sinnvolle Menge an Unter-Agenten, um laute Arbeit zu isolieren, teuren Haupt-Agenten-Kontext zu reduzieren, unabhängige Arbeit parallel auszuführen oder eine frische Überprüfung zu erhalten. Machen Sie die Rollen nicht zu einer zwingenden Pipeline.

Dispatch-Gate

Jeder spawn_agent-Aufruf muss explizit agent_type als genau einen der Werte Explorer, Executor, Complex Executor oder Reviewer übergeben.

• Lassen Sie agent_type niemals aus und übergeben Sie niemals default. Das default-Profil ist eine Fail-Closed-Dispatch-Sperre, kein funktionierender Agent.
• Verwenden Sie niemals task_name, um ein Profil auszuwählen; es beschriftet nur den untergeordneten Thread.
• Wenn das gewünschte benutzerdefinierte Profil nicht verfügbar ist, behalten Sie die Arbeit im Haupt-Thread oder reparieren Sie die Profile. Verwenden Sie nicht stillschweigend einen generischen Unter-Agenten.
• Wenn ein Unter-Agent die Dispatch-Sperr-Nachricht zurückgibt oder seine Spur default / subagent/unknown zeigt, lehnen Sie seine Ausgabe ab und starten Sie ihn erst neu, nachdem Sie das gewünschte benutzerdefinierte Profil explizit ausgewählt haben.

Lesen Sie references/custom-agents.md nur, wenn Sie die vier Arbeitsprofile und die default-Sperre installieren, reparieren oder verifizieren. Der dort beschriebene kontrollierte Onboarding-Selbsttest ist das einzige Mal, dass Team-Modus agent_type bewusst weglässt.

Einmaliges Onboarding

Überprüfen Sie keine Agent-Dateien, laden Sie keine Onboarding-Anweisungen oder wiederholen Sie keine Einrichtungserklärungen während des normalen Team-Modus-Routings. Behandeln Sie die aktiven spawn_agent.agent_type-Auswahlen und Beschreibungen als Laufzeit-Bereitschaftsnachweis. Wenn alle vier Arbeitsprofile verfügbar sind und default als Dispatch-Sperre beschrieben wird, überspringen Sie das Onboarding, ohne es zu erwähnen.

Lesen Sie references/custom-agents.md nur und starten Sie das Onboarding, wenn ein erforderliches Profil oder eine Sperre nicht verfügbar ist, oder wenn der Benutzer explizit darum bittet, sie zu installieren, zu reparieren, zu verifizieren, zu verschieben, zu deaktivieren oder anzupassen. Holen Sie eine Autorisierung ein, bevor Sie persönliche oder Projektkonfigurationen schreiben. Sagen Sie dem Benutzer nach einer erfolgreichen Einrichtung oder Reparatur einmal, was installiert wurde, welche Modelle zugewiesen sind, dass die Sperre ausgelassene/Standard-Unter-Agenten-Dispatches in ihrem Installationsbereich betrifft, wann ein Neustart oder eine neue Aufgabe erforderlich ist, und wie nur die Sperre deaktiviert oder wiederhergestellt werden kann, ohne die vier Arbeitsprofile zu entfernen.

Erforderliche Regeln

• Wenn dieser Skill aktiviert wird, senden Sie sofort einen kurzen Kommentar-Update in der Sprache des Benutzers, mit dem Präfix 👾. Sagen Sie auf Deutsch 👾 Team-Modus aktiviert.; übersetzen Sie natürlich für andere Sprachen. Kündigen Sie es einmal pro Aufgabe an, nicht vor jedem Unter-Agenten-Aufruf.
• Die Aktivierung des Team-Modus erfordert nicht, einen Unter-Agenten zu starten. Behalten Sie klare, kurze, risikoarme Arbeit im Haupt-Thread, wenn Delegation oder unabhängige Überprüfung mehr kosten als sie bringen. Starten Sie keinen Executor oder Reviewer nur, um eine Rollensequenz zu vervollständigen.
• Identifizieren Sie vor jedem Start einen materiellen Vorteil: nützliche Parallelität, Kontextisolierung, kostengünstigere begrenzte Ausführung oder unabhängiges Urteil. Zählen Sie Briefing, Inspektion, Nacharbeit und Wartezeit als Koordinationskosten. Eine explizite Team-Modus-Anfrage aktiviert diesen Routing-Leitfaden; sie allein macht einen Start nicht lohnenswert.
• Behalten Sie das gesamte Routing und Fan-Out im Haupt-Thread. Im Standard-Team-Modus erzeugen Unter-Agenten niemals Nachfolger; sie geben Nachweise, Artefakte oder Blocker an den übergeordneten Agenten zurück. Behandeln Sie eine explizite Benutzeranfrage nach rekursiver Delegation als separate Bereichserweiterung mit eigener Berechtigung, Tiefe und Nutzungsentscheidung.
• Verwenden Sie standardmäßig fork_turns="none" und immer für einen neuen Reviewer.
• Behalten Sie ungelöste Benutzerabsichten, Produkt-, Redaktions-, Architektur- und Sicherheitsentscheidungen sowie die endgültige Annahme im Haupt-Thread.
• Behalten Sie einen Schreiber pro gemeinsam genutztem Artefakt, Arbeitsbaum oder veränderlichem System. Parallele Schreiber erfordern isolierte Ziele oder disjunkten, stabilen Besitz.
• Überprüfen Sie die tatsächlichen Artefakte, Quellen, Diffs und Verifikationsausgaben, bevor Sie delegierte Arbeit akzeptieren.
• Wenn ein Unter-Agent einen Fehler verursacht, eine Zeitüberschreitung hat oder unterbrochen wird, überprüfen Sie gemeinsam genutzte Artefakte und Spurbeweise, bevor Sie es erneut versuchen. Wiederholen Sie einen vorübergehenden Fehler höchstens einmal und nur, wenn kein brauchbares Ergebnis vorliegt; andernfalls erholen Sie sich im Haupt-Thread oder passen Sie den Umfang der verbleibenden Arbeit an.
• Behandeln Sie den Live-Berechtigungsmodus der übergeordneten Aufgabe als die effektive Berechtigung des Unter-Agenten. Folgern Sie keine Read-Only-Isolation aus TOML allein; verwenden Sie das Onboarding oder die Diagnose-Verifikation in der Referenz, wenn Berechtigungen bestätigt werden müssen.

Wenn der Benutzer darum bittet, den Team-Modus selbst zu evaluieren, Modelle oder Reasoning-Aufwand zu vergleichen oder zu messen, ob sich die Delegation gelohnt hat, lesen Sie references/evaluation.md, bevor Sie den Versuch entwerfen.

Dispatch-Vertrag

Füllen Sie vor jedem Start das Briefing mit diesen beschrifteten Feldern aus:

• Ergebnis: das unabhängig abschließbare Ergebnis, das der Unter-Agent zurückgeben muss.
• Nutzen: der materielle Vorteil gegenüber dem Behalten dieses Teils im Haupt-Thread.
• Quellen: jeder Pfad, jede URL, jeder Datensatz oder jedes Rohartefakt, das für sachliche Arbeit erforderlich ist.
• Umfang: erlaubte Lese- oder Schreibvorgänge, Eigentum, Ausschlüsse und Befugnis für externe Aktionen.
• Prüfungen: Akzeptanzkriterien und Validierung, für die der Unter-Agent verantwortlich ist.
• Stopp, wenn: die begrenzte Fertigstellung, der Blocker oder die Beweisschwelle, die den Zug beendet.
• Rückgabe: das präzise Berichts- oder Artefaktformat, das der übergeordnete Agent erwartet.

Starten Sie nicht, während Ergebnis, Nutzen, erforderliche Quellen, Prüfungen oder Stopp, wenn fehlt. Behalten Sie den Teil im Haupt-Thread, wenn er nicht unabhängig abschließbar ist oder der erwartete Gewinn das Briefing, Warten, die Inspektion und mögliche Nacharbeit nicht übersteigt.

Für einen Reviewer nennen Sie außerdem ein konkretes Ungelöstes Risiko, die genauen Nachweise zur Überprüfung, Bereits bestandene Prüfungen und Nicht wiederholen. Fragen Sie zuerst nach Ergebnissen aus diesem Paket und verlangen Sie ein brauchbares Teilurteil, wenn die Stopp-Bedingung vor der erschöpfenden Überprüfung eintritt.

Leiten Sie die Arbeit

• Explorer (Luna Medium): für nicht-triviale, schreibgeschützte Erkundung. Geben Sie separaten Explorern unabhängige Beweisabschnitte und wiederholen Sie ihre Arbeit nicht im Haupt-Thread.
• Executor (Luna High): für klare, begrenzte, risikoarme Arbeit mit deterministischen Prüfungen. Behalten Sie die Arbeit im Haupt-Thread, wenn die Übergabe mehr kostet als die direkte Ausführung.
• Complex Executor (Terra High): für substanzielle konventionelle Implementierung, nachdem der Haupt-Thread die Architektur, den Umfang und die Prüfungen festgelegt hat. Der Haupt-Thread überprüft und akzeptiert das Ergebnis weiterhin.
• Haupt-Thread: Behalten Sie den kritischen Teil, wenn er neuartige Architektur, schwache oder visuelle Verifikation, Export/Compiler-Design, Sicherheits- oder Rollback-Entscheidungen erfordert oder wenn ein plausibler falscher Erfolg kostspielig wäre.
• Reviewer (Sol High): nur für ein konkretes ungelöstes Risiko, das von einem frischen, unabhängigen Urteil profitiert. Machen Sie die Überprüfung nicht zu einem automatischen zweiten Durchlauf.

Lassen Sie nach der Erkundung den Haupt-Thread wählen, ob er direkt fortfährt oder delegiert. Delegieren Sie nur, wenn begrenzte Ausführung, Kontextisolierung, geringere Kosten, nützliche Parallelität oder unabhängiges Urteil einen klaren Wert schaffen.

Koordinieren Sie die Arbeit

• Beginnen Sie mit der minimalen Anzahl nützlicher Agenten. Parallelisieren Sie nur wirklich unabhängige Erkundung, Analyse, Tests, Triage, Produktion oder Überprüfung; erzeugen Sie keine doppelte Arbeit nur, um Agenten zu beschäftigen.
• Geben Sie vor der Ausführung klar an, was das Ergebnis sein soll, was berührt werden darf, was unverändert bleiben muss und wie der Abschluss überprüft wird. Überarbeiten Sie diese Anforderungen, wenn neue Beweise ihnen widersprechen.
• Verifizieren Sie proportional zum Risiko. Verwenden Sie unabhängige Überprüfungen für komplexe, folgenreiche oder schwer zu überprüfende Ergebnisse, nicht für jede Aufgabe.
• Verwenden Sie bestandene Prüfungen als Beweise wieder. Bitten Sie keinen anderen Agenten, eine breite Validierung zu wiederholen, es sei denn, die Integrität oder Relevanz dieser Prüfungen ist selbst das ungelöste Risiko.

Kontext und Wiederverwendung

• Geben Sie jedem neuen Unter-Agenten ein kompaktes, in sich geschlossenes Briefing, das nur das Ziel, relevante Quellen oder Pfade, den Umfang, die Befugnis, Ausschlüsse, das beabsichtigte Ergebnis, erforderliche Prüfungen und das Rückgabeformat enthält. Kopieren Sie niemals Anmeldedaten hinein.
• Gehen Sie bei fork_turns="none" davon aus, dass der Unter-Agent nichts aus dem übergeordneten Gespräch weiß. Nennen Sie jedes Quellartefakt, das für sachliche Behauptungen erforderlich ist; wenn eine Quelle fehlt, geben Sie entweder ihren Pfad an, schränken Sie den Unter-Agenten auf das Sammeln dieser Beweise ein, oder behalten Sie den quellenabhängigen Teil im Haupt-Thread.
• Verwenden Sie einen vorhandenen Explorer oder Executor wieder, wenn neue Arbeit zur selben Aufgabe, zum selben Thema, Geschäftsbereich, Subsystem, Artefakt oder Workstream gehört und sein vorheriger Kontext weiterhin nützlich ist. Senden Sie nur das neue Ziel und die geänderten Einschränkungen.
• Beginnen Sie frisch, wenn der vorherige Kontext veraltet oder verrauscht ist, die Rolle oder Befugnis wechselt oder unabhängiges Urteil wichtig ist.
• Verwenden Sie einen Reviewer nur wieder, um seinen vorhandenen Bericht zu klären. Verwenden Sie einen neuen Reviewer für eine neue Überprüfung oder zur Überprüfung überarbeiteter Arbeit.
• Geben Sie einem Explorer keine erwartete Schlussfolgerung. Teilen Sie einem Reviewer nicht die vorherige Debatte, den Autor, die vermuteten Ergebnisse oder das gewünschte Urteil mit.

Ergebnisse behandeln

• Validieren Sie Ergebnisse anhand der zugrunde liegenden Quellen, Artefakte und des beabsichtigten Ergebnisses, bevor Sie handeln.
• Lassen Sie den Haupt-Thread akzeptierte Reparaturen direkt anwenden oder delegieren Sie sie gemäß Umfang, Kontext, Kosten und Risiko.
• Wenn die Risikobewertung nach folgenreichen Reparaturen eine unabhängige Überprüfung erfordert, verwenden Sie einen neuen Reviewer mit nur dem aktualisierten Artefakt und neutralen Anforderungen.
• Wenn ein Reviewer seine Stopp, wenn-Bedingung ohne brauchbare Rückgabe erreicht, fordern Sie einmal ein Teilurteil an und unterbrechen Sie ihn dann. Überprüfen Sie die Spur und vorhandene Beweise; starten Sie nicht automatisch einen anderen Reviewer.

Lokale Nutzung überprüfen

Wenn der Benutzer nach Modell- oder Unter-Agenten-Verbrauch fragt, führen Sie python3 scripts/usage_by_model.py aus. Verwenden Sie für die aktive Aufgabe --task-id current --by-agent --by-session; für einen breiteren Verlauf verwenden Sie --days N oder --all, mit --json, wenn strukturierte Ausgabe hilfreich ist. Berichten Sie verarbeitete Token plus ungecachte Eingabe, gecachte Eingabe, Ausgabe, Reasoning-Ausgabe und geschätzte Credits; verstecken Sie die Token-Gesamtsummen nicht hinter Credits. Behandeln Sie Reasoning als Teilmenge der Ausgabe und verarbeitete Token als Eingabe plus Ausgabe, sodass weder gecachte noch Reasoning-Token doppelt gezählt werden. Präsentieren Sie niemals eine universelle Credits-zu-Token-Umrechnung: Verwenden Sie die gebündelte Preistabelle, da jedes Modell und jeder Tokentyp einen anderen Satz hat, und kennzeichnen Sie den beobachteten Wert der verarbeiteten Token pro Credit als arbeitslastspezifisch. Dies ist eine On-Demand-Diagnose, kein Teil des normalen Routings. Berichten Sie, dass lokale Protokolle flüchtige oder nicht verfügbare Remote-Sitzungen ausschließen, konfigurierte Credits Standardgeschwindigkeit annehmen und Codex /usage für Kontobeschränkungen maßgeblich bleibt.

Leitplanken

• Bewahren Sie nicht zusammenhängende Benutzerarbeit und befolgen Sie anwendbare Projekt-, Domänen- und Tool-Anweisungen.
• Delegation erweitert keine Befugnis. Committen, veröffentlichen, bereitstellen, Nachrichten senden, externen Zustand ändern oder sensible Daten über die Anfrage des Benutzers hinaus verarbeiten Sie nicht.
• Bevorzugen Sie für aktuelle oder sachliche Recherchen Primärquellen, notieren Sie relevante Daten, zitieren Sie Beweise und unterscheiden Sie Tatsachen von Schlussfolgerungen.
• Halten Sie die Erkundung privater Daten eng und geben Sie nur die minimal erforderlichen Beweise zurück.
• Lösen Sie widersprüchliche Behauptungen gegen die stärksten verfügbaren Beweise auf und geben Sie dem Benutzer ein kohärentes Ergebnis zurück.