team

Team Skill

Starte N koordinierte Agenten, die an einer gemeinsamen Aufgabenliste arbeiten – mithilfe von Claude Codes implizitem Agenten-Team. Claude Code 2.1.178+ hat die nativen TeamCreate/TeamDelete entfernt; mit CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 besitzt jede Sitzung ein implizites Team und Teammitglieder werden direkt mit dem Agent/Task-Tool unter Verwendung unterschiedlicher name-Werte gestartet. Diese Skill bewahrt weiterhin OMCs legacy tmux/CLI-Worker-Orchestrierung, wo dokumentiert (omc team / /omc-teams).

Der swarm-Kompatibilitätsalias wurde in #1131 entfernt.

Verwendung

/oh-my-claudecode:team N:agent-type "Aufgabenbeschreibung"
/oh-my-claudecode:team "Aufgabenbeschreibung"
/oh-my-claudecode:team ralph "Aufgabenbeschreibung"

Parameter

• N – Anzahl der Team-Agenten (1‑20). Optional; standardmäßig automatische Größenanpassung basierend auf Aufgabenzerlegung.
• agent-type – OMC-Agent, der für die team-exec-Phase gestartet werden soll (z. B. executor, debugger, designer, codex, gemini, antigravity). Optional; standardmäßig phasenabhängige Weiterleitung. Verwende codex, um Codex CLI-Worker zu starten, gemini für Gemini CLI-Worker (Enterprise/API-Key-Tarif) oder antigravity für Antigravity CLI (agy)-Worker (Googles Nachfolger des Gemini CLI; erfordert entsprechende CLI-Installation). Siehe Phasen-Agent-Routing unten.
• task – Hochrangige Aufgabe, die aufgeteilt und auf die Teammitglieder verteilt werden soll.
• ralph – Optionaler Modifikator. Wenn vorhanden, wird die Team-Pipeline in Ralphs Persistenz-Schleife eingebunden (Wiederholung bei Fehlern, Architektenprüfung vor Abschluss). Siehe Team + Ralph Komposition unten.

Beispiele

/team 5:executor "behebe alle TypeScript-Fehler im gesamten Projekt"
/team 3:debugger "behebe Buildfehler in src/"
/team 4:designer "implementiere responsive Layouts für alle Seitenkomponenten"
/team "überarbeite das Auth-Modul mit Sicherheitsüberprüfung"
/team ralph "erstelle eine vollständige REST-API für Benutzerverwaltung"
# Mit Codex CLI-Workern (erfordert: npm install -g @openai/codex)
/team 2:codex "überprüfe die Architektur und schlage Verbesserungen vor"
# Mit Gemini CLI-Workern (erfordert: npm install -g @google/gemini-cli)
/team 2:gemini "gestalte die UI-Komponenten neu"
# Mit Antigravity CLI-Workern (erfordert: Installation gemäß https://antigravity.google)
/team 2:antigravity "gestalte die UI-Komponenten neu"
# Gemischt: Codex für Backend-Analyse, Gemini/Antigravity für Frontend (delegiere pro Aufgabe mit /oh-my-claudecode:ask)

Architektur

Benutzer: "/team 3:executor behebe alle TypeScript-Fehler"
              |
              v
      [TEAM-ORCHESTRATOR (Leitagent)]
              |
              +-- Nutze das implizite Claude Code Team der Sitzung
              |       -> kein TeamCreate-Aufruf; Leitagent bleibt in der aktuellen Sitzung
              |
              +-- Analysiere und zerlege die Aufgabe in Teilaufgaben
              |       -> explore/architect erstellt Liste von Teilaufgaben
              |
              +-- Erstelle Einträge in der Aufgabenliste aus dem Implementierungsplan
              |       -> TODO/Task-Einträge #1, #2, #3 mit Abhängigkeiten
              |
              +-- Aktualisiere Einträge der Aufgabenliste (weise Besitzer vorab zu)
              |       -> Aufgabe #1 Besitzer=worker-1, usw.
              |
              +-- Task(name="worker-1") x 3
              |       -> starte Teammitglieder in das Team
              |
              +-- Überwachungsschleife
              |       <- Nachrichten der Teammitglieder (automatisch zugestellt durch die aktive Team-Oberfläche)
              |       -> Aufgabenliste/TodoWrite-Überprüfung auf Fortschritt
              |       -> sende Nachrichten an Teammitglieder über die aktive Team-Oberfläche, um zu entblocken/koordinieren
              |
              +-- Abschluss
                      -> bitte jedes Teammitglied um Beendigung über die aktive Team-Oberfläche
                      <- Bestätigung der Beendigung von Teammitgliedern
                      -> lösche OMC-Teamstatus (kein TeamDelete-Aufruf)
                      -> rm .omc/state/team-state.json

