Entwickelt eine bestehende Teamzusammensetzung weiter, indem ihre Struktur direkt verfeinert oder eine spezialisierte Variante erstellt wird. Behandelt die Bewertung des aktuellen Teams anhand von Vorlage und Koordinationsmustern, das Sammeln von Weiterentwicklungsanforderungen, die Wahl des Umfangs (Mitglieder anpassen, Koordinationsmuster aendern, Teams aufteilen/zusammenfuehren), das Anwenden von Aenderungen an Teamdatei und CONFIG-Block, das Aktualisieren von Versions-Metadaten sowie die Synchronisierung der Registry und Querverweise. Verwenden wenn das Mitglieder-Roster eines Teams veraltet ist, das Koordinationsmuster nicht mehr passt, Nutzer-Feedback Workflow-Luecken zeigt, eine spezialisierte Variante benoetigt wird, oder Agenten der Bibliothek hinzugefuegt oder entfernt wurden.
Ein Team verbessern, umstrukturieren oder eine spezialisierte Variante eines Teams erstellen, das urspruenglich mit create-team verfasst wurde. Dieses Verfahren behandelt die Wartungsseite des Team-Lebenszyklus: Luecken anhand der Vorlage und der Koordinationsmuster bewerten, gezielte Verbesserungen an Zusammensetzung und Workflow anwenden, Versionen erhoehen und Registry sowie Querverweise synchron halten.
r-package-review und r-package-review-security-focused)teams/r-package-review.md)Die bestehende Teamdatei lesen und jeden Abschnitt gegen die Teamvorlage (teams/_template.md) bewerten:
| Abschnitt | Was pruefen | Haeufige Probleme |
|---|---|---|
| Frontmatter | Alle Pflichtfelder (name, description, lead, version, author, coordination, members[]) | Fehlende tags, veraltete version, falsches coordination |
| Zweck | Klare Multi-Agenten-Begruendung (mindestens zwei unterschiedliche Spezialgebiete) | Koennte von einem einzelnen Agenten erledigt werden |
| Teamzusammensetzung | Tabelle stimmt mit Frontmatter-Mitgliedern ueberein, keine ueberlappenden Verantwortlichkeiten | Veraltete Tabelle, duplizierte Schwerpunkte |
| Koordinationsmuster | Stimmt mit tatsaechlichem Workflow ueberein, ASCII-Diagramm vorhanden | Falsches Muster fuer den Workflow |
| Aufgabenzerlegung | Phasengliederung mit konkreten Aufgaben pro Mitglied | Vage Aufgaben, fehlende Phasen |
| CONFIG-Block | Gueltiges YAML zwischen Markierungen, stimmt mit Frontmatter und Prosa ueberein | Nicht synchron, fehlendes blocked_by, ungueltiges YAML |
| Verwendungsszenarien | 2-3 realistische Aktivierungsaufforderungen | Platzhaltertext |
| Einschraenkungen | 3-5 ehrliche Beschraenkungen | Fehlend oder zu generisch |
| Siehe auch | Gueltige Links zu Mitglieder-Agenten, verwandten Teams, Leitfaeden | Veraltete Links |
# Teamdatei lesen
cat teams/<team-name>.md
# Pruefen ob alle Mitglieder-Agenten noch existieren
grep "id:" teams/<team-name>.md | while read line; do
agent=$(echo "$line" | grep -oP '(?<=id: )[\w-]+')
grep "id: $agent" agents/_registry.yml || echo "MISSING: $agent"
done
# Pruefen ob das Team von einem Leitfaden referenziert wird
grep -r "<team-name>" guides/*.md
Erwartet: Eine Liste spezifischer Luecken, Schwachstellen oder Verbesserungsmoeglichkeiten, nach Abschnitt geordnet.
Bei Fehler: Falls die Teamdatei nicht existiert oder kein Frontmatter hat, ist dieser Skill nicht anwendbar — stattdessen create-team verwenden, um sie von Grund auf zu erstellen.
Identifizieren und kategorisieren, was die Weiterentwicklung ausgeloest hat:
| Ausloser | Beispiel | Typischer Umfang |
|---|---|---|
| Nutzer-Feedback | "Reviews dauern zu lang, Agenten duplizieren Aufwand" | Verantwortlichkeiten schaerfen oder Muster aendern |
| Neuer Agent verfuegbar | Agent api-security-analyst wurde erstellt | Mitglied hinzufuegen |
| Agent weiterentwickelt | code-reviewer hat neue Skills bekommen | Mitglieder-Verantwortlichkeiten aktualisieren |
| Agent entfernt | deprecated-agent wurde eingestellt | Mitglied entfernen, Aufgaben neu zuweisen |
| Koordinationsfehler | Sequenzielles Team hat unabhaengige Teilaufgaben | Auf parallel wechseln |
| Umfangserweiterung | Team muss auch Deployment abdecken, nicht nur Review | Mitglied hinzufuegen oder Variante erstellen |
| Team zu gross | 6+ Mitglieder verursachen Koordinationsaufwand | In zwei Teams aufteilen |
| Team zu klein | Einzelnes Mitglied erledigt den Grossteil der Arbeit | Mit anderem Team zusammenfuehren oder Mitglieder hinzufuegen |
Die spezifischen Aenderungen vor der Bearbeitung dokumentieren:
- Frontmatter: neues Mitglied `api-security-analyst` mit Rolle "API Security Reviewer" hinzufuegen
- Teamzusammensetzung: Zeile zur Zusammensetzungstabelle hinzufuegen
- Aufgabenzerlegung: API-Sicherheits-Review-Aufgaben zur Ausfuehrungsphase hinzufuegen
- CONFIG-Block: Mitglieds- und Aufgabeneintraege hinzufuegen
- Siehe auch: Link zur neuen Agentendatei hinzufuegen
Erwartet: Eine konkrete Liste von Aenderungen, jede einem spezifischen Abschnitt der Teamdatei zugeordnet.
Bei Fehler: Falls die Aenderungen unklar sind, den Benutzer um Klaerung bitten, bevor fortgefahren wird.
Diese Entscheidungsmatrix verwenden, um zu bestimmen, ob direkt verfeinert oder eine Variante erstellt werden soll:
| Kriterium | Verfeinerung (direkt) | Spezialisierte Variante (neues Team) |
|---|---|---|
| Team-ID | Unveraendert | Neue ID: <team>-<specialty> |
| Dateipfad | Dieselbe .md-Datei | Neue Datei in teams/ |
| Versions-Bump | Patch oder Minor | Beginnt bei 1.0.0 |
| Koordination | Kann sich aendern | Kann vom Original abweichen |
| Registry | Bestehenden Eintrag aktualisieren | Neuer Eintrag hinzugefuegt |
| Urspruengliches Team | Direkt modifiziert | Unveraendert, erhaelt Querverweise in Siehe-auch |
Verfeinerung: Waehlen beim Anpassen von Mitgliedern, Schaerfen von Verantwortlichkeiten, Beheben des CONFIG-Blocks oder Aendern des Koordinationsmusters. Das Team behaelt seine Identitaet.
Variante: Waehlen wenn die weiterentwickelte Version einem wesentlich anderen Anwendungsfall dient, ein anderes Koordinationsmuster erfordert oder eine andere Zielgruppe anspricht. Das Original bleibt fuer seinen bestehenden Anwendungsfall unveraendert.
Zusaetzliche Umfangsentscheidungen:
| Situation | Massnahme |
|---|---|
| Team hat 6+ Mitglieder und ist langsam | In zwei fokussierte Teams aufteilen |
| Zwei Teams mit je 2 Mitgliedern decken angrenzende Domains ab | In ein Team mit 3-4 Mitgliedern zusammenfuehren |
| Das Koordinationsmuster des Teams ist falsch | Verfeinerung — Muster direkt aendern |
| Team braucht voellig anderen Lead | Verfeinerung wenn Lead existiert; zuerst Agenten erstellen wenn nicht |
Erwartet: Eine klare Entscheidung — Verfeinerung, Variante, Aufteilen oder Zusammenfuehren — mit Begruendung.
Bei Fehler: Im Zweifel Verfeinerung verwenden. Aufteilen oder Zusammenfuehren hat groessere Auswirkungen und sollte mit dem Benutzer bestaetigt werden.
Die bestehende Teamdatei direkt bearbeiten. Konsistenz ueber alle Abschnitte hinweg wahren, die die Teamzusammensetzung referenzieren:
members[]: Mitgliedereintraege hinzufuegen, entfernen oder aktualisieren (jeweils mit id, role, responsibilities)members- und tasks-Listen aktualisieren (siehe Schritt 5)Diese Bearbeitungsregeln befolgen:
grep "id: agent-name" agents/_registry.yml# Original als Ausgangspunkt kopieren
cp teams/<team-name>.md teams/<team-name>-<specialty>.md
# Variante bearbeiten:
# - `name` in `<team-name>-<specialty>` aendern
# - `description` aktualisieren um spezialisierten Umfang widerzuspiegeln
# - `coordination`-Muster bei Bedarf anpassen
# - `version` auf "1.0.0" zuruecksetzen
# - Mitglieder, Aufgaben und CONFIG-Block fuer spezialisierten Anwendungsfall anpassen
# - Original in Siehe-auch als Allzweck-Alternative referenzieren
Erwartet: Die Teamdatei (verfeinert oder neue Variante) besteht die Bewertungscheckliste aus Schritt 1, mit intern konsistenten Abschnitten.
Bei Fehler: Falls eine Bearbeitung interne Konsistenz bricht (z.B. CONFIG-Block listet ein Mitglied auf, das nicht im Frontmatter steht), das Frontmatter members[] mit der Teamzusammensetzungs-Tabelle, Aufgabenzerlegung und CONFIG-Block vergleichen, um die Diskrepanz zu finden.
Der CONFIG-Block zwischen <!-- CONFIG:START --> und <!-- CONFIG:END --> muss mit den Prosa-Abschnitten synchron bleiben. Nach jeder Mitglieds- oder Aufgabenaenderung:
agent in CONFIG members einem Mitglied im Frontmatter entsprichtassignee in CONFIG tasks einer Mitglieds-Agenten-ID entsprichtblocked_by-Abhaengigkeiten aktualisieren, falls sich die Aufgabenreihenfolge geaendert hat