tjrtm/the-team-loop

Der Team-Loop

Verwende dieses Skill, wenn zwei kooperierende Teams oder Agenten in einem Repository arbeiten. Ersetze Team A und Team B durch die konfigurierten Namen. Der Owner ist ein Mensch und die Autorität für Priorität, Merge, Deployment, Freeze und Richtlinienentscheidungen.

Onboarding: Fünf-Minuten-Setup

1. Kopiere dieses Skill in das Ziel-Repository und installiere den Adapter für das aktive Agent-Tool.
2. Kopiere templates/team-loop.yml nach .team-loop.yml; setze Teamnamen und gate_command.
3. Führe scripts/setup-labels.sh --repo OWNER/REPO aus.
4. Lasse den Owner ein gepinntes Koordinations-Issue und ein Issue mit dem Label ready erstellen.
5. Jedes Team liest diese Datei, beansprucht maximal ein Item und verwendet den konfigurierten Status-Header.

Rollen

• Owner: Erstellt oder promoted bereite Arbeit; postet direkte Owner:-Entscheidungen in eigenen Worten; autorisiert Merges und Deployments, außerhalb eines schriftlichen Mandats mit Gültigkeitsbereich und UTC-Endzeit.
• Team A / Team B: Bauen, testen, reviewen, beanspruchen, übergeben und berichten. Verwende nach Möglichkeit separate GitHub-Identitäten.
• Reviewer (optional): Führt ein Review mit frischem Kontext durch. Erforderlich für konfigurierte Risikopfade oder -kategorien.

Loop-Zustände

backlog -> ready -> in-progress -> blocked oder needs-owner -> Implementierungs-PR -> ready-for-owner -> gemergt -> deployed.

• backlog ist nicht beanspruchbar. Bündle wöchentlich niedrig priorisierte Backlog-Arbeit zur Owner-Freigabe.
• ready autorisiert Implementierung, Tests und das Öffnen eines PRs. Autorisiert niemals Merge oder Deployment.
• Beim Schließen eines Issues entferne veraltete Zustands-Labels wie in-progress, ready, blocked und needs-owner.

Claim-Protokoll

1. Lies Labels unmittelbar vor dem Handeln erneut. Beanspruche keine in-progress, blocked oder nicht-ready Arbeit.
2. Führe scripts/claim.sh --repo OWNER/REPO --issue N --team "Team A" --plan "kurzer Plan" aus.
3. Das Skript fügt in-progress und ein Team-Label hinzu, postet den Claim und prüft den Zustand erneut. Wenn es einen Wettlauf verliert, zieht es sich zurück.
4. Halte die laufende Arbeit auf oder unter wip_limit pro Team. Beende, übergib oder blockiere ein Item explizit, bevor du ein anderes beanspruchst.
5. Bei team:any gewinnt der zeitlich früheste gültige Claim-Kommentar; das andere Team zieht sich zurück. Löse keinen Gleichstand durch doppelte Implementierung.

Kommentare und Kommunikation

Jeder Team-Kommentar beginnt in seiner ersten Zeile mit:

Status: <Zustand> | Team: <konfiguriertes Team> | <kurzer Kontext>

Poste nur einen Claim mit Plan, Review-Ergebnis, Gate-Ergebnis, Übergabe, Frage, Eskalation an den Owner, Zustimmung oder Release-Bericht. Poste keine Kommentare zu gestartet, in der Warteschlange, noch warten, wieder aktiviert oder andere zeremonielle Kommentare. Halte gewöhnliche Kommentare auf fünf kurze Zeilen; platziere Belege in der PR-Beschreibung oder in zugeklappten Details.

Nur der Owner schreibt Owner:-Entscheidungen. Teams müssen verlinken oder einen direkten Owner-Kommentar anfragen, niemals einen als Autorität weiterleiten.

Labels und Weiterleitung

Verwende die Labels in reference/labels.md. Ein nicht zugewiesenes ready-Issue wird standardmäßig Team A zugewiesen, sofern die Konfiguration nichts anderes sagt. team:any ermöglicht es beiden Teams, es zu beanspruchen. Wenn du keine eigene Arbeit hast, hilf dem anderen Team in dieser Reihenfolge: angeforderte Reviews, Zug-Vorbereitung oder Rebase, dann wöchentliche Backlog-Batches. Führe keine unbegrenzte Fehlersuche ohne Owner-Anfrage durch.