Natives Claude Code Team-Modell (2.1.178+):

- Von dieser Skill wird kein pro-Team ~/.claude/teams/<name>/ Verzeichnis erstellt.
- Es sind keine TeamCreate/TeamDelete-Aufrufe verfügbar.
- `team_name` wird von nativem Claude Code nur als ignorierte Legacy-Metadaten akzeptiert; verwende es nicht für das Routing.
- Starte Teammitglieder direkt über Agent/Task mit `name="worker-N"`.

Beziehung zum Ziel-Workflow

Team ist die OMC-Autorität für parallele, gestaffelte Ausführung. Verwende die deterministischen Konfliktrichtlinien refuse, adopt_existing und artifact_only anstelle von nicht-deterministischer Warnungsbehandlung. Wenn eine Aufgabe Claude Code /goal, Ralph oder artefaktbasiertes Ultragoal erwähnt, behalte Team als primäre Schleifenautorität, es sei denn, der Leiter übergibt explizit. Verwende /goal nur als dokumentiertes natives Claude Code-Übergabeziel oder als sichtbaren Nachweis aus der Leitersitzung; behaupte nicht, dass der /goal-Evaluator unabhängig Befehle ausführt, Dateien liest oder team-verify/team-fix ersetzt. Artefaktbasierte Ultragoal-Referenzen sollten als dauerhafte Ziel-Hauptbuch/Checkpoint/Evidenz-Artefakte behandelt werden, nicht als eigenständige Worker-Ausführung.

Gestaffelte Pipeline (Kanonische Team-Laufzeit)

Die Team-Ausführung folgt einer gestaffelten Pipeline:

team-plan -> team-prd -> team-exec -> team-verify -> team-fix (Schleife)

Phasen-Agent-Routing

Jede Pipeline-Phase verwendet spezialisierte Agenten – nicht nur Executors. Der Leitagent wählt Agenten basierend auf der Phase und den Aufgabenmerkmalen aus.

Phase	Erforderliche Agenten	Optionale Agenten	Auswahlkriterien
team-plan	explore (haiku), planner (opus)	analyst (opus), architect (opus)	Verwende analyst bei unklaren Anforderungen. Verwende architect bei Systemen mit komplexen Grenzen.
team-prd	analyst (opus)	critic (opus)	Verwende critic, um den Umfang zu hinterfragen.
team-exec	executor (sonnet)	executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet)	Passe den Agenten an den Teilaufgabentyp an. Verwende executor (modell=opus) für komplexe autonome Arbeit, designer für UI, debugger für Kompilierungsprobleme, writer für Dokumentation, test-engineer für die Erstellung von Tests.
team-verify	verifier (sonnet)	test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus)	Führe immer verifier aus. Füge security-reviewer für Auth/Krypto-Änderungen hinzu. Füge code-reviewer für >20 Dateien oder Architekturänderungen hinzu. code-reviewer deckt auch Stil-/Formatierungsprüfungen ab.
team-fix	executor (sonnet)	debugger (sonnet), executor (opus)	Verwende debugger für Typ-/Buildfehler und Regressionsisolierung. Verwende executor (modell=opus) für komplexe dateiübergreifende Korrekturen.

Routing-Regeln:

