Was du am Ende dieses Moduls mitnimmst
Spezialist, optional. Sobald du ein funktionierendes Context Engineering for Claude Code-Projekt hast, hängt manches von dem, was noch zu bauen ist, tatsächlich nicht vom Rest ab. In diesem Modul lässt du zwei Agents gleichzeitig an zwei dieser Teile arbeiten, ohne dass einer den anderen blockiert oder stillschweigend dessen Arbeit überschreibt.
Am Ende hast du zwei echte Arbeitspakete auf main gebracht, jedes in einem eigenen Worktree gebaut, und ein Integration-Review, das beide zusammen geprüft hat, nicht nur einzeln.
Die Lektionen
In dieser Reihenfolge. Jede beantwortet eine konkrete Art, wie parallele Arbeit schiefgehen kann.
- Warum ein Branch allein main blockiert
Eine Arbeitskopie kann immer nur auf einen Branch ausgecheckt sein. Ein zweiter Agent, der etwas anderes anfangen will, muss warten, stashen oder auf die halbfertige Änderung des ersten treten. - Das Worktree-Layout für Claude Code
Ein Ordner pro Feature, jeder auf einen eigenen Branch ausgecheckt, neben dem Hauptordner statt darin. Main bleibt die ganze Zeit auf main. - Benennung: Dev-Doc, Worktree, Branch
Die drei Namen sollten sich ineinander zurückverfolgen lassen, damit jeder vom Branch oder vom Worktree aus das Dev-Doc findet und umgekehrt. Das genaue Benennungsrezept ist Teil des Work-Record-Skills und wird hier nicht veröffentlicht. Halte deine eigenen drei konsistent, dann funktioniert es. - Wirklich unabhängige Arbeit aufteilen
Zwei Arbeitspakete lassen sich nur dann gefahrlos parallelisieren, wenn das Ergebnis des einen nichts daran ändert, was das andere tun sollte. Überlappende Änderungen an derselben Datei sind ein Warnsignal, kein automatisches Hindernis: Es kommt darauf an, was für eine Änderung es ist. - Modellrollen
Opus legt den Zuschnitt jedes Worktrees fest, bevor er startet. Sonnet baut, einer pro Worktree. Fable prüft das zusammengeführte Ergebnis: ein Modell, das keinen der beiden Branches geschrieben hat und beide gleichzeitig kontrolliert. - Integration-Review
Zwei Branches ohne Git-Konflikte können zusammen trotzdem falsch sein. Das Integration-Review öffnet die zusammengeführten Dateien, nicht die beiden Diffs einzeln.
Die Aufgabe
Ausgangspunkt
Das Core-Projekt, bei dem noch zwei Wettbewerber ergänzt werden müssen. An deinem eigenen Projekt sind das zwei beliebige Arbeitspakete, die du wirklich nebeneinander laufen lassen kannst: siehe Wirklich unabhängige Arbeit aufteilen weiter unten.
Erwartetes Ergebnis
Zwei Wettbewerber, in zwei Worktrees ergänzt, zusammengeführt, geprüft.
Bestanden, wenn
Beide landen auf main, ohne sich gegenseitig zu überschreiben, und das Integration-Review nennt mindestens eine Sache, die abgeglichen werden musste.
Warum ein Branch allein main blockiert
Eine Arbeitskopie kann immer nur auf einen Branch ausgecheckt sein. Für einen Agent ist das in Ordnung. In dem Moment, in dem ein zweiter starten will, nicht mehr.
Ein Worktree pro Feature
Ein Branch, eine Arbeitskopie
Das Worktree-Layout für Claude Code
Gezeigt an einem Dummy-Projekt, nicht an einem echten. Main bleibt immer im Projektordner ausgecheckt; jedes Feature bekommt daneben einen eigenen Ordner in einem benachbarten *-workstreams/-Verzeichnis.
~/projects/
├── example-app/ # main is always checked out here
└── example-app-workstreams/
├── add-search/ # one worktree per feature
└── fix-checkout-bug/Die genauen Befehle: Worktree anlegen, darin arbeiten, entfernen, sobald der Branch gemergt ist.
# from inside example-app, on main
git worktree add ../example-app-workstreams/add-search -b feat/add-search
# work happens in the new folder (main is untouched)
cd ../example-app-workstreams/add-search
# ...build, commit, push, open the PR from here...
# once the branch is merged, remove the worktree
cd ../../example-app
git worktree remove ../example-app-workstreams/add-searchNicht dasselbe
Die in Claude Code eingebauten Worktrees (.claude/worktrees/, innerhalb des Projekts) sind für ein Wegwerf-Experiment, das du ohnehin verwirfst. Echte Feature-Arbeit bekommt einen benannten Worktree im benachbarten *-workstreams/-Ordner von oben, wo sie Review und Merge übersteht wie jeder andere Branch.
Wirklich unabhängige Arbeit aufteilen
Mehr Worktrees bedeuten nicht automatisch mehr Tempo. Zwei Arbeitspakete lassen sich nur dann gefahrlos parallelisieren, wenn das Ergebnis des einen nichts daran ändert, was das andere tun sollte.
Abgelehnt: Nicht wirklich unabhängig. Beide würden im Lauf des Projekts dieselbe CLAUDE.md und denselben dev-docs/-Ordner bearbeiten, die Aufteilung ist also gar nicht unabhängig: Es sind dieselben Dateien, nur zu anderen Zeiten. Die beiden Agents sehen die laufenden Entscheidungen des jeweils anderen nicht, treffen also widersprüchliche Entscheidungen zu denselben offenen Fragen, und ein Merge muss die Annahmen des anderen auseinanderklauben. Teile an der Stelle, die das Ergebnis des anderen nicht braucht, um zu wissen, was zu tun ist: hier ein Wettbewerber pro Worktree, jeder fügt seine eigene Zeile in data.js ein.
Modellrollen
Dieselben drei Rollen wie im Rest des Kurses, nur pro Worktree statt pro Session angewendet.
- Opus Legt den Zuschnitt jedes Worktrees fest, bevor einer startet: Dadurch ist die Aufteilung aus dem Abschnitt oben etwas, das du entschieden hast, und nichts, das einfach passiert ist.
- Sonnet Baut: ein Sonnet pro Worktree, das nur mit dem Zuschnitt seines eigenen Worktrees arbeitet.
- Fable Prüft das zusammengeführte Ergebnis: ein Modell, das keinen der beiden Branches geschrieben hat und beide gleichzeitig kontrolliert. Das ist das Integration-Review, als Nächstes.
Integration-Review
Zwei Branches ohne Git-Konflikte können zusammen trotzdem falsch sein. Würdest du das freigeben?
Abgelehnt: Kein Integration-Read. Git prüft nur, ob dieselben Zeilen geändert wurden. Beide Worktrees haben einen Wettbewerber ergänzt, indem sie eine Zeile an data.js angehängt haben: keine Zeilenüberlappung, der Merge ist nach Gits Definition also sauber. Aber der Agent jedes Worktrees ging davon aus, die sechste Zeile zu ergänzen, und die Seite, die data.js liest, ging von genau fünf aus. Der Merge ist sauber und die Seite trotzdem falsch, und in keinem der beiden Diffs ist das zu sehen. Nur das Öffnen der zusammengeführten Seite zeigt es. Dafür ist ein Integration-Review da: Es liest die zusammengeführten Dateien, nicht die beiden Diffs für sich.
Gib zwei Arbeitspaketen ihren eigenen Raum
Ein Befehl richtet pro Feature einen eigenen Arbeitsbereich ein, damit keiner den anderen blockiert, und ein Prompt prüft die beiden, sobald sie wieder zusammengeführt sind.
Ein Ordner, ein Branch
- Beide Jobs teilen sich denselben Ordner, der zweite wartet also, bis der erste fertig ist, bevor er überhaupt starten kann.
- Das Hin- und Herwechseln mittendrin hinterlässt halbfertige Dateien und lässt den Faden reißen.
Ein Ordner pro Arbeitspaket
| Was sich ändert | |
|---|---|
| Setup | git worktree add ../worktrees/add-competitor -b feat/add-competitor: ein Befehl, ein eigener Ordner, ein eigener Branch. |
| Warum es dich entlastet | Jeder Job hat seine eigenen Dateien auf der Platte, sodass zwei gleichzeitig laufen können, ohne sich zu blockieren oder gegenseitig zu überschreiben. |
| Abschluss | git worktree remove ../worktrees/add-competitor, sobald gemergt ist, damit sich alte Arbeitsbereiche nicht anhäufen. |
| Der Haken | Dass Git sauber mergt, heißt nicht, dass die beiden Änderungen zusammenpassen. Das prüft der Integration-Review-Prompt. |
Zum Weiterlesen: Von der Idee zum Beleg zeigt den Weg von der Recherche zum Build, dem zwei parallele Worktrees trotzdem je folgen müssen, und das Claude Agents Toolkit deckt das Betreiben mehrerer Agents an einem Projekt über Worktrees hinaus ab. Wiederkehrende Arbeit automatisieren ist das, was das Sonnet jedes Worktrees meist ausführt, sobald es ein wiederholter Ablauf ist, und Nachvollziehbar recherchieren ist der Spezialist, den du am ehesten mit einem Worktree pro Quelle kombinieren solltest.
