Ein Claude-Code-Plugin, das den Arbeitsstand zwischen mehreren Personen teilt, die am selben Repository arbeiten — jede in ihrer eigenen Session.
Wer zu mehreren mit Claude Code an einem Repo arbeitet, kennt beide Probleme: Jede neue Session fängt bei null an, Architekturentscheidungen und Konventionen müssen ständig neu erklärt werden. Und keine Session weiß, was die anderen gerade tun. team-sync legt dafür einen geteilten, laufend aktualisierten Wissensstand in dasselbe Git-Repository, auf einen eigenen Branch.
Kein zentraler Server, keine geteilte KI-Nutzung. Jede Person nutzt weiterhin ihre eigene Claude-Code-Session mit ihrer eigenen Membership. Das Plugin schiebt nur Textdateien über git hin und her.
Neben dem Projektordner liegt ein zweiter Checkout desselben Repos auf
dem Branch team-channel, als git worktree:
projekte/
├── mein-projekt/ ← hier arbeitest du
└── mein-projekt-channel/ ← Branch team-channel, vom Plugin gepflegt
├── status/ eine Datei pro Person
├── questions/ eine Datei pro Frage
├── decisions/ eine Datei pro Entscheidung
└── reservierungen/ wer sitzt gerade an welcher Datei
Beim Sessionstart liest ein Hook den Channel und gibt drei Dinge in die Session: offene Fragen an dich, woran die anderen zuletzt gearbeitet haben, und die zuletzt getroffenen Entscheidungen.
Währenddessen passieren drei Dinge automatisch:
- Vor jedem Edit wird geprüft, ob gerade jemand anders an derselben Datei sitzt. Wenn ja, gibt es einen Hinweis — blockiert wird nie.
- Beim ersten Zugriff auf eine Datei wird sie für dich reserviert, damit die anderen dasselbe sehen.
- Alle paar Minuten meldet das Plugin, was im Channel neu dazugekommen ist: beantwortete Anfragen, neue Fragen an dich, neue Festlegungen.
Beim Sessionende wird ein letzter Stand geschrieben und alle deine Reservierungen werden freigegeben.
Jede Person, jede Frage und jede Entscheidung ist eine eigene Datei. Dadurch entstehen praktisch nie Merge-Konflikte, auch wenn drei Leute gleichzeitig pushen.
SessionEnd feuert erst, wenn eine Session wirklich endet. Wer morgens
eine Session öffnet und bis mittags durcharbeitet, stünde im Channel den
ganzen Vormittag mit dem Stand von gestern — und würde von den anderen in
dieser Zeit nichts erfahren.
Bei langen, autonom laufenden Sessions ist der Empfänger einer Meldung ohnehin nicht der Mensch vor dem Bildschirm, sondern Claude selbst. Genau deshalb sind die Meldungen als Handlungsanweisungen formuliert und nicht als Rückfragen: Es ist niemand da, der antworten könnte.
Warten kostet genau die Zeit, die das Werkzeug sparen soll. Deshalb wartet niemand:
14:32 Session A fasst auth.py an → Reservierung
14:51 Session B will an dieselbe Datei
→ Hinweis, B legt eine Anfrage ab und macht mit etwas anderem weiter
14:53 A sieht die Anfrage und antwortet: "Ich bin nur in verify_token"
14:56 B sieht die Antwort und arbeitet an der richtigen Stelle weiter
Bleibt eine Antwort aus — weil die andere Session längst geschlossen ist — gilt die Datei nach zehn Minuten als frei.
Reservierungen auf verschiedenen Branches ergeben nur einen knappen Hinweis. Dort löst git den Konflikt später ohnehin, und eine Warnung, die zu oft danebenliegt, wird nach dem dritten Mal überlesen.
In Claude Code:
/plugin marketplace add oasis4/team-sync
/plugin install team-sync@team-sync-marketplace
Einmal pro Person und Projekt. Das Setup-Skript hängt nicht am Plugin, es braucht nur git — am einfachsten aus einem Klon dieses Repos, im Projekt-Repo ausgeführt:
git clone https://github.com/oasis4/team-sync.git ~/werkzeuge/team-synccd /pfad/zu/deinem/projekt && python3 ~/werkzeuge/team-sync/scripts/setup_channel.pyDie erste Person legt damit den Branch team-channel an, alle weiteren
checken ihn nur noch aus. Danach läuft alles automatisch.
Prüfen, ob es sitzt:
python3 ~/werkzeuge/team-sync/scripts/team_sync.py doctorWer lieber das installierte Plugin nutzt: Es liegt unter
~/.claude/plugins/marketplaces/, der genaue Ordnername steht in
~/.claude/plugins/installed_plugins.json.
- Python 3.9 oder neuer, als
python3aufrufbar - git 2.5 oder neuer
- Ein gemeinsames Remote, auf das alle pushen dürfen
Keine Pakete zu installieren, das Plugin nutzt nur die Standardbibliothek.
Heißt der Python-Befehl bei dir python statt python3, passe die drei
Zeilen in hooks/hooks.json entsprechend an.
| Command | Wofür |
|---|---|
/team |
Wer arbeitet gerade woran, was ist offen |
/ask max wie läuft die Session-Verwaltung im Frontend |
Frage für Max hinterlegen |
/answer |
Offene Fragen an dich durchgehen und beantworten |
/decide JWT statt Server-Session |
Entscheidung mit Begründung protokollieren |
/sync |
Sofort einen selbst formulierten Stand pushen |
Reservierungen laufen ohne Zutun. Wer sie von Hand ansehen oder aufheben will:
python3 ~/werkzeuge/team-sync/scripts/team_sync.py reservierungenpython3 ~/werkzeuge/team-sync/scripts/team_sync.py freigeben --alleDer Unterschied zwischen /sync und dem automatischen Zwischenstand ist
der Punkt: Das Hintergrundskript kennt nur die letzte Nachricht und die
Liste angefasster Dateien. Bei /sync schreibt Claude die
Zusammenfassung aus dem vollen Sessionkontext — was fertig ist, was
halbfertig, was als Nächstes kommt. Sinnvoll, wenn gerade ein größerer
Schritt fertig geworden ist.
Alles im Channel sind normale Markdown-Dateien. Sie lassen sich von Hand
bearbeiten, im Editor lesen und auf GitHub im Branch team-channel
ansehen.
Alles optional, per Umgebungsvariable:
| Variable | Vorgabe | Wirkung |
|---|---|---|
TEAM_AGENT_NAME |
git config user.name |
Eigener Name im Channel |
TEAM_SYNC_CHECKPOINT_SECONDS |
600 |
Abstand der automatischen Zwischenstände |
TEAM_SYNC_EMPFANG_SECONDS |
120 |
Wie oft nach Neuem im Channel gesehen wird |
TEAM_SYNC_RESERVIERUNG_STUNDEN |
4 |
Wie lange eine Reservierung gilt |
TEAM_SYNC_ANFRAGE_TIMEOUT |
10 |
Minuten, bis eine unbeantwortete Anfrage aufgegeben wird |
TEAM_SYNC_ANFRAGE_SPERRE |
60 |
Minuten, bis zu derselben Datei erneut gefragt werden darf |
TEAM_SYNC_CHANNEL_DIR |
Worktree bzw. <projekt>-channel |
Anderer Ort für den Channel |
TEAM_SYNC_BRANCH |
team-channel |
Anderer Branchname |
TEAM_SYNC_STALE_HOURS |
48 |
Ab wann ein Status als veraltet gilt |
TEAM_SYNC_MAX_STATUS |
5 |
Wie viele fremde Stände in den Sessionkontext kommen |
TEAM_SYNC_MAX_DECISIONS |
5 |
Wie viele Entscheidungen in den Sessionkontext kommen |
TEAM_SYNC_MAX_QUESTIONS |
5 |
Wie viele offene Fragen in den Sessionkontext kommen |
TEAM_SYNC_MAX_STATUS_CHARS |
700 |
Maximale Länge eines fremden Standes im Kontext |
TEAM_SYNC_MAX_FILES |
12 |
Wie viele Dateien ein Status auflistet |
TEAM_SYNC_CACHE_SECONDS |
60 |
Gültigkeit des internen Cache für Name und Branch |
TEAM_SYNC_FORCE |
– | Auf 1 gesetzt umgeht der Zwischenstand die Drosselung. Zum Ausprobieren gedacht, nicht für den Dauerbetrieb. |
Die MAX_-Werte begrenzen, was bei jedem Sessionstart an Tokens anfällt.
Wächst der Channel über Monate, wächst der Kontext nicht mit.
Die drei wichtigsten Stellschrauben im Alltag sind
TEAM_SYNC_EMPFANG_SECONDS (wie schnell ihr voneinander erfahrt),
TEAM_SYNC_RESERVIERUNG_STUNDEN (zu lang erzeugt Fehlalarme, zu kurz
verpasst Kollisionen) und TEAM_SYNC_ANFRAGE_TIMEOUT.
Kein Echtzeit-Chat. Zwei Sessions stimmen sich über git ab, nicht über eine Leitung. Zwischen Frage und Antwort liegen typischerweise ein paar Minuten. Das reicht für den Fall, um den es geht — „A sitzt seit zwanzig Minuten an dieser Datei" — und nicht für „beide greifen in derselben Sekunde zu". Letzteres soll es auch nicht abfangen.
Kein Blockieren. Der Hinweis vor einem Edit verweigert nichts, er informiert. Ein Hook, der zu oft verweigert, bringt eine autonom laufende Session stundenlang unbemerkt zum Stehen — das wäre schlimmer als die doppelte Arbeit, die er verhindern soll.
Keine KI-Zusammenfassung im Hintergrund. Der automatische Status wird
aus dem Transkript zusammengesetzt, ohne zusätzlichen Modellaufruf. Jede
Person bezahlt ihr Kontingent selbst, und ein Hintergrundskript, das
ungefragt davon abzwackt, wäre ein schlechter Tausch für eine
Statuszeile. Wer eine echte Zusammenfassung will, nimmt /sync.
Keine automatische Schnittstellendokumentation. Ein contracts/
Ordner für API-Verträge war geplant, ist aber bewusst zurückgestellt,
bis sich der Rest im Alltag bewährt hat.
Kein Erzwingen. Die Hooks informieren, sie verhindern nicht, dass zwei Leute dieselbe Datei anfassen. Das bleibt Teamsache — das Werkzeug macht nur wahrscheinlicher, dass es rechtzeitig auffällt.
- Woche 1: Zu dritt nur mit
status/undquestions/arbeiten. Das ist der Teil, der sofort etwas bringt. - Danach:
decisions/dazunehmen. Das zahlt sich erst nach einigen Wochen aus, wenn jemand eine alte Entscheidung nachschlägt. - Später:
contracts/, falls sich das Grundsystem bewährt.
Wichtig für die Aktualität: Das System ist nur so frisch wie euer Push-Rhythmus. Kleine, häufige Commits helfen mehr als stundenlange Sessions am Stück.
Fehlerberichte und Vorschläge gerne als Issue. Zum Entwickeln siehe CONTRIBUTING.md.
python3 -m unittest discover -s tests -t testsMIT, siehe LICENSE.