finishing-a-development-branch

Überblick

Was dieses Skill macht

Das Skill finishing-a-development-branch hilft dir, einen Git-Development-Branch sicher abzuschließen, sobald die Implementierung fertig ist und die Test-Suite erfolgreich durchläuft. Es führt dich durch einen klaren, wiederholbaren Workflow, mit dem du entscheiden kannst, ob du lokal mergen, pushen und einen Pull Request öffnen, den Branch später weiterverwenden oder komplett verwerfen möchtest.

Das Grundprinzip des Skills ist einfach:

Tests verifizieren → Basis-Branch bestimmen → Optionen präsentieren → Entscheidung ausführen → Aufräumen

Anstatt einzelne Git-Befehle ad hoc auszuführen oder wichtige Checks zu vergessen, gibt finishing-a-development-branch deinem Agent eine konsistente Checkliste für das Ende eines Feature- oder Bugfix-Branches.

Für wen ist finishing-a-development-branch gedacht?

• Entwickler, die mit Git-Branches arbeiten und eine strukturierte „Ende-des-Branches“-Routine wünschen
• Teams, die verlangen, dass Tests vor Merge oder PR-Erstellung bestanden werden
• Nutzer des obra/superpowers Skill-Sets, die Git-Workflows von Agents sicherer steuern lassen möchten
• Alle, die sich regelmäßig fragen: „Ist dieser Branch bereit zum Mergen, und wie soll ich ihn integrieren?“

Besonders gut passt es in Repositories, die bereits automatisierte Tests und Standard-Basis-Branches wie main oder master verwenden.

Welche Probleme dieses Skill löst

• Vergessen, Tests vor einem Merge oder Pull Request auszuführen
• Unklarheit darüber, von welchem Branch ein Feature-Branch ursprünglich abgespalten wurde
• Uneinheitliche Entscheidungen, ob lokal gemergt, per PR integriert oder Arbeit verworfen werden soll
• Zurückgelassene Branches, die das Repository zumüllen, weil der Abschluss-Schritt nie klar war

Indem es zuerst auf Tests besteht und danach nur wenige, klar definierte Optionen anbietet, verringert finishing-a-development-branch Fehler und macht deinen Git-Workflow berechenbar.

Wann dieses Skill gut passt

Nutze finishing-a-development-branch, wenn:

• Eine Funktion oder ein Fix vollständig implementiert ist
• Erwartet wird, dass alle Tests bestehen, oder du Integration bei fehlschlagenden Tests bewusst blockieren willst
• Du bereit bist zu entscheiden, wie dieser Branch integriert werden soll oder ob er verworfen wird

Es ist kein guter Fit, wenn:

• Du noch aktiv auf dem Branch entwickelst oder experimentierst
• Das Repository keine sinnvollen Tests hat und du keine aussagekräftige Test-Suite ausführen kannst
• Du komplexes Multi-Branch-Release-Management über einen einfachen Feature- → Basis-Branch-Workflow hinaus brauchst

Wenn du primär Hilfe beim Schreiben von Code oder beim Review von Änderungen brauchst, kombiniere dieses Skill mit anderen, die sich auf Implementierung oder Code-Review fokussieren. finishing-a-development-branch kümmert sich explizit um den letzten Integrationsschritt.

Verwendung

Installation und Setup

1. Skill installieren

Installiere finishing-a-development-branch aus dem Repository obra/superpowers mit der Skills CLI:

npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch

Damit steht das Skill deiner Agent-Umgebung zur Verfügung und kann den geführten Git-Workflow auf dein aktuelles Repository anwenden.

2. Repository-Voraussetzungen prüfen

Damit das Skill wie vorgesehen funktioniert, sollte dein Projekt:

• Ein Git-Repository mit eindeutigem Basis-Branch sein (typischerweise main oder master).
• Über eine ausführbare Test-Suite verfügen, typischerweise via Befehle wie:
  • npm test
  • cargo test
  • pytest
  • go test ./...

Der genaue Befehl hängt von deinem Tech-Stack ab; das Skill erwartet, dass irgendein Test-Befehl existiert und vor der Integration ausgeführt werden kann.

3. Nutzung des Skills ankündigen

