Erstellt eine neue Teamzusammensetzungsdatei gemaess der agent-almanac- Teamvorlage und Registry-Konventionen. Behandelt Definition des Teamzwecks, Mitgliederauswahl, Wahl des Koordinationsmusters, Aufgabenzerlegungsdesign, maschinenlesbaren Konfigurationsblock, Registry-Integration und README-Automatisierung. Verwenden beim Definieren eines Multi-Agenten- Workflows, beim Zusammenstellen von Agenten fuer einen komplexen Pruefungsprozess oder beim Erstellen einer koordinierten Gruppe fuer wiederkehrende kollaborative Aufgaben.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Erstellt eine neue Teamzusammensetzungsdatei gemaess der agent-almanac- Teamvorlage und Registry-Konventionen. Behandelt Definition des Teamzwecks, Mitgliederauswahl, Wahl des Koordinationsmusters, Aufgabenzerlegungsdesign, maschinenlesbaren Konfigurationsblock, Registry-Integration und README-Automatisierung. Verwenden beim Definieren eines Multi-Agenten- Workflows, beim Zusammenstellen von Agenten fuer einen komplexen Pruefungsprozess oder beim Erstellen einer koordinierten Gruppe fuer wiederkehrende kollaborative Aufgaben.
Eine Multi-Agenten-Teamzusammensetzung definieren, die zwei oder mehr Agenten koordiniert, um Aufgaben zu erledigen, die mehrere Perspektiven, Spezialgebiete oder Phasen erfordern. Die resultierende Teamdatei wird in die Teams-Registry integriert und kann in Claude Code namentlich aktiviert werden.
Wann verwenden
Eine Aufgabe erfordert mehrere Perspektiven, die ein einzelner Agent nicht liefern kann (z.B. Code-Review plus Sicherheitspruefung plus Architektur-Review)
Ein wiederkehrender kollaborativer Workflow mit konsistenten Rollenzuweisungen und Uebergabemustern wird benoetigt
Eine bestehende Agenten-Zusammensetzung wird wiederholt verwendet und soll formalisiert werden
Ein komplexer Prozess zergliedert sich natuerlich in Phasen oder Spezialgebiete, die von verschiedenen Agenten behandelt werden
Eine koordinierte Gruppe fuer sprint-basierte, pipeline-basierte oder parallele Arbeit definiert werden soll
Eingaben
Erforderlich: Teamname (Kleinbuchstaben-Kebab-Case, z.B. data-pipeline-review)
Erforderlich: Teamzweck (ein Absatz der beschreibt, welches Problem mehrere Agenten erfordert)
Erforderlich: Lead-Agent (muss in agents/_registry.yml existieren)
Optional: Anzahl der Mitglieder (Standard: 3-4; empfohlener Bereich: 2-5)
Optional: Quellmaterial (bestehender Workflow, Runbook oder Ad-hoc-Teamzusammensetzung zur Formalisierung)
Vorgehensweise
Schritt 1: Teamzweck definieren
Artikulieren, welches Problem mehrere gemeinsam arbeitende Agenten erfordert. Ein gueltiger Teamzweck muss antworten:
Welches Ergebnis liefert dieses Team? (z.B. ein umfassender Pruefbericht, eine bereitgestellte Anwendung, ein Sprint-Inkrement)
Warum kann ein einzelner Agent dies nicht tun? Mindestens zwei unterschiedliche Spezialgebiete oder Perspektiven identifizieren.
Wann sollte dieses Team aktiviert werden? Ausloesebedingungen definieren.
Den Zweck als einen Absatz schreiben, den ein Mensch oder Agent lesen kann, um zu entscheiden, ob dieses Team aktiviert werden soll.
Erwartet: Ein klarer Absatz, der das Wertangebot des Teams erklaert, mit mindestens zwei identifizierten unterschiedlichen Spezialgebieten.
Bei Fehler: Falls keine zwei unterschiedlichen Spezialgebiete identifiziert werden koennen, braucht die Aufgabe wahrscheinlich kein Team. Stattdessen einen einzelnen Agenten mit mehreren Skills verwenden.
Schritt 2: Lead-Agenten auswaehlen
Der Lead-Agent orchestriert das Team. Einen Agenten aus agents/_registry.yml waehlen, der:
Ueber Domain-Expertise relevant fuer den primaeren Output des Teams verfuegt
Eingehende Anfragen in Teilaufgaben fuer andere Mitglieder zerlegen kann
Ergebnisse von mehreren Pruefern zu einem kohaerenten Lieferobjekt zusammenfuehren kann
# Alle verfuegbaren Agenten auflisten
grep "^ - id:" agents/_registry.yml
Der Lead muss auch als Mitglied in der Teamzusammensetzung erscheinen (der Lead ist immer ein Mitglied).
Erwartet: Ein Agent als Lead ausgewaehlt, dessen Existenz in der Agenten-Registry bestaetigt.
Bei Fehler: Falls kein bestehender Agent fuer die Lead-Rolle passt, zuerst einen erstellen mit dem Skill create-agent. Kein Team mit einem Lead erstellen, der nicht als Agentendefinition existiert.
Schritt 3: Mitglieder-Agenten auswaehlen
2-5 Mitglieder (einschliesslich des Leads) mit klaren, nicht ueberlappenden Verantwortlichkeiten waehlen. Fuer jedes Mitglied definieren:
id: Agentenname aus der Agenten-Registry
role: Ein kurzer Titel (z.B. "Qualitaetspruefer", "Sicherheitsauditor", "Architektur-Reviewer")
responsibilities: Ein Satz der beschreibt, was dieses Mitglied tut, was kein anderes tut
# Pruefen ob jeder Kandidat-Agent existiert
grep "id: agent-name-here" agents/_registry.yml
Nicht-Ueberschneidung pruefen: keine zwei Mitglieder sollten dieselbe primaere Verantwortlichkeit haben. Falls Verantwortlichkeiten sich ueberschneiden, entweder die Rollen zusammenfuehren oder die Grenzen schaerfen.
Erwartet: 2-5 Mitglieder ausgewaehlt, jeweils mit einer einzigartigen Rolle und klaren Verantwortlichkeiten, alle in der Agenten-Registry bestaetigt.
Bei Fehler: Falls ein benotigter Agent nicht existiert, zuerst einen erstellen. Falls Verantwortlichkeiten zwischen zwei Mitgliedern ueberlappen, sie umschreiben, um Grenzen zu klaeren, oder ein Mitglied entfernen.
Schritt 4: Koordinationsmuster waehlen
Das Muster waehlen, das am besten zum Workflow des Teams passt. Die fuenf Muster und ihre Anwendungsfaelle:
Muster
Wann verwenden
Beispielteams
hub-and-spoke
Lead verteilt Aufgaben, sammelt Ergebnisse, synthetisiert. Am besten fuer Review- und Audit-Workflows.
r-package-review, gxp-compliance-validation
sequential
Jeder Agent baut auf der Ausgabe des vorherigen auf. Am besten fuer Pipelines und phasenweise Workflows.
fullstack-web-dev, tending
parallel
Alle Agenten arbeiten gleichzeitig an unabhaengigen Teilaufgaben. Am besten wenn Teilaufgaben keine Abhaengigkeiten haben.
devops-platform-engineering
timeboxed
Arbeit in feste Iterationen unterteilt. Am besten fuer laufende Projektarbeit mit einem Backlog.
scrum-team
adaptive
Team selbst-organisiert sich basierend auf der Aufgabe. Am besten fuer unbekannte oder hochvariable Aufgaben.
opaque-team
Entscheidungshilfe:
Falls der Lead alle Ergebnisse sehen muss, bevor er Output liefert: hub-and-spoke
Falls Agent B die Ausgabe von Agent A benoetigt, um zu beginnen: sequential
Falls alle Agenten ohne Ergebnisse der anderen arbeiten koennen: parallel
Falls die Arbeit mehrere Iterationen mit Planungszeremonien umfasst: timeboxed
Falls die Aufgabenstruktur nicht im Voraus vorhersagbar ist: adaptive
Erwartet: Ein Koordinationsmuster mit einer klaren Begruendung fuer die Wahl.
Bei Fehler: Im Zweifel hub-and-spoke verwenden. Es ist das haeufigste Muster und funktioniert fuer die meisten Review- und Analyse-Workflows.
Schritt 5: Aufgabenzerlegung entwerfen
Definieren, wie eine typische eingehende Anfrage auf die Teammitglieder aufgeteilt wird. Als Phasen strukturieren:
Einrichtungsphase: Was der Lead tut, um die Anfrage zu analysieren und Aufgaben zu erstellen
Ausfuehrungsphase: Woran jedes Mitglied arbeitet (parallel, sequenziell oder pro Sprint je nach Koordinationsmuster)
Synthesephase: Wie Ergebnisse gesammelt und das endgueltige Lieferobjekt erstellt wird
Fuer jedes Mitglied 3-5 konkrete Aufgaben auflisten, die sie bei einer typischen Anfrage erledigen wuerden.
Erwartet: Eine phasenbezogene Zerlegung mit konkreten Aufgaben pro Mitglied, die dem gewahlten Koordinationsmuster entspricht.
Bei Fehler: Falls Aufgaben zu vage sind (z.B. "prueft Dinge"), sie spezifischer machen (z.B. "prueft Code-Stil gegen den tidyverse Style Guide, prueft Testabdeckung, bewertet Fehlermeldungsqualitaet").
Schritt 6: Die Teamdatei schreiben
Vorlage kopieren und alle Abschnitte ausfuellen:
cp teams/_template.md teams/<team-name>.md
Folgende Abschnitte in dieser Reihenfolge ausfuellen:
YAML-Frontmatter: name, description, lead, version ("1.0.0"), author, created, updated, tags, coordination, members[] (jeweils mit id, role, responsibilities)
Titel: # Team Name (menschenlesbar, Titelschreibweise)
Einfuehrung: Zusammenfassender Absatz
Zweck: Warum dieses Team existiert, welche Spezialgebiete es vereint
Teamzusammensetzung: Tabelle mit Spalten Mitglied, Agent, Rolle, Schwerpunkte
Koordinationsmuster: Prosabeschreibung plus ASCII-Diagramm des Ablaufs
Aufgabenzerlegung: Phasengliederung mit konkreten Aufgaben pro Mitglied
Verwendungsszenarien: 2-3 konkrete Szenarien mit Beispiel-Benutzeranfragen
Einschraenkungen: 3-5 bekannte Beschraenkungen
Siehe auch: Links zu Mitglieder-Agentendateien und verwandten Skills/Teams
Erwartet: Eine vollstaendige Teamdatei mit allen ausgefuellten Abschnitten, ohne verbleibenden Platzhaltertext aus der Vorlage.
Bei Fehler: Mit einer bestehenden Teamdatei vergleichen (z.B. teams/r-package-review.md), um die Struktur zu pruefen. Nach Vorlage-Platzhalterstrings wie "your-team-name" oder "another-agent" suchen.
Schritt 7: Den CONFIG-Block schreiben
Der CONFIG-Block zwischen <!-- CONFIG:START --> und <!-- CONFIG:END --> liefert maschinenlesbares YAML fuer Werkzeuge. So strukturieren:
Das Feld subagent_type ordnet Claude Code-Agententypen zu. Fuer Agenten in .claude/agents/ die Agenten-ID als subagent_type verwenden. blocked_by zur Ausdrueckung von Aufgabenabhaengigkeiten verwenden.
Erwartet: CONFIG-Block ist gueltiges YAML, alle Agenten stimmen mit denen in der Frontmatter-Mitgliederliste ueberein und Aufgabenabhaengigkeiten bilden einen gueltigen DAG (keine Zyklen).
Bei Fehler: YAML-Syntax pruefen. Sicherstellen, dass jeder assignee in der Aufgabenliste einem agent in der Mitgliederliste entspricht. Pruefen ob blocked_by nur Aufgabennamen referenziert, die frueher in der Liste definiert wurden.
Schritt 8: Zur Registry hinzufuegen
teams/_registry.yml bearbeiten, um das neue Team hinzuzufuegen:
Den total_teams-Zaehler am Anfang der Registry aktualisieren.
# Pruefen ob der Eintrag hinzugefuegt wurde
grep "id: <team-name>" teams/_registry.yml
Erwartet: Neuer Eintrag erscheint in der Registry, total_teams-Zaehler ist um eins erhoeht.
Bei Fehler: Falls der Teamname bereits in der Registry existiert, einen anderen Namen waehlen oder den bestehenden Eintrag aktualisieren. Pruefen ob die YAML-Einrueckung mit bestehenden Eintraegen uebereinstimmt.
Schritt 9: README-Automatisierung ausfuehren
README-Dateien aus der aktualisierten Registry neu generieren:
npm run update-readmes
Erwartet: Befehl beendet mit 0, teams/README.md listet jetzt das neue Team auf.
Bei Fehler:npm run check-readmes ausfuehren, um zu sehen, welche Dateien veraltet sind. Falls das Skript fehlschlaegt, pruefen ob package.json im Repository-Stamm existiert und js-yaml installiert ist (npm install).
Schritt 10: Team-Aktivierung pruefen
Testen, ob das Team in Claude Code aktiviert werden kann:
User: Verwende das <team-name>-Team fuer <typische Aufgabenbeschreibung>
Claude Code sollte:
Die Teamdatei unter teams/<team-name>.md finden
Lead und Mitglieder identifizieren
Das in der Datei beschriebene Koordinationsmuster befolgen
Erwartet: Claude Code erkennt den Teamnamen, identifiziert den korrekten Lead und die Mitglieder und befolgt das Koordinationsmuster.
Bei Fehler: Pruefen ob die Teamdatei unter teams/<team-name>.md liegt (nicht in einem Unterverzeichnis). Pruefen ob alle Mitglieder-Agenten in .claude/agents/ existieren (das auf agents/ verweist). Bestaetigen, dass das Team in teams/_registry.yml aufgefuehrt ist.
Schritt 11: Uebersetzungen anlegen
Erforderlich fuer alle Teams. Dieser Schritt gilt sowohl fuer menschliche Autoren als auch fuer KI-Agenten, die dieser Vorgehensweise folgen. Nicht ueberspringen — fehlende Uebersetzungen sammeln sich zu einem veralteten Backlog an.
Unmittelbar nach dem Committen des neuen Teams Uebersetzungsdateien fuer alle 4 unterstuetzten Locales anlegen:
for locale in de zh-CN ja es; do
npm run translate:scaffold -- teams <team-name> "$locale"done
Anschliessend die angelegte Prosa in jeder Datei uebersetzen (Code-Bloecke und IDs bleiben auf Englisch). Abschliessend die Statusdateien neu generieren:
npm run translation:status
Erwartet: 4 Dateien unter i18n/{de,zh-CN,ja,es}/teams/<team-name>.md erstellt, alle mit source_commit, der dem aktuellen HEAD entspricht. npm run validate:translations zeigt 0 Stale-Warnungen fuer das neue Team.
Bei Fehler: Falls das Scaffolding fehlschlaegt, pruefen ob das Team in teams/_registry.yml existiert. Falls sich die Statusdateien nicht aktualisieren, npm run translation:status explizit ausfuehren — es wird nicht automatisch von CI ausgeloest.
Validierung
Teamdatei existiert unter teams/<team-name>.md
YAML-Frontmatter wird fehlerfrei geparst
Alle Pflicht-Frontmatter-Felder vorhanden: name, description, lead, version, author, coordination, members[]
Jedes Mitglied im Frontmatter hat id, role und responsibilities
Alle Abschnitte vorhanden: Purpose, Team Composition, Coordination Pattern, Task Decomposition, Configuration, Usage Scenarios, Limitations, See Also
CONFIG-Block existiert zwischen <!-- CONFIG:START --> und <!-- CONFIG:END --> Markierungen
CONFIG-Block-YAML ist gueltig und parsebar
Alle Mitglieder-Agenten-IDs existieren in agents/_registry.yml
Lead-Agent erscheint in der Mitgliederliste
Keine zwei Mitglieder teilen dieselbe primaere Verantwortlichkeit
Team ist in teams/_registry.yml mit korrektem Pfad, Lead, Mitgliedern und Koordination aufgefuehrt
total_teams-Zaehler in der Registry ist erhoeht
npm run update-readmes wird ohne Fehler abgeschlossen
Haeufige Stolperfallen
Zu viele Mitglieder: Teams mit mehr als 5 Mitgliedern sind schwer zu koordinieren. Der Overhead des Verteilens von Aufgaben und Synthetisierens von Ergebnissen ueberwiegt den Nutzen zusaetzlicher Perspektiven. In zwei Teams aufteilen oder auf wesentliche Spezialgebiete reduzieren.
Ueberlappende Verantwortlichkeiten: Falls zwei Mitglieder beide "Code-Qualitaet pruefen", werden ihre Ergebnisse in Konflikt stehen. Jedes Mitglied muss einen klar unterschiedlichen Schwerpunktbereich haben.
Falsches Koordinationsmuster: hub-and-spoke verwenden, wenn Agenten die Ausgaben der anderen benoetigen (sollte sequential sein), oder sequential verwenden, wenn Agenten unabhaengig arbeiten koennen (sollte parallel sein).
Fehlender CONFIG-Block: Der CONFIG-Block ist kein optionaler Prosa-Schmuck. Werkzeuge lesen ihn, um Teams automatisch mit TeamCreate zu erstellen. Ohne ihn ist die Teamdatei nur menschenlesbar.
Lead-Agent nicht in der Mitgliederliste: Der Lead muss auch als Mitglied mit eigener Rolle und Verantwortlichkeiten erscheinen. Ein Lead, der nur "koordiniert" ohne substantielle Arbeit zu leisten, verschwendet einen Slot.
Verwandte Skills
create-skill - folgt demselben Meta-Muster fuer das Erstellen von SKILL.md-Dateien
create-agent - Agentendefinitionen erstellen, die als Teammitglieder dienen
commit-changes - die neue Teamdatei und Registry-Aktualisierungen committen
