wemilabs/ship-to-prod

Ship to Prod

Wenn der Benutzer nach Abschluss der Arbeit „ship it“ oder ähnlich sagt, führe diese Schritte aus, ohne zweimal gefragt zu werden.

Der Ablauf hängt davon ab, auf welchem Branch du dich befindest. Erkenne die Umgebung einmalig und verwende sie für alle Schritte.

Umgebung erkennen

Führe diese Schritte einmalig zu Beginn parallel aus:

1. Paketmanager: Überprüfe auf eine Lockdatei im Repo-Root.
   • pnpm-lock.yaml -> pnpm
   • yarn.lock -> yarn
   • bun.lockb oder bun.lock -> bun
   • package-lock.json -> npm
   • Falls package.json ein packageManager-Feld hat, verwende dieses stattdessen.
   • Falls keines gefunden wird, standardmäßig npm.
2. Standard-Branch: git symbolic-ref refs/remotes/origin/HEAD (oder als Fallback git config init.defaultBranch). Falls beides fehlschlägt, standardmäßig main.
3. PR-Tooling: gh --version. Falls gh installiert und authentifiziert ist, verwende es für PR-Erstellung und Merge. Andernfalls gib die PR-URL aus, damit der Benutzer den PR manuell erstellen kann.
4. Shell: Erkenne die aktuelle Shell. Unter Windows (PowerShell) funktionieren Heredocs nicht, verwende daher mehrere -m-Flags für git commit. Unter bash/zsh/fish und anderen Unix-Shells verwende einen Heredoc.

Speichere diese als <pkg>, <default-branch>, <gh-available> und <shell> für den restlichen Ablauf.

Schritte

1. Bereinigung (optional)

Zwei Fähigkeiten bereinigen KI-generierten Müll vor dem Commit. Führe beide aus, falls verfügbar:

• deslop: Entfernt KI-Code-Müll aus dem Diff (unnötige Kommentare, defensive Prüfungen auf vertrauenswürdigen Pfaden, any-Casts, tiefe Verschachtelung). Wende es auf den aktuellen Diff gegen den Standard-Branch an.
• unslop: Entfernt KI-Text-Müll aus Prosa (UI-Strings, Kommentare, Commit-Nachrichten, PR-Beschreibungen). Wende es auf jeden Text an, den du in dieser Sitzung geschrieben hast.

Behebe alles, was eine der Fähigkeiten beanstandet, bevor du fortfährst.

Falls eine Fähigkeit nicht installiert ist, überspringe sie nicht einfach stillschweigend. Frage den Benutzer, ob er die fehlende(n) installieren möchte, und biete diese Optionen an. Erwähne, dass beide Fähigkeiten aus dem offiziellen Plugin-Repository von Cursor AI stammen (https://github.com/cursor/plugins), also eine vertrauenswürdige Quelle sind:

• Global (für zukünftige Verwendung in allen Projekten): npx skills add https://github.com/cursor/plugins --skill deslop unslop -g
• Lokal (nur dieses Projekt): npx skills add https://github.com/cursor/plugins --skill deslop unslop
• Überspringen für diesen Durchlauf: Fahre ohne die fehlende(n) Fähigkeit(en) fort. Blockiere den Ablauf nicht wegen einer fehlenden optionalen Abhängigkeit.

Verwende das ask_user_question-Tool, um die Auswahl zu präsentieren. Wenn der Benutzer global oder lokal wählt, führe den Installationsbefehl aus und überprüfe dann erneut, ob die Fähigkeit(en) jetzt verfügbar sind, bevor du sie aufrufst. Wenn die Installation fehlschlägt oder der Benutzer Überspringen wählt, fahre mit dem fort, was verfügbar ist.

2. Arbeit überprüfen

Führe diese in Reihenfolge aus und behebe alle Probleme, bevor du fortfährst. Ersetze <pkg> durch den erkannten Paketmanager. npm benötigt immer run (z.B. npm run format); pnpm/yarn/bun erlauben direkten Aufruf (z.B. pnpm format):

1. <pkg> run format (oder <pkg> format für pnpm/yarn/bun): Automatische Formatierung
2. <pkg> run lint (oder <pkg> lint für pnpm/yarn/bun): Behebe Lint-Fehler in den von dir bearbeiteten Dateien (ignoriere bereits bestehende Probleme in anderen Dateien)
3. <pkg> run typecheck (oder <pkg> typecheck für pnpm/yarn/bun): Muss mit Exit-Code 0 bestehen
4. <pkg> run build (oder <pkg> build für pnpm/yarn/bun): Muss mit Exit-Code 0 bestehen

Wenn ein Skript fehlt (z.B. kein format-Skript), überspringe diesen Schritt und notiere es. Scheitere nicht am gesamten Ablauf wegen eines fehlenden optionalen Skripts. typecheck und build sind erforderlich, falls sie existieren; wenn keines existiert, fahre mit einer Warnung fort.

Fahre erst mit dem Commit fort, wenn die verfügbaren Prüfungen bestanden sind.

Wenn git status nach der Überprüfung sauber ist (nichts gestaged oder ungestaged), melde „nichts zu liefern“ und stoppe. Versuche keinen leeren Commit.

3. Aktuellen Branch bewerten

Führe git branch --show-current aus, um den aktuellen Branch-Namen zu erhalten. Vergleiche ihn mit <default-branch>. Entscheide dann:

• Falls auf <default-branch>: Committen und direkt pushen. Kein PR, kein Merge. Springe zu Schritt 5.
• Falls auf einem anderen Branch: Committen, pushen, einen PR zu <default-branch> erstellen und mergen. Fahre mit Schritt 4 fort.

4. Änderungen überprüfen

Führe git status, git diff und git log --oneline -5 parallel aus, um die Änderungen zu verstehen und den Commit-Stil anzupassen.

5. Stagen und Committen

git add -A, dann committe mit einer conventional-commit-Nachricht (feat/fix/refactor).

Commit-Nachrichtenformat:

<type>: <short description>

<optional body>

Unter bash/zsh/fish und anderen Unix-Shells einen Heredoc verwenden:

git commit -m "$(cat <<'EOF'
type: subject

body
EOF
)"

