jeffyfung/skills

Commit, Pushen und PR Erstellen

Liefert die Arbeit auf dem aktuellen Feature-Branch: Commit → Push → PR. Das Bestätigungs-Gate (Schritt 6) schützt den Push – überspringe es niemals, auch nicht, wenn es im selben Durchlauf mehrmals hintereinander aufgerufen wird.

Es gibt ein optionales Argument: den Basis-Branch. Ohne dieses wird der Basis-Branch in Schritt 5 aufgelöst.

1. Branch schützen

git branch --show-current. Wenn es main/master ist, stoppen und den Benutzer auffordern, zuerst einen Feature-Branch zu erstellen – niemals direkt nach main committen oder pushen.

2. Commit eingrenzen

git status + git diff. Nur Dateien bereitstellen, die zur aktuellen Aufgabe gehören. Nicht versionierte Dateien, die wie Zwischenergebnisse, generierte Daten oder lokale Test-Fixes aussehen (CSVs, *_results/*, Logs), werden nicht automatisch bereitgestellt – liste sie auf und frage den Benutzer, ob sie eingefügt, ignoriert oder in die gitignore aufgenommen werden sollen.

3. Pre-Commit-Prüfungen

Suche nach den Formatierungs-/Lint-Befehlen des Repos – überprüfe AGENTS.md, CLAUDE.md und README.md (in dieser Reihenfolge) auf einen dokumentierten Formatierer/Linter und führe den dort angegebenen aus. Verwende nicht standardmäßig dotnet format oder eine andere toolspezifische Annahme, wenn keines dieser Dokumente einen benennt – notiere, dass kein Formatierer/Linter dokumentiert ist, und fahre fort.

Wenn die Änderung getesteten Code betrifft und ein schneller, gezielter Testlauf verfügbar ist, führe ihn aus; führe nicht die gesamte Testsuite nur für den Commit aus.

4. Commit-Nachricht

Conventional Commits (feat|fix|test|docs|refactor(scope): summary), angepasst an den Stil, der bereits in git log für dieses Repo vorhanden ist. Textkörper nur, wenn das "Warum" nicht offensichtlich aus dem Diff hervorgeht.

5. Basis-Branch auflösen

Der Basis-Branch ist main, es sei denn, die Arbeit ist gestapelt – auf einem Feature-Branch aufgebaut, der noch nicht gelandet ist, wo ein Basis auf main den darunterliegenden Branch in diesen Diff ziehen würde.

1. Argument gegeben – das ist der Basis-Branch. Verifiziere ihn mit git rev-parse --verify origin/<base>; wenn der Ref nicht existiert, sag es und verwende main.
2. Kein Argument – suche einen Kandidaten. Einer von:
   • Das Gespräch besagt, dass diese Arbeit auf Commits eines anderen Branches basiert.
   • Die Arbeit stammt von einem Ticket, das durch ein anderes Ticket blockiert wird oder von diesem abhängt – der Branch, der diesen Blocker auflöst, ist der Kandidat.
   • git log --oneline origin/main..HEAD zeigt Commits, die diese Aufgabe nicht erstellt hat; git branch -r --contains <sha> gibt an, woher sie kamen.
3. Validiere den Kandidaten. Er muss auf dem Remote existieren, sich vom aktuellen Branch unterscheiden und nicht in git branch -r --merged origin/main enthalten sein – ein Kandidat, der bereits in main zusammengeführt wurde, ist tot.
4. Kein Kandidat oder Validierung fehlgeschlagen – main.

Ein validierter Kandidat ist ein Vorschlag, keine Entscheidung: Biete ihn zusammen mit main am Gate in Schritt 6 an und lass den Benutzer wählen.

6. Bestätigungs-Gate – Push

Zeige dem Benutzer die Commit-Nachricht, git diff --stat (oder den Commit, sobald er erstellt ist) und den Basis-Branch aus Schritt 5 – beide Optionen, wenn Schritt 5 einen Kandidaten gefunden hat. Hole dir die explizite Freigabe vor git push -u origin <branch>. Das Pushen veröffentlicht den Branch – behandle es als Einbahnstraße. Die PR-Erstellung baut auf derselben Bestätigung auf (siehe Schritt 7) und benötigt keine separate Genehmigung.

7. PR öffnen

Prüfe zuerst, ob für diesen Branch bereits ein PR existiert: gh pr list --head <branch> --state all.

• Offener PR gefunden – verwende ihn erneut, erstelle kein Duplikat. Gib seine URL an.
• Zusammengeführter PR gefunden – der Branch wurde bereits einmal eingereicht; stoppe und frage den Benutzer, was er tun möchte, bevor ein weiterer PR erstellt wird (neue Commits seit dem Merge sind ungewöhnlich, nicht der Standardfall).
• Kein vorhandener/zusammengeführter PR – die Push-Bestätigung aus Schritt 6 deckt dies bereits ab: Entwurf des Textkörpers und sofortiges Ausführen von gh pr create --base <base> --head <branch> --title "<title>" --body "<body>", keine zusätzliche Genehmigung erforderlich.

Screenshots für sichtbare UI-Änderungen. Wenn die Änderung etwas verändert, das ein Benutzer sehen kann – ein neues Textfeld, eine geänderte Farbe, neues Layout oder neuen Text, eine neue Seite oder Komponente – mache Screenshots des Happy Paths und der Edge Cases, die die Änderung einführt (leere und Fehlerzustände, langer/überlaufender Text, Responsive vs. Desktop, wo relevant). Lade sie mit gh pr create --attach '<path>#<alt text>' hoch (wiederhole pro Bild; gh pr edit <pr>, um zu einem vorhandenen PR hinzuzufügen). Wenn der Textkörper denselben Pfad referenziert – z. B. ![Happy path](./pr-shots/happy.png) unter einer ## Screenshots-Überschrift – schreibt gh die Referenz an Ort und Stelle zur hochgeladenen URL um; andernfalls werden Anhänge am Ende des Textkörpers angehängt. Dies funktioniert für private Repos: Anhänge sind für jeden mit Repo-Zugriff sichtbar. Halte die Dateien außerhalb des Commits (ein Scratch-Verzeichnis) – sie werden hochgeladen, nicht versioniert. Erfordert gh ≥ 2.99; bei älteren Versionen ziehe die Bilder im Web-UI in den PR-Textkörper. Überspringe dies nur, wenn die Änderung für den Benutzer unsichtbar ist (Logik, Tests, Konfiguration, Dokumentation, CI).

Überprüfe vor dem Entwurf das Repo auf seinen eigenen PR-Beschreibungsstandard – .github/PULL_REQUEST_TEMPLATE.md, .github/pull_request_template.md, docs/* oder CONTRIBUTING.md-Hinweise zu PR-Textkörpern. Eine im Repo dokumentierte Vorlage überschreibt die untenstehende; verwende sie stattdessen.

PR-Textkörper-Vorlage (Fallback – Repo-Standard hat Vorrang, falls vorhanden)

## Zusammenfassung
<was sich geändert hat und warum, 1-6 Sätze>

## Änderungen
- <bemerkenswerte Änderung 1>
- <bemerkenswerte Änderung 2>

## Screenshots
<für sichtbare UI-Änderungen: Happy Path + relevante Randfälle; bei unsichtbaren Änderungen weglassen>

## Designentscheidungen
<bemerkenswerte Kompromisse oder abgelehnte Alternativen – nur bei großen funktionalen Änderungen, siehe unten>

## Tests
<ausgeführte Befehle / wie verifiziert>

## Nacharbeiten
<verschobene Arbeit, oder "Keine">

Wenn der Basis-Branch nicht main ist, beginne die Zusammenfassung mit der Nennung des Basis-Branches und was zuerst landen muss – der Reviewer muss wissen, dass der Diff gestapelt ist und dass der PR nach dem Merge des Basisses erneut auf main ausgerichtet wird.

Füge Designentscheidungen nur ein, wenn der PR neues funktionales Verhalten von nennenswerter Größe einführt (ein neues Modul, einen nicht-trivialen Algorithmus, einen Kompromiss, nach dem ein Reviewer sonst fragen müsste) – lasse den Abschnitt bei Dokumentation/Konfiguration/Chores/kleinen Korrekturen komplett weg, anstatt ihn leer zu lassen.

8. Review-Übersicht (nur bei umfangreichen Änderungen)

Erstelle eine eigenständige HTML-Übersicht, wenn eine der folgenden Bedingungen zutrifft:

• der Diff berührt mehrere verschiedene Nicht-UI-Module;
• er ändert ein Datenbankschema (Migrationen, Tabellen, Spalten, Indizes, Constraints);
• es handelt sich um eine große End-to-End-Funktion (einen neuen Ablauf, der mehrere Schichten durchquert).

Überspringe sie bei Dokumentation, Konfiguration, Routineaufgaben, kleinen Korrekturen und Änderungen, die auf ein Modul oder nur auf die UI beschränkt sind. Die Übersicht dient dazu, eine Review zu verkürzen – generiere sie nicht automatisch für jeden PR.

Schreibe eine Datei, pr-walkthrough.html, in einem Scratch-Verzeichnis außerhalb des Commits (stage sie niemals), öffne sie lokal mit open pr-walkthrough.html und gib dem Benutzer den Pfad. Hoste sie nicht, hänge sie nicht an und versioniere sie nicht.

Strukturiere sie als Abschnitte unter nativen <details>/<summary>-einklappbaren Überschriften – der erste Abschnitt offen, der Rest zugeklappt – damit der Reviewer die Überschriften überfliegen und nur das aufklappen kann, was er braucht. Kein JavaScript.

Geschrieben für einen Reviewer, der den Diff nicht gelesen hat:

• Was und warum – die Änderung in ein paar Sätzen, plus die Reihenfolge, in der der Diff gelesen werden sollte.
• Änderungskarte – welche Module berührt werden und wie sie zusammenhängen. Ein Diagramm, keine Dateiliste.
• Mechanik – jedes nicht offensichtliche Stück Logik oder Datenfluss, erklärt neben dem Code, den es benennt (path:line).
• Schemaänderungen – Vorher/Nachher-Tabellenformen, der Migrationspfad und das Risiko (Sperren, Backfill, Rollback).
• Knifflige Teile – die Teile, nach denen ein Reviewer sonst fragen müsste, und worauf zu achten ist.

Diagramme: Inline-SVG, handgeschrieben und an den Inhalt angepasst, für Modulabhängigkeiten, Anfrage-/Sequenzfluss und Schema. Halte die Datei in sich geschlossen – kein externes JS, CSS oder Bild-URLs, damit sie offline geöffnet werden kann. Verwende gerenderte Bilder oder Screenshots nur, wenn das zu erklärende Element visuell ist.

9. Bericht

Gib dem Benutzer die PR-URL und den Basis-Branch, den sie ansteuert. Sage klar, was committet, gepusht und geöffnet wurde – ohne Umschweife.