using-git-worktrees

Überblick über den Skill using-git-worktrees

Was der Skill using-git-worktrees macht

Der Skill using-git-worktrees hilft einem Agenten dabei, für neue Arbeit einen separaten Git-Worktree anzulegen, statt den aktuellen Checkout wiederzuverwenden. Seine eigentliche Aufgabe ist nicht nur „git worktree add ausführen“, sondern einen sinnvollen Speicherort zu wählen, zu prüfen, dass lokale Worktree-Ordner sicher ignoriert werden, und zu vermeiden, dass der Haupt-Workspace verunreinigt wird.

Für wen sich die Installation lohnt

Dieser Skill passt besonders gut für Menschen, die regelmäßig:

• mit Feature-Arbeit beginnen und dabei bestehende Änderungen unberührt lassen wollen
• mehrere Branches parallel prüfen oder umsetzen
• sicherere KI-gestützte Coding-Workflows mit weniger Risiko beim Branch-Wechsel möchten
• projektübergreifend eine wiederholbare Methode brauchen, um isolierte Workspaces anzulegen

Wenn du einen Assistenten oft bittest, „das in einem separaten Branch zu starten“ oder „zu arbeiten, ohne meinen aktuellen Tree anzufassen“, ist using-git-worktrees sehr wahrscheinlich ein guter Fit.

Welches Problem der Skill löst

Nutzer wollen vor allem eines: die Implementierung in einem isolierten Workspace starten, ohne unnötige Setup-Fehler. Der Skill using-git-worktrees ist nützlich, weil er vor dem Erstellen einen klaren Entscheidungsprozess ergänzt:

• ein vorhandenes projektbezogenes Worktree-Verzeichnis bevorzugen, falls vorhanden
• eine dokumentierte Repo-Präferenz aus CLAUDE.md berücksichtigen, falls verfügbar
• nachfragen, wenn es keinen sicheren Standard gibt
• das Ignore-Verhalten prüfen, bevor projektlokale Worktrees erstellt werden

Dadurch ist er verlässlicher als ein generischer Prompt, der direkt zu Shell-Befehlen springt.

Was ihn von einem normalen Prompt unterscheidet

Ein normaler Prompt kennt Git-Worktrees vielleicht konzeptionell, übersieht aber oft repo-spezifische Setup-Details. Dieser Skill gibt dem Agenten eine feste Reihenfolge von Schritten und Sicherheitsprüfungen vor, besonders bei der Wahl des Verzeichnisses und beim Umgang mit .gitignore. Das ist der eigentliche Unterschied bei using-git-worktrees for Git Workflows: weniger Rätselraten beim Setup, nicht mehr Git-Theorie.

Wann dieser Skill nicht gut passt

Lass using-git-worktrees weg, wenn:

• du immer nur in einem einzigen Branch und einem einzigen Verzeichnis arbeitest
• deine Umgebung keine zusätzlichen Arbeitsverzeichnisse erlaubt
• du nur schnell den Branch wechseln willst, aber keine isolierte Ausführung brauchst
• dein Team bereits ein festes Wrapper-Skript hat, das diese Entscheidungslogik vollständig ersetzt

In solchen Fällen sind ein einfacher Shell-Befehl oder ein interner Workflow oft schneller.

So verwendest du den Skill using-git-worktrees

Installationskontext für using-git-worktrees

Installiere den Skill aus der Skill-Sammlung obra/superpowers:

npx skills add https://github.com/obra/superpowers --skill using-git-worktrees

Nach der Installation solltest du ihn verwenden, wenn du Arbeit beginnst, für die der aktuelle Checkout nicht wiederverwendet werden soll.

Wie Nutzer den Skill tatsächlich aufrufen

Das Repository macht ausdrücklich klar, dass der Agent die Nutzung zu Beginn ankündigen soll. In der Praxis sollte deine Anfrage die Anforderung an Isolation deutlich machen, zum Beispiel:

• „Use using-git-worktrees and set up an isolated workspace for this feature.“
• „Before implementing, create a worktree for branch feature/auth-refresh.“
• „Use the using-git-worktrees skill so my current changes stay untouched.“

So steigt die Wahrscheinlichkeit, dass der Agent dem Skill folgt, statt zu improvisieren.

Welche Eingaben der Skill braucht

Für gute Ergebnisse solltest du Folgendes angeben:

• den Namen des Ziel-Branches
• ob es sich um einen neuen oder einen bestehenden Branch handelt
• ob du projektlokale oder globale Worktree-Ablage bevorzugst
• repo-spezifische Einschränkungen wie „must stay under project root“

Minimal sinnvolle Eingaben:

