hibeekaey/agent-sync

Zusammenarbeit zwischen Coding-Agenten koordinieren

Sie sind der Koordinator: Sie besitzen die Aufgabenbeschreibung, prüfen jedes Arbeitsergebnis und entscheiden, was als nächstes passiert. Jeder andere Agent ist ein Worker: Er erhält eine Spezifikation, erzeugt ein Artefakt und stoppt. Es gibt keine herstellerübergreifende Nachrichtenbus, daher ist die Koordination rundenbasiert und dateivermittelt:

Sie schreiben task.md -> Worker läuft headless -> Worker schreibt result.md ->
Sie lesen, prüfen, entscheiden die nächste Runde

Wenn agent-sync installiert ist, führen Sie agent sync vor der Delegierung aus, damit jeder Worker mit dem gleichen synthetisierten Gedächtnis startet, das Sie haben.

1. Aufgabenverzeichnis schreiben

task/
  task.md      # die Spezifikation (siehe Vertrag unten)
  ...inputs... # alles, was der Worker benötigt; Worker erhalten keinen anderen Kontext
  result.md    # der Worker schreibt dies; seine Existenz signalisiert Fertigstellung

task.md ist ein Auftragsangebot und muss enthalten:

• das Ziel, in einem Absatz;
• das genaue Arbeitsergebnis (eine Datei, benannt);
• eine prüfbare Definition von „erledigt“;
• die Anweisung, nach dem Schreiben des Arbeitsergebnisses zu stoppen;
• die Lock- oder Worktree-Regeln aus Abschnitt 2, wenn der Worker einen gemeinsam genutzten Baum bearbeiten wird.

2. Den Freigabemodus VOR dem Aufrufen von jemandem wählen

Regel Null: Zwei Agenten dürfen niemals gleichzeitig denselben Arbeitsbaum verändern.

Situation	Modus
Worker liest nur (Review, Analyse, Zweitmeinung)	Gleiches Verzeichnis, kein Lock
Alternierende Bearbeitungen an einem Baum	Gleiches Verzeichnis + mkdir Lock
Parallele Versuche oder parallele dateiberührende Subtasks	Ein git Worktree pro Worker
Zwei Agenten bearbeiten gleichzeitig einen Baum	Niemals; umstrukturieren

Gleich-Verzeichnis-Lock (mkdir ist atomar; fügen Sie diese Anweisungen auch in task.md ein):

until mkdir .agent-lock 2>/dev/null; do sleep 1; done   # erwerben
echo "$(whoami):$$" > .agent-lock/owner
# ... Arbeit ...
rm -rf .agent-lock                                       # freigeben

Ein Lock niemals automatisch nach Zeit verfallen lassen: Ein langsamer Worker sieht identisch zu einem toten aus. Überprüfen Sie, ob der Worker-Prozess tot ist, bevor Sie ein veraltetes Lock löschen.

Worktree-Modus: git worktree add ../task-<worker> -b agent/<worker> pro Worker, Worker pushen niemals und berühren niemals die Bäume der anderen, der Haupt-Checkout bleibt schreibgeschützt, und Sie (der Koordinator) führen alle Merges als den einen serialisierten Schritt durch.

3. Den Worker headless aufrufen

Worker	Befehl
Claude Code	claude -p "Read task.md in this directory and complete it."
Codex CLI	codex exec --skip-git-repo-check --sandbox workspace-write "Read task.md in this directory and complete it." </dev/null
Gemini CLI	gemini -p "Read task.md in this directory and complete it."

Regeln, die auf die harte Tour gelernt wurden:

• Starten Sie den Worker aus dem Aufgabenverzeichnis heraus und beschränken Sie seinen Schreibzugriff darauf.
• Schließen Sie stdin (</dev/null) für jeden im Hintergrund laufenden Worker, sonst könnte er auf Eingabe warten.
• Codex verweigert nicht vertrauenswürdige Nicht-Git-Verzeichnisse ohne --skip-git-repo-check.

4. Prüfen, dann entscheiden

• Das Wort des Workers ist nicht das Arbeitsergebnis. Lesen Sie result.md und prüfen Sie es gegen die Definition von „erledigt“; führen Sie bei Code die Tests selbst aus.
• Ein fehlendes oder falsches Arbeitsergebnis erhält eine neue Runde mit einer präziseren Spezifikation, nicht eine Wiederholung derselben.
• Sie bleiben für alles verantwortlich, was Sie akzeptieren: Überprüfen Sie die Unterschiede eines Workers wie den PR eines menschlichen Auftragnehmers.

Grenzen

• Geben Sie einem Worker niemals Anmeldeinformationen, Berechtigungen zum Bereitstellen oder Zugriff auf echte Zielgruppen; Worker produzieren Artefakte, der Koordinator (mit dem Benutzer) bringt sie aus.
• Führen Sie dieses Protokoll niemals aus, um Änderungen innerhalb eines Baums ohne Locks oder Worktrees zu parallelisieren, selbst für „schnelle“ Aufgaben.
• Der Benutzer entscheidet, welcher Agent die Koordination übernimmt; geben Sie die Koordination nicht an einen Worker ab.