Review, Zug, Gate, Zertifikat

1. Jeder PR durchläuft leichte, fokussierte Prüfungen und erhält die für sein Risiko erforderliche Review-Stufe.

2. Ein Reviewer labelt vollständige PRs mit ready-for-owner.

3. Der Zug-Ausführer sammelt die zu diesem Zeitpunkt verfügbaren reviewten PRs. Er führt aus:

   scripts/train.sh --repo OWNER/REPO --name train-YYYYMMDD-N PR_NUMMER...
   

4. train.sh fügt zu jedem enthaltenen PR train-running hinzu, zeichnet Basis- und Head-Commits auf, führt einen Konflikt-Check durch, erstellt ein temporäres Merge-Ergebnis und ruft gate.sh einmal auf.

5. gate.sh bindet das Zertifikat an git rev-parse HEAD^{tree}. Ein passendes vorhandenes Zertifikat ist gültiger Beweis, es sei denn, es wird --force verwendet.

6. Wenn sich die Basis oder ein PR-Head ändert oder der Screen/Gate fehlschlägt, ist der Zug ungültig. Entferne oder teile die problematischen PRs auf und baue den Zug neu. Führe während des train-running-Haltens keine nicht zugehörigen Arbeiten zusammen.

7. Nach direkter Owner-Genehmigung oder einem aktiven Mandat führe train.sh erneut mit --merge --owner-authorization "Owner: ..." aus, um die aufgezeichneten PR-Heads in Reihenfolge zu mergen. Es lehnt ab, wenn sich die Basis oder ein Head geändert hat, und überprüft nach jedem Merge den Tree des geschützten Branches.

Deployment, Freeze, Hold und Pause

• Deploye nur den konfigurierten geschützten Branch und nur mit einem passenden Tree-Zertifikat, es sei denn, der Owner liefert eine dokumentierte Ausnahme.
• Erstelle einen Deployment-Bericht für das Release. Label versendete PRs und Issues als deployed; verlinke sie mit dem einen Bericht, anstatt sie zu duplizieren.
• freeze stoppt neue Merges und Deployments. Behandle fehlgeschlagene Label-Lesevorgänge als eingefroren für irreversible Aktionen.
• Ein Zug-Hold blockiert Merges außerhalb dieses Zuges, bis der Zug endet.
• Bei Pause stoppe Claims, Züge, Merges und Deployments. Der Owner postet eine Neustart-Liste, die die Elemente benennt, die fortgesetzt werden dürfen. Überprüfe vor dem Neustart Labels, PR-Heads, Basis und Zertifikate erneut.

Eskalation und Mandate

Verwende needs-owner, wenn eine Produkt-, Sicherheits-, Rechts-, Release- oder mehrdeutige Zuständigkeitsentscheidung die Arbeit blockiert. Gib das beobachtete Verhalten, Optionen, Empfehlung und ggf. eine Frist an. Setze unabhängige Arbeit fort.

Ein Mandat muss seinen genauen Gültigkeitsbereich und die UTC-Ablaufzeit angeben, zum Beispiel:

Owner: Team A darf die reviewten Dokumentations-PRs 41 und 42 bis 2026-05-01T18:00:00Z mergen und deployen.

Alles außerhalb dieses Bereichs oder nach Ablauf erfordert eine frische direkte Entscheidung.

Retrospektive

Führe mindestens wöchentlich scripts/scorecard.sh aus und bespreche die Definitionen in reference/metrics.md. Verbessere jeweils einen messbaren Engpass. Überprüfe Gate-Läufe pro gemergten PR, Claim-Latenz, Zykluszeit, Nettowarteschlangenänderung, mittlere Batch-Größe, zertifizierten Anteil und Änderungsfehlerrate.

Lies reference/rules.md für die normativen nummerierten Regeln und reference/comment-templates.md, bevor du einen Status postest.