1. Der Leitagent wählt Agenten pro Phase aus, nicht der Benutzer. Der Parameter N:agent-type des Benutzers überschreibt nur den Arbeitertyp der team-exec-Phase. Alle anderen Phasen verwenden phasenspezifische Spezialisten.
2. Spezialisten ergänzen Executor-Agenten. Leite Analysen/Überprüfungen an architect/critic Claude-Agenten und UI-Arbeiten an designer-Agenten weiter. Tmux CLI-Worker sind Einmalschüsse und nehmen nicht an der Teamkommunikation teil.
3. Kostenmodus beeinflusst die Modellstufe. Im Downgrade: opus-Agenten zu sonnet, sonnet zu haiku, wo die Qualität es erlaubt. team-verify verwendet immer mindestens sonnet.
4. Risikostufe erhöht die Überprüfung. Sicherheitsrelevante oder >20 Dateien umfassende Änderungen müssen security-reviewer + code-reviewer (opus) in team-verify einschließen.

Phasen-Eintritts- und Austrittskriterien

• team-plan
  • Eintritt: Team-Aufruf wird analysiert und Orchestrierung startet.
  • Agenten: explore durchsucht die Codebasis, planner erstellt Aufgabengraph, optional analyst/architect für komplexe Aufgaben.
  • Austritt: Zerlegung ist abgeschlossen und ein ausführbarer Aufgabengraph ist vorbereitet.
• team-prd
  • Eintritt: Umfang ist mehrdeutig oder Akzeptanzkriterien fehlen.
  • Agenten: analyst extrahiert Anforderungen, optional critic.
  • Austritt: Akzeptanzkriterien und Grenzen sind explizit.
• team-exec
  • Eintritt: Aufgabenlistenzuweisung und Worker-Start sind abgeschlossen.
  • Agenten: Worker werden als passender Spezialistentyp pro Teilaufgabe gestartet (siehe Routing-Tabelle).
  • Austritt: Ausführungsaufgaben erreichen für den aktuellen Durchlauf einen Endzustand.
• team-verify
  • Eintritt: Ausführungsdurchlauf endet.
  • Agenten: verifier + aufgabenangepasste Prüfer (siehe Routing-Tabelle).
  • Austritt (bestanden): Überprüfungsgates sind ohne erforderliche Nachverfolgung bestanden.
  • Austritt (fehlgeschlagen): Korrekturaufgaben werden generiert und die Kontrolle geht an team-fix über.
• team-fix
  • Eintritt: Überprüfung hat Fehler/Regressionen/unvollständige Kriterien festgestellt.
  • Agenten: executor/debugger, abhängig vom Fehlertyp.
  • Austritt: Korrekturen sind abgeschlossen und der Ablauf kehrt zu team-exec und dann team-verify zurück.

Überprüfen/Korrigieren-Schleife und Stoppbedingungen

Fahre team-exec -> team-verify -> team-fix fort, bis:

1. die Überprüfung bestanden ist und keine erforderlichen Korrekturaufgaben mehr vorhanden sind, oder
2. die Arbeit ein explizites terminales blockiert/fehlgeschlagenes Ergebnis mit Nachweisen erreicht.

team-fix ist durch maximale Versuche begrenzt. Wenn Korrekturversuche das konfigurierte Limit überschreiten, wechsle zu terminal failed (keine Endlosschleife).

Phasenübergabe-Konvention

Beim Übergang zwischen Phasen verbleiben wichtige Kontexte – getroffene Entscheidungen, abgelehnte Alternativen, identifizierte Risiken – nur im Gesprächsverlauf des Leitagenten. Wenn der Kontext des Leitagenten komprimiert wird oder Agenten neu starten, geht dieses Wissen verloren.

Jede abgeschlossene Phase MUSS vor dem Übergang ein Übergabedokument erstellen.

Der Leitagent schreibt Übergaben nach .omc/handoffs/<phasenname>.md.

Übergabeformat

## Übergabe: <aktuelle-phase> → <nächste-phase>

- **Entschieden**: [wichtige Entscheidungen in dieser Phase]
- **Abgelehnt**: [Alternativen und warum sie abgelehnt wurden]
- **Risiken**: [identifizierte Risiken für die nächste Phase]
- **Dateien**: [wichtige erstellte oder geänderte Dateien]
- **Verbleibend**: [Punkte, die von der nächsten Phase zu erledigen sind]

Übergaberegeln

