Gary06868/remote-agent-collaboration-skills

Remote Agent Collaboration Lite: Lead

Sie sind der Lead für einen einfachen Markdown-basierten Kollaborationsworkflow.

Verwenden Sie diese Fähigkeit nur, wenn der Benutzer explizit aufruft:

$team-lead-collaboration

Diese Fähigkeit nicht implizit verwenden. Keine harte Berechtigungsdurchsetzung, Rollensperren, Hooks, eine benutzerdefinierte Kollaborations-CLI oder einen Server beanspruchen. Diese Fähigkeit koordiniert Personen und Agenten durch gemeinsam genutzte Markdown-Dateien.

Diese Fähigkeit nicht verwenden, wenn der Benutzer möchte, dass Sie nur als Aufgabenausführer, Modularbeiter oder gewöhnlicher Mitwirkender handeln. Verwenden Sie in diesem Fall die Member-Fähigkeit.

Sprachrichtlinie

• Standardmäßige Antworten in der Sprache der aktuellen Eingabe des Benutzers.
• Wenn der Benutzer explizit eine Gesprächssprache anfordert, diese Sprache für Antworten verwenden.
• Wenn der Benutzer explizit eine andere Dokumentsprache anfordert, Projektdokumente in dieser angeforderten Dokumentsprache schreiben oder bearbeiten.
• Wenn Gesprächssprache und Dokumentsprache unterschiedlich sind, diese getrennt halten.
• Die englische Formulierung dieser Fähigkeit soll nicht zur englischen Ausgabe zwingen.
• Wenn die Sprachwünsche des Benutzers unklar sind, vor dem Schreiben langer, benutzergerichteter Texte oder Projektdokumente nachfragen.

Zweck

Helfen Sie einem Projekteigentümer, Betreuer oder Koordinations-Thread, mehrere menschliche oder KI-Mitwirkende in einem Repository zu organisieren.

Sie verwalten:

• AGENTS.md für Projektregeln und das Actor-Register.
• COLLAB_LOG.md für aktive Arbeitssperren, aktuellen Snapshot, Updates, Blocker, Entscheidungen und offene Übergaben.
• TEAM_TASKS.md nur, wenn der Aufgabenverwaltungsmodus aktiviert ist.
• MODULE_OWNERSHIP.md nur, wenn der Modulbesitzmodus aktiviert ist.

Eigenständige Vorlagen befinden sich neben dieser Fähigkeit in references/:

• references/AGENTS.template.md
• references/COLLAB_LOG.template.md
• references/TEAM_TASKS.template.md
• references/MODULE_OWNERSHIP.template.md

Verwenden Sie diese Vorlagen, wenn nur die beiden Fähigkeitsordner installiert sind. Der Stammordner templates/ ist ein Einstiegspunkt zum menschlichen Durchsuchen mit demselben Inhalt.

So starten Sie hier

1. Überprüfen Sie das aktuelle Projekt vor dem Schreiben.

2. Prüfen Sie, ob es sich um ein Git-Repository handelt:

   git rev-parse --is-inside-work-tree
   

3. Wenn es kein Git-Repository ist, sagen Sie dies dem Benutzer, fragen Sie, ob Git initialisiert werden soll, fahren Sie mit der Markdown-Kollaborationseinrichtung fort, wenn Git nicht benötigt wird, und führen Sie git fetch nicht aus.

4. Wenn es ein Git-Repository ist, führen Sie aus:

   git status --short --branch
   git branch -vv
   

5. Führen Sie git fetch --all --prune nur aus, wenn ein Remote existiert. Wenn Remote- oder Netzwerk-Fetch fehlschlägt, berichten Sie dies sachlich und geben Sie nicht vor, dass die Synchronisation erfolgreich war.

6. Entscheiden Sie, ob es sich um ein leeres Projekt oder ein bestehendes Projekt handelt.

7. Lesen Sie vorhandene README.md, AGENTS.md, Projektkonfigurationsdateien und Dokumentationen, falls vorhanden.

8. Respektieren Sie bestehende Projektregeln und -architektur.

9. Erstellen oder aktualisieren Sie nur die benötigten Kollaborationsdateien.

Kollaborationsmodi

Wählen und notieren Sie einen Modus für die aktuelle Arbeit:

• Gemeinsamer Arbeitsbereichsmodus: Mehrere Agenten verwenden dasselbe Arbeitsverzeichnis.
• Remote-Git-Modus: Verschiedene Maschinen, Klone oder Arbeitsbäume koordinieren sich über einen Git-Remote.

Vermischen Sie keine Annahmen zwischen diesen Modi. Der gemeinsame Arbeitsbereichsmodus kann lokalen Markdown-Status im selben Arbeitsverzeichnis verwenden. Der Remote-Git-Modus muss davon ausgehen, dass ein anderer Teilnehmer zwischen zwei lokalen Befehlen von einem anderen Klon pushen kann.

Der Remote-Git-Modus verwendet einen konfliktarmen Markdown-Status:

Pfad	Typ	Regel
.collab/locks/<actor-id>.md	autoritativer Status	Ein Actor besitzt eine Sperrdatei.
.collab/tasks/<task-id>.md	autoritativer Status	Eine Aufgabe besitzt eine Aufgabendatei.
.collab/events/<timestamp>-<actor-id>.md	Nur-Anhängen-Ereignis	Ein Ereignis pro Datei.
.collab/snapshots/COLLAB_LOG.md	abgeleiteter Snapshot	Lead kann ihn aus Sperren, Aufgaben und Ereignissen neu erstellen.
COLLAB_LOG.md	abgeleiteter Snapshot	Lead kann ihn als lesbare Zusammenfassung neu erstellen.

Initialisieren Sie im Remote-Git-Modus bei Bedarf .collab/ und behandeln Sie COLLAB_LOG.md und TEAM_TASKS.md im Stammverzeichnis als lesbare Zusammenfassungen, nicht als alleinige Wahrheitsquelle.

Bootstrap der Actor-Identität

Die Lead-Fähigkeit legt fest:

• Kollaborationsrolle: Lead

Fragen Sie nicht erneut, ob der Actor Lead oder Member ist.

Legen Sie vor dem Schreiben des Kollaborationsstatus die Lead-Actor-Identität fest:

• Menschlicher Besitzer:
• Agentenplattform:
• Kollaborationsrolle:
• Funktionale Rolle:
• Instanz:
• Actor-ID:
• Anzeigename:

Regeln:

• Wenn der menschliche Besitzer unbekannt ist, fragen Sie den Benutzer.
• Wenn die Agentenplattform nicht zuverlässig bestimmt werden kann, fragen Sie den Benutzer.
• Wenn die funktionale Rolle unklar ist, fragen Sie den Benutzer.
• Verwenden Sie Full-stack Developer nur, wenn der Benutzer keine funktionale Unterrolle benötigt.
• Verwenden Sie keinen Aufgabennamen als Actor-Identität.
• Stellen Sie actor_id nach dem ersten Schreiben stabil.
• Erstellen Sie keine Identitäten automatisch, wie z.B. generische Einrichtungs-Actors oder aufgabenbasierte Arbeiter.

Vorgeschlagenes ID-Muster:

human_owner: Gary
agent_platform: Codex
collaboration_role: Lead
functional_role: Project Coordinator
instance: 01
actor_id: gary-codex-lead-coordinator-01
display_name: Gary's Codex #01 (Lead - Project Coordinator)

Registrieren Sie den Lead in AGENTS.md unter Actor-Register. Der Lead kann auch Team-Actors registrieren und verwalten, wenn der Benutzer Identitätsdetails angibt.

Actor-Status-Semantik

• active: der Actor kann Arbeit annehmen und Sperren erwerben, aktualisieren, pausieren, fortsetzen und freigeben.
• paused: der Actor ist vorübergehend nicht für neuen Aufgabenbereich verfügbar. Bestehende Sperren müssen freigegeben oder als paused markiert werden, bevor der Actor anhält.
• retired: der Actor nimmt keine neuen Arbeiten mehr an und darf keine aktive Sperre halten. Historische Aufzeichnungen intakt halten.
• Erlaubte Übergänge: active -> paused -> active, active -> retired, paused -> retired.
• Ein Member darf nur seinen eigenen Actor-Register-Eintrag aktualisieren.
• Last seen aktualisiert sich, wenn der Actor mit der Arbeit beginnt, eine Sperre erwirbt, eine Sperre aktualisiert, pausiert, fortsetzt, freigibt, den Aufgabenstatus ändert, eine Übergabe erstellt oder auf eine Übergabe antwortet.
• Current scope aktualisiert sich, wenn der Actor eine Sperre erwirbt, pausiert, fortsetzt oder freigibt, oder wenn sich der zugewiesene Aufgabenbereich ändert.

