Beide Skills erkennen den direkten Workflow jetzt über zwei Wege: CLAUDE.md-Angabe oder Vorhandensein der Datei .commit-on-main. Konflikt mit Remote-Version zugunsten der strukturierteren Variante aufgelöst (explizite Schritt-Markierungen, getrennter Abschluss-Block). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3.9 KiB
description: Finaler Abschluss eines Features: Commit → Push → PR erstellen → PR mergen → Branch löschen → main pullen. Aktivieren wenn alles fertig ist und der Branch vollständig in main überführt werden soll. Unterschied zu /go: /ship merged den PR und räumt auf. Nicht aufrufen wenn der User nur committen, nur pushen, nur einen PR erstellen oder die Tests noch laufen lassen möchte. context: fork model: claude-haiku-4-5-20251001
/ship — Commit, PR, Merge, Cleanup
Führe diese Schritte der Reihe nach aus. Bei jedem Fehler: Abbruch mit klarer Fehlermeldung.
Schritt 0: Git-Workflow erkennen
Prüfe, ob das Projekt den direkten Workflow (ohne Branches/PRs) nutzt. Das ist der Fall, wenn mindestens eine der folgenden Bedingungen zutrifft:
- Die
CLAUDE.mdim Repository-Root gibt an, dass direkt aufmaster/maincommitet und gepusht werden soll - Eine Datei
.commit-on-mainexistiert im Repository-Root
→ Nur Schritt 1 (Commit) und Schritt 2 (Push) ausführen, dann direkt zum Abschluss springen. Schritte 3–7 entfallen.
Ansonsten: normaler Branch+PR-Workflow (weiter mit Branch-Prüfung).
Schritt 0b: Branch-Prüfung (nur bei Branch+PR-Workflow)
git branch --show-current
Falls der aktuelle Branch main ist und es uncommittete Änderungen oder lokale Commits gibt, die noch nicht auf Remote sind: Branch-Namen direkt aus den geänderten Dateien ableiten und ohne lange Erklärung vorschlagen:
„Du bist auf
main. Ich lege Branchfeat/xyzan — OK?"
Nach Bestätigung:
git checkout -b <branch-name>
Bei uncommitteten Änderungen: Änderungen bleiben erhalten (kein stash nötig, checkout -b nimmt sie mit).
Bei lokalen Commits auf main: Branch anlegen, dann git push -u origin <branch-name> — main bleibt unverändert.
Danach normal weiter mit Schritt 1.
Schritt 1: Commit
Prüfe ob es uncommittete Änderungen gibt:
git status
git diff --stat
Falls ja: Erstelle einen Commit. Leite den Commit-Titel aus den geänderten Dateien und git diff --stat ab. Nutze das HEREDOC-Format:
git add -p ← nur wenn sinnvoll, sonst: git add <spezifische Dateien>
git commit -m "..."
Falls nichts zu committen: weiter mit Schritt 2.
Schritt 2: Push
git push
Falls der Branch noch kein Remote-Tracking hat:
git push -u origin <branch>
Schritt 3: PR erstellen (nur bei Branch+PR-Workflow)
Ermittle Branch-Namen und Commits seit main:
git branch --show-current
git log --oneline origin/main..HEAD
Erstelle den PR via mcp__gitea__pull_request_write (method: create):
owner: aus git remote URL ermittelnrepo: aus git remote URL ermittelnhead: aktueller Branchbase: maintitle: Erster Commit-Titel des Branchesbody: Alle Commits als Aufzählung + Akzeptanzkriterien als Checkboxen (was wurde geändert, wie verifiziert)
Merke dir den PR-Index aus der Antwort.
Schritt 4: PR freigeben (nur bei Branch+PR-Workflow)
Genehmige den PR via mcp__gitea__pull_request_review_write (method: create_review):
review_type: APPROVEDbody: "Automatisch freigegeben via /ship"
Schritt 5: PR mergen (nur bei Branch+PR-Workflow)
Merge via mcp__gitea__pull_request_write (method: merge):
merge_style: mergedelete_branch: true ← löscht Remote-Branch automatisch
Schritt 6: Checkout main + Pull (nur bei Branch+PR-Workflow)
git checkout main
git pull
Schritt 7: Lokale Branches aufräumen (nur bei Branch+PR-Workflow)
git branch -d <feature-branch>
git remote prune origin
Falls git branch -d scheitert (Branch nicht vollständig gemergt laut git): trotzdem löschen mit -D, da wir wissen dass der PR gemergt wurde.
Abschluss
Bei direktem Workflow (kein PR):
- Commit-Hash und -Titel
- Aktueller Stand von
git log --oneline -3
Bei Branch+PR-Workflow:
- PR-URL
- Welche Branches gelöscht wurden
- Aktueller Stand von
git log --oneline -3