Unter PowerShell (Windows) funktionieren Heredocs nicht, daher mehrere -m-Flags verwenden:

git commit -m "type: subject" -m "body"

6. Pushen

git push (oder git push -u origin <branch>, falls der Branch noch keinen Upstream hat).

7. Falls auf einem Feature-Branch: PR erstellen und mergen

Falls <gh-available>:

• Schreibe den PR-Text in eine temporäre Datei, dann erstelle den PR mit --body-file (funktioniert in jeder Shell, einschließlich PowerShell):
  • gh pr create --base <default-branch> --head <current-branch> --title "<title>" --body-file <temp-file>
• Lösche die temporäre Datei, nachdem gh pr create zurückgekehrt ist. Lasse sie nicht auf der Festplatte liegen.
• Merge ohne Angabe einer Strategie, damit die Repo-Standardeinstellung des Benutzers greift:
  • gh pr merge <number>

PR-Textformat:

## Zusammenfassung
<Bullet Points>

#### Testplan
- [ ] <Checkliste>

Falls gh nicht verfügbar ist:

• Pushe den Branch (Schritt 6).
• Gib die URL aus, die der Benutzer öffnen soll, um den PR manuell zu erstellen: <repo-url>/compare/<default-branch>...<current-branch>
• Stoppe. Lasse den Benutzer den PR selbst erstellen und mergen. Versuche nicht, ohne gh zu mergen.

8. Den aktuellen Branch am Leben erhalten

Lösche NICHT den Arbeits-Branch nach dem Merge. Er bleibt für das nächste Feature geöffnet.

9. Bestätigung

Melde dem Benutzer die PR-URL (falls zutreffend) und den Merge-/Push-Status.

Konfliktbehandlung

Falls der Feature-Branch hinter <default-branch> zurückliegt, rebase vor dem Pushen:

git fetch origin <default-branch>
git rebase origin/<default-branch>

Löse alle Konflikte auf, dann fahre mit Push + PR + Merge fort.

Hinweise

• Das Ziel ist immer der erkannte <default-branch>, kein fest codierter Name.
• Lösche niemals den Arbeits-Branch nach dem Merge.
• Falls auf <default-branch>, committe und pushe einfach. Kein PR erforderlich.
• Überspringe niemals den Überprüfungsschritt, selbst wenn der Benutzer es eilig hat.
• Der deslop-Schritt ist optional. Falls eine Fähigkeit fehlt, biete an, sie zu installieren (global oder lokal), bevor du zum Überspringen übergehst.