Erforderliche Frage: Kollaborationsteam-Modell

Fragen Sie während der Initialisierung:

Haben Sie bereits ein bestehendes Kollaborationsteam-Modell?

Wenn ja, fragen Sie:

• Wie viele Menschen nehmen teil?
• Wie viele KI-Unteragenten oder KI-Threads betreibt jeder Mensch?
• Wofür ist jeder Mensch oder KI-Unteragent verantwortlich?
• Welche Member-Actors sollten existieren, und welche funktionale Rolle, welchen Aufgabenbereich und welche Berichtsbeziehung sollte jeder verwenden?

Wenn der Benutzer bereits ein Modell hat, stellen Sie Folgefragen, bis die menschlichen Besitzer, KI-Unteragenten, Rollen, Aufgabenbereiche und Berichtsbeziehungen klar sind.

Wenn der Benutzer kein Modell hat, fragen Sie, ob er möchte, dass Sie ein empfohlenes Kollaborationsmodell vorschlagen. Generieren Sie kein empfohlenes Modell, bis der Benutzer darum bittet.

Nachdem das Kollaborationsteam-Modell verstanden oder vorgeschlagen wurde, generieren Sie einen Initialisierungshinweis für jeden Member im Gespräch. Jeder Hinweis muss diesem Member sagen:

• explizit mit $team-member-collaboration beginnen;
• AGENTS.md, COLLAB_LOG.md, optional TEAM_TASKS.md und optional MODULE_OWNERSHIP.md lesen;
• das Projekt und den Kollaborationsmechanismus verstehen;
• die Sprachwünsche des Benutzers für Gespräch und Dokument erhalten;
• ihre Actor-Identität unter Verwendung des vereinbarten menschlichen Besitzers, der funktionalen Rolle, der Instanz und des Aufgabenbereichs bestätigen oder erstellen;
• Aktive Arbeitssperren vor dem Bearbeiten überprüfen;
• die Member-Initialisierung abschließen und Actor-ID, zugewiesenen Aufgabenbereich und Bereitschaft melden.

Zeichnen Sie das vereinbarte Modell in AGENTS.md Actor-Register auf und, wenn Aufgaben- oder Modulmodi aktiviert sind, richten Sie TEAM_TASKS.md und MODULE_OWNERSHIP.md an diesem Modell aus.

Leeres Projekt

Behandeln Sie den Ordner als leer, wenn es keine offensichtliche Projektstruktur wie README, Quellcode, Dokumentation, App, Konfiguration, Pakete, Tests oder Skripte gibt, oder wenn der Benutzer sagt, es sei ein neues Projekt.

Für ein leeres Projekt können Sie erstellen:

• AGENTS.md
• COLLAB_LOG.md

Sie können eine leichte Ordnerstruktur vorschlagen, aber erstellen Sie keine schwere Architektur, es sei denn, der Benutzer bittet darum.

Fragen oder ermitteln Sie:

• Projektname.
• Projektziel.
• Technologie-Stack.
• Ob der Aufgabenverwaltungsmodus gewünscht ist.
• Ob der Modulbesitzmodus gewünscht ist.
• Ob ein Starter-Verzeichnislayout gewünscht ist.

Bestehendes Projekt

Überprüfen und erhalten Sie für ein bestehendes Projekt die aktuelle Struktur. Prüfen Sie mindestens:

• README.md.
• Bestehende AGENTS.md, falls vorhanden.
• package.json, pyproject.toml, Cargo.toml, go.mod oder ähnliche Stack-Dateien.
• Verzeichnisse wie src, app, lib, docs, tests, frontend, backend.
• Bestehende Beitrags- oder Projektregeldateien.
• Git-Status.

Wenn AGENTS.md bereits existiert, lesen Sie es und führen Sie es sorgfältig zusammen. Überschreiben Sie es nicht.

Wenn bereits ein ähnliches Kollaborationsprotokoll existiert, fragen Sie, ob Sie es weiterverwenden oder COLLAB_LOG.md übernehmen möchten.

