netheremp/baton-pass-netheremp

Baton Pass

Zweck: Kontinuität zwischen mehreren Agenten mit minimalem Textaufwand bewahren.

Dies ist ein Low-Token-Workflow-Tool, keine Dokumentationszeremonie.

Kurzeinrichtung

Auf jedem Agenten installieren (einmal pro Maschine)

npx github:netheremp/baton-pass-netheremp install

Installiert diese Fähigkeit in ~/.claude und jedes ~/.codex*-Home. Danach:

• Claude Code (CLI + IDE) – Fähigkeit lädt automatisch; /new-game /save-state /baton-pass /foresight /dragon-dance /party-check /hindsight
• Codex CLI – Fähigkeit lädt automatisch; explizit mit $baton-pass ausführen
• Codex Desktop-App – Fähigkeit lädt automatisch; /prompts:baton-pass im Composer

Alternativen: /plugin marketplace add netheremp/baton-pass-netheremp (Claude Code) oder /plugins → installieren (Codex).

Repository für Multi-Agent-Arbeit initialisieren

npx github:netheremp/baton-pass-netheremp init

Fügen Sie --track-state hinzu, um den Übergabezustand in Git zu committen (für Teams, die eine gemeinsame Historie benötigen). Standardmäßig nur lokal (gitignoriert).

Dies erstellt:

• baton-pass.config.json – wo der Workflow Ihre Speicherdateien findet
• baton-pass.state.json – leichtgewichtiger gemeinsamer Besitzstatus
• docs/agent-handoff.md – repospezifische Regeln für alle Agenten
• docs/current-state.md – was gerade passiert
• docs/next-task.md – wer die Arbeit besitzt und was als Nächstes kommt
• docs/progress.md – fortlaufendes Sitzungsprotokoll (nur Anhängen)

init fügt auch die /move-Slash-Befehle in das .claude/commands/ des Repos ein.

Der Bewegungs-Satz

• new-game = Workflow in einem frischen Repo initialisieren
• save-state = sicher anhalten, ohne zu übergeben
• baton-pass = Arbeit übertragen, wenn Token knapp sind oder der Besitz wechselt
• foresight = Arbeit empfangen oder wieder aufnehmen, Ausrichtung prüfen, dann fortfahren
• dragon-dance = Workflow nur verbessern, wenn eine echte Lektion gelernt wurde
• party-check = prüfen, wer zuletzt gehandelt hat, wer als Nächstes handeln sollte und den aktuellen Repo-Zustand
• hindsight = die gesamte Übergabekette prüfen – beanspruchte Meilensteine, durchgeführte Verifikationen, mitgeführte Risiken, nie gelöste Punkte

Kernregel

Standardmäßig Delta, keine Zusammenfassung.

Stabile Projekthistorie nicht wiederholen, es sei denn, der Empfänger kann ohne sie nicht sicher fortfahren.

Wann welche Bewegung verwendet werden soll

new-game

Einmal zu Repo-Beginn verwenden oder wenn dieser Workflow in ein Repo eingeführt wird, das noch keine gemeinsamen Speicherdateien hat.

save-state

Verwenden, wenn:

• Sie plötzlich aufhören müssen
• Sie die Arbeit für später pausieren
• der Besitz sich noch nicht ändert

save-state ist ein lokaler Prüfpunkt, keine Übergabe.

baton-pass

Verwenden, wenn:

• Token knapp sind
• ein anderer Agent übernimmt
• Sie ein übertragbares Kontinuitätspaket benötigen

baton-pass ist ein Übergabe-Prüfpunkt.

foresight

Verwenden, wenn:

• Sie einen Stab empfangen
• Sie nach einem save-state zurückkehren
• Zweifel bestehen, dass der geschriebene Zustand noch mit dem Repo übereinstimmt

dragon-dance

Nur verwenden, wenn:

• der Workflow selbst etwas gelernt hat
• der Empfänger eine Abweichung festgestellt hat
• der Stab etwas Wichtiges ausgelassen hat
• eine neue Regel eindeutig wiederholte Verschwendung verhindern würde

dragon-dance nicht reflexartig auslösen. Nicht standardmäßig in jede Sitzung oder baton-pass aufnehmen.

party-check

Verwenden, wenn:

• Sie vergessen haben, wer an der Reihe ist
• mehrere Agenten das Repo teilen
• Sie den aktuellen Status ohne die Kosten einer vollständigen foresight möchten

party-check ist die Bewegung innerhalb der Sitzung. Von einem einfachen Terminal (kein Agent, keine Token) führen Sie baton-pass status aus – es gibt dieselbe Besitzanzeige plus die letzte Übergabekette aus, und baton-pass status --json gibt maschinenlesbare Ausgabe für Skripte und Hooks.

hindsight

Verwenden, wenn:

