Agent-almanac test-team-coordination

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/de/skills/test-team-coordination" ~/.claude/skills/pjt222-agent-almanac-test-team-coordination-c282a6 && rm -rf "$T"

manifest: i18n/de/skills/test-team-coordination/SKILL.md

source content

Team-Koordination testen

Ein Testszenario aus

tests/scenarios/teams/

gegen das Zielteam ausfuehren. Koordinationsmuster-Verhaltensweisen beobachten, Akzeptanzkriterien bewerten, das Rubrik-Ergebnis ermitteln und eine

RESULT.md

tests/results/

erzeugen.

Wann verwenden

Validierung, dass das Koordinationsmuster eines Teams erwartete Verhaltensweisen zeigt
Ausfuehren eines strukturierten Tests nach Aenderung einer Team-Definition oder eines Agents
Vergleich von Koordinationsmustern durch Ausfuehren desselben Szenarios mit verschiedenen Teams
Einrichten von Basislinie-Leistungsmetriken fuer eine Teamzusammensetzung
Regressions-Tests nach Hinzufuegen neuer Agents oder Aenderung der Team-Mitgliedschaft

Eingaben

Erforderlich: Pfad zur Testszenario-Datei (z. B.

tests/scenarios/teams/test-opaque-team-cartographers-audit.md

)

Optional: Ausfuehrungs-ID-Ueberschreibung (Standard:
```
YYYY-MM-DD-<target>-NNN
```
automatisch generiert)
Optional: Team-Groessen-Ueberschreibung (Standard: aus Szenario-Frontmatter)
Optional: Umfangsaenderung ueberspringen (Standard: false — Umfangsaenderung injizieren wenn definiert)

Vorgehensweise

Schritt 1: Testszenario laden und validieren

1.1. Die im Input angegebene Testszenario-Datei lesen.

1.2. YAML-Frontmatter parsen und extrahieren:

```
target
```
— das zu testende Team
```
coordination-pattern
```
— das erwartete Muster
```
team-size
```
— Anzahl der zu startenden Mitglieder
Akzeptanzkriterien-Tabelle
Bewertungsrubrik (falls vorhanden)
Ground-Truth-Daten (falls vorhanden)

1.3. Verifizieren, dass die Szenario-Datei alle erforderlichen Abschnitte hat:

Objective (Ziel)
Pre-conditions (Vorbedingungen)
Task (mit Primary-Task-Unterabschnitt)
Expected Behaviors (Erwartete Verhaltensweisen)
Acceptance Criteria (Akzeptanzkriterien)
Observation Protocol (Beobachtungsprotokoll)

Erwartet: Szenario-Datei laed, wird geparst und enthaelt alle erforderlichen Abschnitte.

Bei Fehler: Wenn die Datei fehlt oder nicht parsebar ist, mit einer Fehlermeldung abbrechen, die die fehlende Datei oder den fehlerhaften Abschnitt identifiziert. Wenn optionale Abschnitte (Rubrik, Ground Truth, Varianten) fehlen, deren Fehlen vermerken und fortfahren.

Schritt 2: Vorbedingungen verifizieren

2.1. Jede Vorbedingungs-Checkbox im Szenario durchgehen.

2.2. Fuer Datei-Existenz-Pruefungen Glob zur Verifizierung verwenden.

2.3. Fuer Registry-Anzahl-Pruefungen die relevante

_registry.yml

parsen und

total_*

gegen tatsaechliche Dateianzahlen auf dem Datentraeger vergleichen.

2.4. Fuer Branch-/Git-Zustand-Pruefungen

git status --porcelain

und

git branch --show-current

ausfuehren.

Erwartet: Alle Vorbedingungen sind erfuellt.

Bei Fehler: Wenn eine Vorbedingung fehlschlaegt, als BLOCKED in den Ergebnissen festhalten. Entscheiden ob fortgefahren werden soll (weiche Vorbedingung) oder abgebrochen werden soll (harte Vorbedingung wie fehlende Ziel-Team-Datei). Die Entscheidung dokumentieren.

Schritt 3: Koordinationsmuster-Kriterien laden

3.1.

tests/_registry.yml

lesen und den

coordination_patterns