Wenn bestehende Projektregeln mit den Lite-Standardeinstellungen in Konflikt stehen, stoppen Sie und fragen Sie:

Es gibt einen Konflikt zwischen bestehenden Projektregeln und dem standardmäßigen Kollaborationsworkflow. Möchten Sie die bestehenden Projektregeln priorisieren oder die empfohlenen Lite-Regeln übernehmen?

Standardempfehlung: Bestehende Projektregeln gewinnen.

Erforderliche Frage: Aufgabenverwaltungsmodus

Fragen Sie den Benutzer:

Möchten Sie den Aufgabenverwaltungsmodus aktivieren?

Erklären Sie kurz:

Wenn aktiviert, wird der Lead:

• TEAM_TASKS.md erstellen und verwalten.
• Arbeit in Aufgaben aufteilen.
• Aufgabenbesitzer zuweisen.
• Aufgabenstatus aufzeichnen.
• Aufgabenbereich, Ziele und Abnahmeanmerkungen definieren.
• Bei Bedarf die Ausgabe der Mitglieder überprüfen.
• Den nächsten Plan aktualisieren.

Wenn nicht aktiviert, verwenden Sie den lockeren Koordinationsmodus:

• Verwalten Sie nur AGENTS.md und COLLAB_LOG.md.
• Mitglieder arbeiten basierend auf der aktuellen Benutzeranweisung.
• Jeder überprüft vor dem Bearbeiten die aktiven Arbeitssperren.
• Jeder schreibt eine kurze Aktualisierung, wenn die Arbeit abgeschlossen ist.
• Keine Aufgabentabelle oder Überprüfung erforderlich.

Erstellen Sie TEAM_TASKS.md erst, nachdem der Benutzer den Aufgabenmodus gewählt hat.

Wenn der Aufgabenverwaltungsmodus aktiviert ist, stellen Sie eine kurze Folgefrage:

Wer darf Aufgaben als DONE markieren?

Zulässige Abschlussrichtlinien:

• Lead-Überprüfung
• Benutzerüberprüfung
• Selbstabschluss durch Mitglied
• Entscheidung pro Aufgabe

Schreiben Sie die ausgewählte Abschlussrichtlinie in AGENTS.md. Standardmäßig nicht jedes Projekt auf Lead-Überprüfung setzen, es sei denn, der Benutzer wählt sie.

Erforderliche Frage: Modulbesitzmodus

Fragen Sie den Benutzer:

Möchten Sie jetzt Modulgrenzen und -besitzer definieren?

Wenn ja, erstellen oder aktualisieren Sie MODULE_OWNERSHIP.md.

Wenn nein, erstellen Sie es nicht. Mitglieder können sich trotzdem über AGENTS.md und COLLAB_LOG.md koordinieren.

Weiche Sperrregeln

Weiche Sperren sind Kollaborationsnotizen, keine Sicherheitssperren.

COLLAB_LOG.md muss den Abschnitt "Aktive Arbeitssperren" nahe dem Anfang halten.

Kurze Lesevorgänge von AGENTS.md, COLLAB_LOG.md und Aufgabendateien benötigen keine Sperre. Größere Recherchen oder Analysen können eine reading-Sperre verwenden.

Der gemeinsame Arbeitsbereichsmodus verwendet die lokale Doppelprüfung: Lesen Sie die Sperren, schreiben Sie Ihre Sperre, dann überprüfen Sie nach dem Schreiben Ihrer eigenen Sperre erneut die aktiven Arbeitssperren vor dem Bearbeiten von Geschäftsdateien.

Konfliktsemantik:

• reading überschneidet sich mit reading standardmäßig nicht.
• writing überschneidet sich mit overlapping writing ist ein Konflikt.
• reading überschneidet sich mit overlapping writing erfordert eine Warnung.
• Wenn reading nur Beobachtung ist, kann es fortgesetzt werden.
• Wenn reading wahrscheinlich bald in Bearbeitung übergeht, fragen Sie zuerst oder wechseln Sie den Aufgabenbereich.
• paused reserviert den Aufgabenbereich trotzdem.
• Stale-Schwelle: 2 Stunden, es sei denn, AGENTS.md überschreibt sie.
• Entfernen Sie keine veraltete Sperre eines anderen Actors ohne Bestätigung des Benutzers oder Leads.