Wenn du den Abschluss-Prozess startest, erwartet das Skill, dass du (oder dein Agent) das explizit ankündigst:

"I'm using the finishing-a-development-branch skill to complete this work."

So bleibt der Workflow für Mitwirkende transparent und signalisiert, dass der strukturierte Prozess aktiv ist.

Geführte Workflow-Schritte

Schritt 1: Tests verifizieren

Bevor Integrationsentscheidungen getroffen werden, führt das Skill die Test-Suite des Projekts aus oder fordert dich dazu auf. Typische Befehle sind:

npm test
# or
cargo test
# or
pytest
# or
go test ./...

• Wenn Tests fehlschlagen: Das Skill meldet die Anzahl der Fehlschläge, zeigt die Fehler an und bricht den Prozess ab. Es weist darauf hin, dass ohne erfolgreiche Tests weder Merge noch PR möglich sind.
• Wenn Tests bestehen: Der Workflow geht zum nächsten Schritt über.

Diese strikte „Tests zuerst“-Hürde verhindert, dass defekter Code gemergt oder in einem Pull Request eingereicht wird.

Schritt 2: Basis-Branch bestimmen

Anschließend ermittelt finishing-a-development-branch, von welchem Branch dein Development-Branch ursprünglich abgespalten wurde, etwa mit Git-Befehlen wie:

git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null

Kann der Basis-Branch nicht automatisch bestimmt werden, stellt das Skill eine Rückfrage wie:

"This branch split from main - is that correct?"

Die korrekte Bestätigung des Basis-Branches ist wichtig, weil sie festlegt, wohin deine Arbeit gemergt wird bzw. auf welchen Branch dein Pull Request zielt.

Schritt 3: Integrationsoptionen präsentieren

Sobald die Tests bestanden sind und der Basis-Branch bekannt ist, präsentiert das Skill genau vier kompakte Optionen:

Implementation complete. What would you like to do?