• Branch-/Task-Name
• Erlaubnis, einen Worktree anzulegen

Bessere Eingaben:

• Branch-Name
• gewünschte Verzeichnisrichtlinie
• ob im aktuellen Checkout uncommittete Änderungen vorhanden sind
• was nach dem Setup passieren soll, etwa „then start implementation“

Die eingebaute Logik zur Verzeichniswahl

Der using-git-worktrees skill ist vor allem wegen seines Workflows zur Verzeichniswahl wertvoll. Er folgt dieser Priorität:

1. .worktrees verwenden, wenn es bereits existiert
2. andernfalls worktrees verwenden, wenn es existiert
3. andernfalls CLAUDE.md auf eine dokumentierte Präferenz prüfen
4. andernfalls den Nutzer bitten, zwischen Folgendem zu wählen:
   • .worktrees/
   • ~/.config/superpowers/worktrees/<project-name>/

Das ist wichtig, weil wild verteilte Worktrees schnell zu einem echten Wartungsproblem werden, wenn jede Sitzung einen neuen Ort erfindet.

Sicherheitsprüfungen vor projektlokaler Erstellung

Ein wichtiges Detail für den praktischen Einsatz: Wenn der Worktree innerhalb des Repositories liegen soll, verlangt der Skill vor der Erstellung eine Prüfung, ob das Verzeichnis ignoriert wird. Das schützt davor, Worktree-Ordner versehentlich mitzuverfolgen oder die Status-Ausgabe unnötig zuzumüllen.

Das ist ein echter Vorteil gegenüber ad hoc genutzten Prompts. Wenn dein Team projektlokale Worktrees erwartet, solltest du sicherstellen, dass .worktrees/ oder worktrees/ in Git ignoriert wird, bevor ihr euch auf diesen Workflow verlasst.

Starke Prompt-Muster für die Nutzung von using-git-worktrees

Schwacher Prompt:

• „Start working on OAuth cleanup.“

Stärkerer Prompt:

• „Use using-git-worktrees to create an isolated workspace for new branch feature/oauth-cleanup. Prefer .worktrees/ if safe and ignored. After setup, begin implementation without touching my current checkout.“

Warum das besser ist:

• nennt den Skill
• gibt ein Branch-Ziel vor
• nennt die Verzeichnispräferenz
• sagt dem Agenten, was als Nächstes passieren soll

Empfohlener Workflow nach dem Erstellen

Eine praktische Reihenfolge für die using-git-worktrees-Nutzung:

1. den Agenten bitten, den Skill zu verwenden
2. Speicherort des Worktrees und Branch-Namen bestätigen
3. den Agenten die Arbeit in den neuen Workspace verlagern lassen
4. erst dann mit Änderungen, Tests oder Implementierungsplanung beginnen

Diese Reihenfolge ist besonders nützlich, wenn dein aktueller Checkout bereits uncommittete Änderungen enthält.

Welche Dateien du im Repository zuerst lesen solltest

Es gibt hier nur eine wirklich relevante Quelldatei: SKILL.md.

Lies sie für:

• die genaue Prioritätsreihenfolge bei der Verzeichniswahl
• den erwarteten Nutzer-Prompt, wenn keine Präferenz existiert
• die Anforderung zur Ignore-Prüfung
• die Aktivierungsformulierung, die dem Agenten sagt, dass er die Skill-Nutzung ankündigen soll

Dieser Skill ist bewusst leichtgewichtig. Die entscheidende Frage für die Einführung ist daher, ob diese Logik zum Git-Workflow deines Teams passt.

Praktische Einschränkungen, die du kennen solltest

Der Skill ist absichtlich eng zugeschnitten. Er bietet offenbar nicht:

• Wrapper-Skripte
• Automatisierungshelfer
• Durchsetzung von Branch-Namensregeln
• Cleanup-Routinen für veraltete Worktrees
• plattformspezifische Fallbacks

using-git-worktrees install gibt dir also Entscheidungshilfe, aber kein vollständiges System zur Worktree-Verwaltung. Wenn du Lifecycle-Automatisierung brauchst, solltest du ihn mit eigenen Shell-Tools ergänzen.

FAQ zum Skill using-git-worktrees

Ist using-git-worktrees gut für Einsteiger?

Ja, wenn der Einsteiger grundlegende Branch-Konzepte bereits versteht und einen sichereren „fass meinen aktuellen Workspace nicht an“-Workflow möchte. Es ist kein Git-Tutorial, sondern ein strukturierter Setup-Skill. Wer ganz neu anfängt, braucht möglicherweise trotzdem Hilfe dabei zu verstehen, was ein Worktree ist und worin der Unterschied zum Cloning liegt.