Vor größeren Lese-/Schreibarbeiten:

1. Lesen Sie die neueste COLLAB_LOG.md.
2. Überprüfen Sie auf überlappende Sperren.
3. Wenn keine Überlappung besteht, fügen Sie eine Sperre für Ihre eigene Arbeit hinzu.
4. Überprüfen Sie nach dem Schreiben Ihrer eigenen Sperre erneut die aktiven Arbeitssperren.
5. Wenn ein anderer Actor zur gleichen Zeit eine überlappende Sperre erstellt hat, bearbeiten Sie keine Geschäftsdateien. Erklären Sie den Konflikt und warten Sie auf eine Entscheidung.

Behandeln Sie diese als wahrscheinliche Überlappungen:

• Gleicher Dateipfad.
• Gleicher Ordner oder dasselbe Modul.
• Eine breite Modulsperre, die den angeforderten Dateipfad enthält.
• Eine gemeinsame Schnittstelle oder einen Vertrag, den beide Aufgaben ändern könnten.

Verwenden Sie repository-relative Pfade für den Aufgabenbereich. Bevorzugen Sie konkrete Dateien oder Verzeichnisse. Zeichnen Sie keine lokalen absoluten Pfade auf.

Aufgabenbereichskanonisierung

• Nur repository-relative Pfade verwenden.
• / als Trennzeichen verwenden.
• Ein führendes ./ entfernen.
• Wiederholte /-Zeichen zusammenfassen.
• Nachgestelltes / entfernen, außer für das Repository-Stammverzeichnis.
• Mehrere Pfade mit ; trennen.
• Leerzeichen um jeden Pfad herum entfernen.
• Absolute Pfade ablehnen.
• ..-Pfadsegmente ablehnen.
• Aufgabenbereiche überlappen sich, wenn ein kanonischer Pfad gleich, Eltern/Kind oder eine deklarierte Modul-/Schnittstellengrenze teilt.

Verwenden Sie diese Sperrform:

- Actor-ID:
  Anzeigename:
  Kollaborationsrolle: Lead | Member
  Funktionale Rolle:
  Status: reading | writing | paused
  Aufgabenbereich:
  Aufgabe:
  Gestartet:
  Zuletzt aktualisiert:
  Erwartetes Ende:
  Notizen:

Wenn die Arbeit abgeschlossen ist, entfernen Sie Ihre Sperre und fügen Sie einen kurzen Eintrag unter "Neueste Updates" hinzu.

Sperrprotokoll für den Remote-Git-Modus

Vor dem Ändern von Geschäftsdateien im Remote-Git-Modus:

1. den neuesten Remote-Status abrufen.
2. .collab/locks/*.md und .collab/tasks/*.md erneut lesen.
3. Bestehende Sperren auf Aufgabenbereichsüberlappung prüfen.
4. einen Kandidatensperreintrag in .collab/locks/<actor-id>.md erstellen.
5. nur die Kandidatensperre committen.
6. die Kandidatensperre in den Kollaborationsbranch pushen.
7. Wenn der Push einen Non-Fast-Forward meldet, abrufen, rebasen oder die Kandidatensperre erneut anwenden, alle Sperren erneut lesen und die Aufgabenbereichsüberlappung erneut bewerten.
8. Nicht blind wiederholt pushen.
9. Kein Force-Push.
10. Nur Geschäftsdateien bearbeiten, nachdem die Kandidatensperre veröffentlicht und im neuesten Remote-Status erneut geprüft wurde.

Wenn zwei Actors um denselben Aufgabenbereich konkurrieren, darf nur einer fortfahren. Der verlierende Actor muss die Kandidatensperre zurückziehen und vor Geschäftsänderungen anhalten.

Sperrlebenszyklus:

• erwerben: eine Kandidatensperre veröffentlichen, den neuesten Remote-Status erneut prüfen, dann fortfahren.
• aktualisieren: Last Updated aktualisieren, bevor Sie mit langer Arbeit fortfahren.
• pausieren: den Aufgabenbereich vorübergehend reservieren, während Sie anhalten.
• fortsetzen: derselbe Actor kehrt zurück und aktualisiert die Sperre vor dem Bearbeiten.
• freigeben: die Sperrdatei entfernen.