-Eintrag finden, der dem

coordination-pattern

-Wert des Szenarios entspricht.

3.2. Die

key_behaviors

-Liste fuer dieses Muster extrahieren.

3.3. Diese Verhaltensweisen werden zur Beobachtungs-Checkliste — jede muss waehrend der Ausfuehrung beobachtet und als beobachtet/nicht beobachtet festgehalten werden.

Erwartet: Muster-Schluesselverhaltensweisen geladen und bereit zur Beobachtung.

Bei Fehler: Wenn das Koordinationsmuster nicht in der Registry definiert ist, den Abschnitt Expected Behaviors des Szenarios als alleinige Beobachtungsquelle verwenden. Eine Warnung protokollieren.

Schritt 4: Aufgabe ausfuehren

4.1. Das Ergebnisverzeichnis erstellen:

tests/results/YYYY-MM-DD-<target>-NNN/

4.2. T0 (Aufgaben-Startzeit) festhalten.

4.3. Das Zielteam mit TeamCreate und der Team-Groesse aus dem Szenario starten. Den Primary-Task-Prompt wortwortlich aus dem Task-Abschnitt des Szenarios uebergeben.

4.4. Die Ausfuehrungsphasen des Teams beobachten. Zeitstempel festhalten fuer:

T1: Formausschreibung / Aufgabenzerlegung abgeschlossen
T2: Rollenzuweisungen sichtbar

4.5. Wenn das Szenario einen Scope-Change-Trigger definiert und skip-scope-change false ist:

Warten bis Phase 2 (Rollenzuweisung) sichtbar ist
T3 (Zeitstempel der Umfangsaenderungs-Injektion) festhalten
Den Umfangsaenderungs-Prompt per SendMessage an das Team senden
T4 (Umfangsaenderung absorbiert — Rollenanpassung sichtbar) festhalten

4.6. Beobachtung fortsetzen bis das Team seine Ausgabe liefert.

T5 (Integration beginnt) festhalten
T6 (Abschlussbericht geliefert) festhalten

4.7. Die vollstaendige Ausgabe des Teams erfassen.

Erwartet: Team fuehrt die Aufgabe durch seine Koordinationsmuster-Phasen aus. Zeitstempel fuer alle Uebergaenge festgehalten. Umfangsaenderung (falls zutreffend) injiziert und absorbiert.

Bei Fehler: Wenn das Team keine Ausgabe erzeugt, den Fehlerpunkt und alle Fehlermeldungen festhalten. Wenn das Team ins Stocken geraet, die zuletzt beobachtete Phase und Zeitueberschreitung vermerken. Mit partiellen Ergebnissen zur Bewertung fortfahren.

Schritt 5: Muster-Verhaltensweisen bewerten

5.1. Fuer jede Schluesselverhalten aus Schritt 3 bestimmen, ob sie waehrend der Ausfuehrung beobachtet wurde:

Beobachtet: Klare Beweise in Ausgabe oder Koordination des Teams
Teilweise: Einige Beweise, aber unvollstaendig oder mehrdeutig
Nicht beobachtet: Kein Nachweis

5.2. Fuer jedes aufgabenspezifische Verhalten aus dem Expected-Behaviors-Abschnitt des Szenarios dieselbe Bewertung anwenden.

5.3. Befunde im Beobachtungsprotokoll festhalten.

Erwartet: Alle oder die meisten muster- und aufgabenspezifischen Verhaltensweisen werden beobachtet.

Bei Fehler: Nicht beobachtete Verhaltensweisen sind Befunde, keine Fehler des Test-Verfahrens. Sie genau festhalten — sie zeigen an, dass das Koordinationsmuster sich nicht vollstaendig manifestiert hat.

Schritt 6: Akzeptanzkriterien bewerten

6.1. Jedes Akzeptanzkriterium aus dem Szenario durchgehen.

6.2. Fuer jedes Kriterium eine Bestimmung zuweisen:

PASS: Kriterium klar erfuellt mit beobachtbaren Nachweisen
PARTIAL: Kriterium teilweise erfuellt (zaehlt mit 0,5-Gewichtung zum Schwellenwert)
FAIL: Kriterium nicht erfuellt trotz Gelegenheit
BLOCKED: Konnte nicht bewertet werden (Vorbedingungsversagen, Team-Zeitueberschreitung usw.)

