Kürzlich machen viele Vibe-Coding, besonders kurz bevor das Kontingent zurückgesetzt wird. Dann wirft man eine Menge Tasks an Agent(s) raus. Manche Aufgaben zeigen als erledigt an – also kümmert man sich erstmal nicht weiter. Aber am nächsten Tag im Test stelle ich fest: Die Aufgaben waren doch nicht fertig. Ich schaue zurück und sehe, warum: Es wurde ein worktree angelegt, aber nicht in `main` geändert. Es wurde schlichtweg nichts zusammengeführt.
Dann habe ich den Agent gebeten, das Ganze nochmal zentral durchzuschauen. Es gab auch noch einige solcher worktrees – die soll er bereinigen.
Zum Schluss habe ich ihm eine Regel in Agents.md geben lassen: Worktrees dürfen zwar erstellt werden, aber sie dürfen nicht übersehen werden.
--- Beispiel für Review-Prompt zu worktree ---
Schau bitte, welche worktrees noch nicht mit `main` synchronisiert wurden. Synchronisierte kannst du direkt löschen. Nicht synchronisierte bitte auflisten: Zweig(e), Zusammenfassung der Änderungen (inklusive der letzten paar Commits) und die zugehörigen Session-Sitzungen.
--- Beispiel für Cleanup-Prompt zu worktree ---
Schau dir bitte den Inhalt dieser worktrees an: Was sich klar lohnt zu mergen, lass mich wissen, und führe es für mich zusammen und bereinige die worktrees. Unklare Fälle bestätige mit mir – aber gib mir eine klare Empfehlung.
--- Beispiel-Regeln für AGENTS.md ---
- Kein worktree darf zurückbleiben: Bei Tasks, die in einem worktree erledigt werden, muss dieses worktree (und sein Branch) nach Abschluss gelöscht werden. Vor dem Löschen zwei Optionen wählen: Entweder in `main` mergen; oder, wenn nicht gemerged wird, erst die nicht committeten Änderungen in diesen Branch committieren, dann mit dem Tag `archive/<worktree-Name>` archivieren und anschließend `git worktree remove` + `git branch -D` ausführen. Die orchestrierten Subagent-Sitzungen kümmern sich darum, die daraus abgeleiteten worktrees abzuschließen. Muss ausnahmsweise erhalten bleiben (vom User zu entscheiden, Konflikte offen zur Auflösung), dann müssen im finalen Reply Pfade und Gründe ausdrücklich genannt werden – es darf nicht stillschweigend zurückgelassen werden.
Dann habe ich den Agent gebeten, das Ganze nochmal zentral durchzuschauen. Es gab auch noch einige solcher worktrees – die soll er bereinigen.
Zum Schluss habe ich ihm eine Regel in Agents.md geben lassen: Worktrees dürfen zwar erstellt werden, aber sie dürfen nicht übersehen werden.
--- Beispiel für Review-Prompt zu worktree ---
Schau bitte, welche worktrees noch nicht mit `main` synchronisiert wurden. Synchronisierte kannst du direkt löschen. Nicht synchronisierte bitte auflisten: Zweig(e), Zusammenfassung der Änderungen (inklusive der letzten paar Commits) und die zugehörigen Session-Sitzungen.
--- Beispiel für Cleanup-Prompt zu worktree ---
Schau dir bitte den Inhalt dieser worktrees an: Was sich klar lohnt zu mergen, lass mich wissen, und führe es für mich zusammen und bereinige die worktrees. Unklare Fälle bestätige mit mir – aber gib mir eine klare Empfehlung.
--- Beispiel-Regeln für AGENTS.md ---
- Kein worktree darf zurückbleiben: Bei Tasks, die in einem worktree erledigt werden, muss dieses worktree (und sein Branch) nach Abschluss gelöscht werden. Vor dem Löschen zwei Optionen wählen: Entweder in `main` mergen; oder, wenn nicht gemerged wird, erst die nicht committeten Änderungen in diesen Branch committieren, dann mit dem Tag `archive/<worktree-Name>` archivieren und anschließend `git worktree remove` + `git branch -D` ausführen. Die orchestrierten Subagent-Sitzungen kümmern sich darum, die daraus abgeleiteten worktrees abzuschließen. Muss ausnahmsweise erhalten bleiben (vom User zu entscheiden, Konflikte offen zur Auflösung), dann müssen im finalen Reply Pfade und Gründe ausdrücklich genannt werden – es darf nicht stillschweigend zurückgelassen werden.