• ein Meilenstein oder eine große Funktion abgeschlossen ist und Sie eine saubere Aufzeichnung wünschen
• etwas sich falsch anfühlt und Sie nachverfolgen müssen, was tatsächlich beansprucht vs. getan wurde
• ein neuer Agent hinzukommt und ein vollständiges Bild der Historie benötigt, nicht nur den letzten Stab
• eine foresight schwere Abweichung festgestellt hat und Sie verstehen müssen, wie weit zurück sie begann
• das Projekt überprüft, an einen Menschen übergeben oder archiviert wird

hindsight nicht nach jedem baton-pass ausführen. Es ist ein Audit, kein routinemäßiger Prüfpunkt.

Was jede Bewegung schreiben soll

save-state

Minimale Ausgabe:

• aktuelle Aufgabe
• gestoppt bei
• berührte Dateien
• nächste sofortige Aktion
• Blockade oder Risiko

baton-pass

Minimale Ausgabe:

• Ziel
• erledigt
• Aufgaben (falls ein Aufgabenplan verwendet wird – jede Aufgabe mit Status: erledigt / in Bearbeitung / ausstehend)
• Dateien
• Arbeitsbaum (Branch-Name und Arbeitsbaum-Pfad bei Verwendung von Git-Worktrees)
• verifiziert
• Abweichungen (Entscheidungen, die während der Sitzung getroffen wurden und vom ursprünglichen Plan abweichen)
• Umgebung (Voraussetzungen, die der nächste Agent bestätigen muss: laufende Dienste, gesetzte .env-Variablen, Testdatenbanken usw.)
• als Nächstes
• Risiken
• nächster Agent

Commit-Disziplin:

• Vor der Übergabe committen oder dokumentieren, warum nicht.
• Niemals einen schmutzigen Arbeitsbaum übergeben, ohne den nicht-committeten Zustand explizit zu benennen.
• Wenn die Verifikation nicht durchgeführt wurde, dies sagen – nicht implizieren, dass sie bestanden hat.

Warum Aufgaben, Arbeitsbaum, Abweichungen und Umgebung wichtig sind: Das Sitzungsgedächtnis geht bei der Übergabe verloren. Wenn Sie mitten in einem 20-Aufgaben-Plan stecken, kann der nächste Agent aus dem Git-Log allein nicht rekonstruieren, welche Aufgaben erledigt sind – schreiben Sie den Status explizit. Wenn Sie innerhalb eines Worktrees arbeiten, benötigt der nächste Agent den genauen Pfad. Wenn Sie etwas anders als im Plan festgelegt repariert haben, schreiben Sie es auf – der nächste Agent wird den Plan erneut lesen und es falsch machen. Wenn die Umgebung in einem bestimmten Zustand sein muss (Datenbank läuft, .env befüllt), benennen Sie es – ein neuer Agent wird ohne diese Info auf dieselbe Blockade stoßen.

foresight

Minimale Ausgabe:

• ausgerichtet oder nicht
• falls nicht ausgerichtet, was war veraltet oder fehlte
• korrigierter nächster Schritt nur bei Bedarf

Wenn die Abweichung schwerwiegend ist (der Stab behauptet, Arbeit sei erledigt, aber das Repo zeigt etwas anderes), schreiben Sie vor dem Fortfahren einen strukturierten Abweichungsbericht:

• was wurde beansprucht
• was das Repo tatsächlich zeigt
• was wiederholt werden muss
• ob diese Abweichung ein dragon-dance rechtfertigt

dragon-dance

Minimale Ausgabe:

• Problem
• Auswirkung
• Verbesserung
• neue Konvention

party-check

Minimale Ausgabe:

• Zustand
• letzte Bewegung
• letzter Agent
• nächster Agent
• aktualisiert am
• kurze Zusammenfassung

hindsight

Minimale Ausgabe:

• Prüfumfang (vollständige Kette oder begrenzter Bereich)
• Tabelle der Übergabekette (von → bis, Datum, Zielzusammenfassung)
• pro Agent beanspruchte Meilensteine mit Verifikationsstatus
• Verifikationslücken (Behauptungen ohne Nachweis)
• über Stäbe hinweg mitgeführte Risiken
• über Stäbe hinweg gefundene Abweichungen
• nie gelöste offene Punkte
• Prüf-Fazit: sauber, Lücken gefunden, Risiken ungelöst oder Handlungsbedarf

Zu prüfende Quellen:

• docs/progress.md – vollständiges Sitzungsprotokoll
• docs/next-task.md – Turn-State-Verlauf
• baton-pass.state.json – programmatischer Zustand
• Git-Log – Commit-Nachrichten und -Daten
• alle im Fortschritt referenzierten gespeicherten Stab- oder save-state-Dateien

Empfangsverfahren für foresight