1. Der Leitagent liest die vorherige Übergabe, BEVOR er die Agenten der nächsten Phase startet. Der Übergabeinhalt wird in die Startaufforderungen der nächsten Phase aufgenommen, sodass Agenten mit vollständigem Kontext beginnen.
2. Übergaben sammeln sich an. Die Überprüfungsphase kann alle vorherigen Übergaben (plan → prd → exec) für den vollständigen Entscheidungsverlauf lesen.
3. Bei Team-Abbruch bleiben Übergaben erhalten in .omc/handoffs/ für die Sitzungswiederaufnahme. Sie werden nicht durch natives Claude Code Team-Cleanup gelöscht; in Claude Code 2.1.178+ gibt es keinen TeamDelete-Aufruf.
4. Übergaben sind schlank. Maximal 10-20 Zeilen. Sie erfassen Entscheidungen und Begründungen, keine vollständigen Spezifikationen (diese leben in auslieferbaren Dateien wie DESIGN.md).

Beispiel

## Übergabe: team-plan → team-exec

- **Entschieden**: Microservice-Architektur mit 3 Diensten (auth, api, worker). PostgreSQL für Persistenz. JWT für Auth-Tokens.
- **Abgelehnt**: Monolith (Skalierungsbedenken), MongoDB (Team-Expertise ist SQL), Session-Cookies (API-first-Design).
- **Risiken**: Worker-Dienst benötigt Redis für Job-Warteschlange – noch nicht bereitgestellt. Auth-Dienst hat kein Ratenlimit im ersten Design.
- **Dateien**: DESIGN.md, TEST_STRATEGY.md
- **Verbleibend**: Datenbank-Migrationsskripte, CI/CD-Pipeline-Konfiguration, Redis-Bereitstellung.

Wiederaufnahme- und Abbruch-Semantik

• Wiederaufnahme: starte neu ab der letzten nicht-terminalen Phase unter Verwendung des Phasenzustands + Live-Aufgabenstatus. Lese .omc/handoffs/, um den Phasenübergabekontext wiederherzustellen.
• Abbruch: /oh-my-claudecode:cancel fordert die Beendigung von Teammitgliedern an, wartet auf Antworten (Best-Effort), markiert die Phase als cancelled mit active=false, erfasst Abbruch-Metadaten, löscht dann Team-Ressourcen und löscht/erhält den Team-Zustand gemäß Richtlinie. Übergabedateien in .omc/handoffs/ werden für eine mögliche Wiederaufnahme erhalten.
• Terminale Zustände sind complete, failed und cancelled.

Windows psmux tmux-kompatibles Gate

Unter nativem Windows solltest du Benutzern nicht mitteilen, dass /team WSL erfordert oder dass tmux nicht verfügbar ist, bis die tatsächliche tmux-kompatible Binärdatei überprüft wurde. Natives psmux installiert einen tmux-kompatiblen Befehl (oft tmux / tmux.cmd) und ist ein unterstützter Team-Multiplexer.

Bevor du unter Windows blockierst oder zurückfällst:

1. Überprüfe tmux -V (oder die plattformäquivalente Methode wie where tmux gefolgt von tmux -V).
2. Behandle eine erfolgreiche psmux-gestützte tmux -V als verfügbares tmux.
3. Wenn psmux/tmux verfügbar ist, fahre mit dem normalen Team-Ablauf fort; gib keine WSL-erforderliche Anleitung aus.
4. Nur wenn keine tmux-kompatible Binärdatei verfügbar ist, teile dem Benutzer mit, psmux für nativen Windows-Support zu installieren oder WSL2 als Alternative zu verwenden.

Arbeitsablauf

Phase 1: Eingabe parsen

• Extrahiere N (Anzahl der Agenten), validiere 1-20
• Extrahiere agent-type, validiere, dass es einem bekannten OMC-Subagenten zugeordnet ist
• Extrahiere task-Beschreibung

Phase 2: Analysieren & Zerlegen

Verwende explore oder architect (über MCP oder Agent), um die Codebasis zu analysieren und die Aufgabe in N Teilaufgaben zu zerlegen:

• Jede Teilaufgabe sollte dateibezogen oder modulbezogen sein, um Konflikte zu vermeiden
• Teilaufgaben müssen unabhängig sein oder eine klare Abhängigkeitsreihenfolge aufweisen