Welches Problem löst das besser als normale Prompts?

Normale Prompts überspringen oft den unordentlichen Teil: wo der Worktree liegen soll und ob ein projektlokales Verzeichnis sicher ignoriert wird. Der im Skill codierte using-git-worktrees guide reduziert diese Setup-Fehler und sorgt für konsistenteres Verhalten des Agenten.

Brauche ich projektlokale Worktrees, um ihn zu nutzen?

Nein. Der Skill kann auf einen globalen Speicherort lenken, wenn kein lokales Verzeichnis existiert und im Repo keine Präferenz dokumentiert ist. Dadurch ist er auch dann brauchbar, wenn du keine zusätzlichen Ordner innerhalb des Repositories möchtest.

Kann ich using-git-worktrees auch für bestehende Branches verwenden?

Ja. Der Workflow ist auch dann sinnvoll, wenn ein bestehender Branch in einen separaten Workspace ausgecheckt werden soll. Der Hauptwert liegt in der Isolation, nicht nur im Erstellen neuer Branches.

Wann sollte ich using-git-worktrees nicht verwenden?

Verwende ihn nicht, wenn:

• du nur eine winzige Änderung im aktuellen Branch machen willst
• dein Team nicht verwaltete Worktree-Speicherorte verbietet
• du bereits deterministische interne Tools hast, die Speicherort- und Ignore-Regeln übernehmen
• dein Repo ungewöhnliche Git-Einschränkungen hat, die der Skill nicht kennt

Ersetzt das Git-Kenntnisse?

Nein. Der using-git-worktrees skill verbessert Disziplin bei Aufruf und Setup, aber du brauchst weiterhin grundlegendes Git-Urteilsvermögen für Branch-Namen, Rebasing, Cleanup und Merge-Strategie.

So verbesserst du den Skill using-git-worktrees

Branch- und Verzeichnisabsicht explizit angeben

Die größte Qualitätssteigerung erreichst du, wenn du dem Agenten sowohl das Branch-Ziel als auch die gewünschte Verzeichnisrichtlinie mitteilst. Beispiel:

„Use using-git-worktrees for branch fix/cache-invalidation. If .worktrees/ exists and is ignored, use it; otherwise ask before using a global location.”

So beseitigst du die häufigste Quelle von Unklarheit.

Präferenzen in CLAUDE.md dokumentieren

Da der Skill CLAUDE.md prüft, kannst du zukünftige Ergebnisse verbessern, indem du dort Folgendes dokumentierst:

• bevorzugtes Worktree-Verzeichnis
• ob projektlokale Worktrees erlaubt sind
• Namenskonventionen für Branches oder Ordner

So wird wiederholter Klärungsbedarf vom Nutzer zur Repo-weiten Richtlinie.

Ignore-Regeln für lokale Verzeichnisse vorab konfigurieren

Wenn dein Team .worktrees/ oder worktrees/ innerhalb des Projekts nutzen möchte, füge die Ignore-Regel vorab hinzu. Das macht den Pfad using-git-worktrees for Git Workflows reibungsloser, weil die Sicherheitsprüfung sauber durchläuft, statt mitten in der Aufgabe eine Diskussion auszulösen.

Auf typische Fehlerbilder achten

Die wichtigsten Fehlerbilder sind gut vorhersehbar:

• der Agent erstellt einen Worktree an einem nicht freigegebenen Ort
• lokale Worktree-Ordner werden nicht ignoriert
• der Branch-Name wird aus einer vagen Feature-Anfrage schlecht abgeleitet
• die Implementierung startet im ursprünglichen Checkout, bevor die Isolation abgeschlossen ist

Die meisten dieser Probleme entstehen durch unvollständige Prompts, nicht durch den Skill selbst.

Vor dem Coding eine Bestätigung verlangen

Ein einfacher Verbesserungsprompt:

• „Use using-git-worktrees, then report the final path and branch before making edits.”

So lassen sich Fehler früh abfangen. Das ist besonders nützlich in Repositories mit mehreren verschachtelten Ordnern oder ungewöhnlichen Richtlinien.

Nach dem ersten Durchlauf nachschärfen

Wenn das erste Ergebnis akzeptabel, aber noch nicht ideal ist, solltest du das Arbeitsmuster verfeinern, statt alles neu zu schreiben:

• den bevorzugten Speicherort für Worktrees festlegen
• einen Hinweis in CLAUDE.md ergänzen
• Branch-Namen in Prompts standardisieren
• vor Änderungen ausdrücklich eine Bestätigung verlangen

Dadurch wird die using-git-worktrees-Nutzung mit der Zeit berechenbarer und wiederholte Reibung beim Setup nimmt ab.