1. Merge back to <base-branch> locally
2. Push and create a Pull Request
3. Keep the branch as-is (I'll handle it later)
4. Discard this work

Which option?

Die Optionen sind bewusst kurz und klar gehalten, damit du schnell wählen kannst.

Typische Anwendungsfälle:

• Option 1 – Du möchtest schnell lokal mergen, etwa in kleineren persönlichen Projekten oder wenn du alleiniger Maintainer bist.
• Option 2 – Du arbeitest im Team und brauchst Code-Review, CI oder Freigaben über eine Git-Plattform wie GitHub.
• Option 3 – Du bist noch nicht entscheidungsbereit, möchtest aber sicherstellen, dass die Tests bestehen und der Branch-Zustand eindeutig ist.
• Option 4 – Du hast nur experimentiert oder der Ansatz ist obsolet und du willst den Branch sauber entfernen.

Schritt 4: Gewählte Option ausführen

Je nach Auswahl führt das Skill die entsprechenden Git-Aktionen und das dazugehörige Aufräumen aus. Im zugrunde liegenden SKILL.md sind einige Detailbefehle abgeschnitten, die Intention ist aber:

• Für lokalen Merge: Den Basis-Branch auschecken, den Development-Branch hinein mergen und bei Bedarf den fertiggestellten Branch löschen.
• Für Push + PR: Den Branch zum Remote pushen und dich anleiten, einen Pull Request gegen den ermittelten Basis-Branch zu erstellen.
• Für Beibehalten: Den aktuellen Branch unverändert lassen und klar markieren, dass du die Integration später vornimmst.
• Für Verwerfen: Den Branch nach Bestätigung sicher verwerfen oder löschen.

Während dieses Schritts liegt der Fokus des Skills auf Vorhersagbarkeit und Sicherheit: kein Merge bei fehlschlagenden Tests, kein Merge in den falschen Basis-Branch und keine versehentliche Arbeitseinbuße.

Praktische Nutzungstipps

In deinen persönlichen Workflow integrieren

• Führe finishing-a-development-branch aus, sobald du glaubst, dass ein Feature „fertig“ ist.
• Nutze die Test-Hürde als finalen Qualitätscheck, bevor du zwischen Merge und PR entscheidest.
• Verwende in Team-Setups standardmäßig Option 2, um sicherzustellen, dass Reviews und CI-Pipelines ausgelöst werden.

Mit Team-Konventionen kombinieren

Wenn dein Team eigene Branching- und Review-Regeln hat (z. B. immer zuerst PR nach develop oder Branches nie automatisch löschen), richte deine Nutzung der Optionen an diesen Vorgaben aus. Die Struktur des Skills macht es leichter, solche Policies konsequent umzusetzen.

Mit anderen superpowers Skills kombinieren

Innerhalb der obra/superpowers Suite ergänzt finishing-a-development-branch Skills, die bei Implementierung, Refactoring oder Testing helfen. Nutze diese, um den Branch weiterzuentwickeln, und rufe dieses Skill erst auf, wenn du wirklich bereit zur Integration bist.

FAQ

Wann sollte ich das finishing-a-development-branch Skill ausführen?

Führe finishing-a-development-branch aus, wenn deine Änderungen implementiert sind, du erwartest, dass die Tests bestehen, und du bereit bist zu entscheiden, wie der Branch integriert werden soll (Merge, PR, behalten oder verwerfen). Es ist als letzter Schritt im Lebenszyklus eines Branches gedacht, nicht als täglicher Entwicklungshelfer.

Was passiert, wenn Tests fehlschlagen?

Wenn die Tests fehlschlagen, meldet das Skill die Fehler und stoppt den Prozess. Es wird weder mergen noch einen Pull Request erstellen. Du solltest die fehlschlagenden Tests auf dem Branch beheben, die Tests erneut ausführen und finishing-a-development-branch erst dann erneut aufrufen.

Kann ich es ohne automatisierte Test-Suite verwenden?

Das Skill folgt dem Prinzip „Tests zuerst verifizieren“. Theoretisch könntest du es in einem Projekt ohne Tests verwenden, würdest damit aber eine seiner wichtigsten Schutzfunktionen umgehen. Für beste Ergebnisse nutze es in Repositories, in denen du Befehle wie npm test, cargo test, pytest oder go test ./... ausführen kannst.

Wie entscheidet es, in welchen Branch gemergt wird?

finishing-a-development-branch versucht, den Basis-Branch über Git merge-base gegen gängige Branch-Namen wie main oder master zu bestimmen. Ist das nicht eindeutig, fragt es dich nach einer Bestätigung, welcher Basis-Branch verwendet werden soll. So bleiben Merges und Pull Requests auf den korrekten Branch ausgerichtet.

Erstellt es automatisch einen Pull Request?

Die dokumentierte Funktion des Skills ist es, bei Auswahl von Option 2 „push and create a Pull Request“ auszuführen. Die genauen Mechanismen hängen davon ab, wie deine Agent-Umgebung mit deiner Git-Plattform integriert ist. Mindestens wird der Branch gepusht und du wirst angeleitet, einen PR gegen den ermittelten Basis-Branch zu öffnen.

Wird mein Branch automatisch gelöscht?

Die SKILL-Beschreibung konzentriert sich darauf, Optionen zu präsentieren und den gewählten Workflow inklusive Aufräumen auszuführen. Das konkrete Löschverhalten kann davon abhängen, wie deine Umgebung den Cleanup-Schritt interpretiert. Behandle Option 4 („discard this work“) als potenziell destruktiv und wähle sie nur, wenn du sicher bist, dass du den Branch nicht mehr brauchst.

Ist finishing-a-development-branch für komplexe Release-Flows geeignet?

Dieses Skill richtet sich an einfache Feature- oder Fix-Branches, die in einen einzigen Basis-Branch zurückgeführt werden. Wenn du mehrere langlebige Release-Branches, Hotfix-Flows oder komplexe Deployment-Pipelines verwaltest, kannst du finishing-a-development-branch zwar weiterhin pro Branch einsetzen, brauchst aber möglicherweise zusätzliche Prozesse oder Tools für die übergeordnete Release-Strategie.

Wie installiere ich finishing-a-development-branch noch einmal?

Nutze die Skills CLI und verweise auf das Repository obra/superpowers:

npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch

Nach der Installation folgst du dem Workflow des Skills: Tests ausführen, Basis-Branch bestätigen, eine Option wählen und das Skill die Integrations- und Aufräum-Schritte erledigen lassen.