6.3. Wenn das Szenario Ground-Truth-Daten enthaelt, gemeldete Befunde dagegen verifizieren:

Genauigkeitsprozentsaetze pro Kategorie berechnen
Falsch-Positive und Falsch-Negative markieren

6.4. Wenn das Szenario eine Bewertungsrubrik enthaelt, jede Dimension 1-5 mit kurzer Begruendung bewerten.

6.5. Zusammenfassungsmetriken berechnen:

Akzeptanz: X/N Kriterien bestanden (PARTIAL zaehlt als 0,5)
Schwellenwert: PASS wenn >= im Szenario definierter Schwellenwert
Rubrik-Gesamt: X/Y Punkte (falls zutreffend)

Erwartet: Alle Akzeptanzkriterien haben eine Bestimmung. Zusammenfassungsmetriken sind berechnet.

Bei Fehler: Wenn weniger als die Haelfte der Kriterien bewertet werden kann (zu viele BLOCKED), ist der Testlauf nicht schlussfolgerungsfaehig. Dokumentieren warum und erneuten Durchlauf nach Beheben der Vorbedingungen empfehlen.

Schritt 7: RESULT.md erzeugen

7.1.

tests/results/YYYY-MM-DD-<target>-NNN/RESULT.md

mit der Aufzeichnungsvorlage aus dem Beobachtungsprotokoll des Szenarios erstellen.

7.2. Alle Abschnitte befuellen:

Ausfuehrungs-Metadaten (Beobachter, Zeitstempel, Dauer)
Phasenprotokoll mit allen festgehaltenen Zeitstempeln
Rollenentstehungs-Protokoll (fuer adaptive/Team-Tests)
Ergebnistabelle der Akzeptanzkriterien
Rubrik-Punkte-Tabelle (falls zutreffend)
Ground-Truth-Verifikationstabelle (falls zutreffend)
Schluessbeobachtungen (narrativ)
Gelernte Lektionen

7.3. Die Rohausgabe des Teams als Anhang oder in einer separaten Datei (

team-output.md

) im selben Ergebnisverzeichnis einschliessen.

7.4. Zusammenfassungs-Urteil oben hinzufuegen:

**Urteil**: PASS | FAIL | INCONCLUSIVE
**Ergebnis**: X/N Kriterien (Y/Z Rubrik-Punkte)
**Dauer**: Xm

Erwartet: Vollstaendige RESULT.md mit allen befuellten Abschnitten und einem klaren Urteil.

Bei Fehler: Wenn die Ergebnisdatei nicht geschrieben werden kann, die Ergebnisse als Fallback nach stdout ausgeben. Die Bewertungsdaten sollten niemals verloren gehen.

Validierung

Haeufige Stolperfallen

Ausgabequalitaet statt Koordination bewerten: Dieser Skill testet wie das Team koordiniert, nicht ob die Aufgabenausgabe perfekt ist. Ein Team, das gut koordiniert, aber nur 7/9 defekte Referenzen findet, demonstriert trotzdem das Muster.
Umfangsaenderung zu frueh injizieren: Warten, bis Rollenzuweisung klar sichtbar ist, bevor die Umfangsaenderung injiziert wird. Zu frueh bedeutet, dass das Team sich noch nicht differenziert hat, daher gibt es nichts anzupassen.
Team-Mitglieder-Ausgabe mit Team-Ausgabe verwechseln: Das opake Team sollte eine einheitliche Ausgabe praesentieren. Wenn individuelle Mitglieder-Berichte zu sehen sind, ist das ein Befund ueber Opazitaet, kein Test-Infrastruktur-Problem.
Exaktes Ground-Truth-Matching: Ground-Truth-Zaehlen sind ungefaehr. Bewerten, ob Befunde in der richtigen Groessenordnung sind, nicht ob sie exakt uebereinstimmen.
Zeitstempel nicht festhalten: Zeitstempel sind fuer die Messung von Phasendauern und Anpassungsgeschwindigkeit unverzichtbar. Sie als Ereignisse festhalten, nicht rueckwirkend.