Nur das Mindeste prüfen, um Fehltritte zu vermeiden:

• aktuelles Benutzerziel
• Arbeitsbaumstatus
• letzte(r) Commit(s)
• current-state
• next-task
• neuester progress-Eintrag
• in gespeichertem Zustand oder Stab benannte Dateien
• Aufgabenlistenstatus, falls ein Plan in Bearbeitung war

Dann entscheiden:

• wenn ausgerichtet, fortfahren
• wenn nicht ausgerichtet, den Stab korrigieren und fortfahren
• wenn die Nichtausrichtung eine wiederverwendbare Lektion offenbart, dragon-dance ausführen

Fähigkeitserkennung über Agenten hinweg

Wenn Fähigkeiten projektlokal installiert sind (in .claude/commands/ oder per Plugin-Installation im Repo), finden Codex und andere Agenten, die das Repo übernehmen, dieselben Fähigkeitsdefinitionen. Die Fähigkeitsdateien reisen mit dem Repo.

Welche Fähigkeiten NICHT über eine Sitzungsgrenze hinweg getragen werden:

• Aufgabenstatus aus speicherinternen Aufgabenverwaltungen (TaskCreate-Listen gehen verloren, wenn die Sitzung endet)
• Ausführungsstatus von Subagenten (welche Überprüfungsschleifen abgeschlossen wurden, welche Agenten liefen)
• Umgebungsstatus (welche Dienste laufen, welche .env-Variablen gesetzt sind)

Der baton-pass muss all dies explizit schreiben. Fähigkeiten sagen Agenten, wie sie arbeiten sollen; der Stab sagt ihnen, wo die Dinge stehen.

Zustandsmodell

Verwenden Sie die gemeinsame Zustandsdatei, um nachzuverfolgen:

• aktueller Zustand
• letzte Bewegung
• letzter Agent
• nächster Agent
• aktualisierte Zeit
• Zusammenfassung

Empfohlene Zustände:

• active
• paused
• handed-off
• claimed
• blocked

Verifikationsvokabular

Verwenden Sie konsistente Sprache, damit Empfänger genau wissen, was überprüft wurde.

• passed – lokal ausgeführt, Ausgabe als sauber bestätigt
• passed outside sandbox – lokal ausgeführt, aber nicht in der CI/Build-Umgebung
• not run — [Grund] – übersprungen, Grund angeben
• expected to pass, unverified – nicht ausgeführt, aber für korrekt gehalten

Niemals passed schreiben, wenn expected to pass, unverified gemeint ist. Diese einzelne Unklarheit verursacht die meiste Nacharbeit bei Übergaben.

Turn-State

Der Turn-State-Block in next-task ist das primäre menschenlesbare Besitzsignal. baton-pass.state.json spiegelt ihn für die programmatische Nutzung wider.

Wenn Sie einen aktualisieren, aktualisieren Sie beide. Wenn sie jemals widersprechen, gewinnt next-task.

Empfohlene state-Werte in beiden:

• active – jemand arbeitet gerade
• paused – sicher gestoppt, derselbe Agent wird fortfahren
• handed-off – übertragen, warte auf Übernahme durch Empfänger
• claimed – Empfänger hat foresight ausgeführt und setzt fort
• blocked – kann nicht fortfahren, Grund sollte in next-task stehen

Anti-Patterns

Vermeiden:

• baton-pass für jeden kleinen Prüfpunkt zu verwenden
• dragon-dance zu verwenden, wenn nichts gelernt wurde
• alle Speicherdateien für triviale Arbeit neu zu schreiben
• foresight jedes Mal in ein vollständiges Repo-Audit zu verwandeln
• hindsight nach jedem baton-pass auszuführen – es ist ein Audit, kein routinemäßiger Schritt
• das gesamte Projekt statt des Deltas neu darzustellen
• passed zu schreiben, wenn expected to pass, unverified gemeint ist
• einen schmutzigen Arbeitsbaum zu übergeben, ohne den nicht-committeten Zustand zu benennen
• den Aufgabenstatus wegzulassen, wenn man mitten in einem nummerierten Plan steckt
• den Arbeitsbaumpfad wegzulassen, wenn die Arbeit innerhalb eines Git-Worktrees stattfindet
• Umgebungsvoraussetzungen wegzulassen, die ein neuer Agent nicht kennen würde

Bester praktischer Ablauf

Pausieren:

• save-state
• später foresight

Übertragen:

• baton-pass
• Empfänger führt foresight aus

Verbessern:

• dragon-dance nur, wenn foresight ein bedeutendes Workflow-Problem aufgedeckt hat

Besitz prüfen:

• party-check

Gesamtkette auditieren:

• hindsight
• falls Lücken oder ungelöste Risiken gefunden werden, dragon-dance ausführen