auto-pr-pipeline

name: auto-pr-pipeline description: | Fuehrt einen repo- und policy-bewussten Delivery-Workflow fuer bestehende Code-Aenderungen aus: Zustand erfassen, passende lokale Checks auswaehlen, selektiv committen, pushen, Draft-PR oder Ready-PR erstellen/aktualisieren, CI und Reviews verarbeiten, Auto-Merge oder Merge Queue nutzen und nur bei echten Hochrisiko-Blockern anhalten.

Aktivieren bei:

• /auto-pr
• /ship-it
• /pr-pipeline
• "mach einen PR"
• "push und merge"
• "bring das auf main"
• "mach das fertig"
• "arbeite die review kommentare ein und mach fertig"
• "aktualisiere den bestehenden PR"
• "aktiviere auto-merge"
• "stell den PR in die merge queue"
• Wenn Code bereits geaendert ist und der Rest des Wegs bis zum Merge professionell abgearbeitet werden soll
• Wenn bestehende Commits, offener PR oder halb fertiger Zustand intelligent fortgesetzt statt stumpf neu begonnen werden sollen

Arbeitsstil: - state-driven statt starrer Phasen - repo-native Checks statt generischer Befehle - pragmatische Commit-Strategie statt Dogmatismus - Auto-Merge oder Merge Queue wenn moeglich - stoppt nur bei schwerwiegenden Problemen und liefert dann Optionen triggers: - /auto-pr - /ship-it - /pr-pipeline - PR erstellen - commit und push - mach einen PR - merge meinen Branch - auto-PR - ship it - alles durchlaufen lassen - PR bis zum Merge - vollstaendiger PR-Workflow - push und merge - von commit bis merge - teste und merge das - mach das fertig - bring das auf main - schick das raus - review kommentare einarbeiten - bestehenden PR aktualisieren - auto-merge aktivieren - merge queue

Auto-PR-Pipeline v3.0

Arbeite nicht wie ein starres Script. Arbeite wie ein senioriger Delivery-Agent, der zuerst den Zustand, dann die Repo-Policy und erst danach die naechste Aktion bestimmt.

Mission

Bringe vorhandene Code-Aenderungen sicher und professionell bis zu einem guten Endzustand:

• sauber validiert
• passend committet
• korrekt gepusht
• als Draft-PR oder Ready-PR sauber dokumentiert
• gegen CI, Reviews und Branch-Regeln abgearbeitet
• gemerged oder sauber bewaffnet fuer Auto-Merge / Merge Queue

Wenn der sicherste Endzustand nicht "sofort mergen" ist, ist ein sauber vorbereiteter Draft-PR oder ein armed Auto-Merge ein guter Abschluss.

Kernprinzipien

1. Repo-Policy zuerst. Lies Branch-Regeln, Merge-Optionen, Review-Anforderungen, CI, CODEOWNERS, PR-Templates und vorhandene Workflows bevor du ueber Commit, Push oder Merge entscheidest.
2. State-driven arbeiten. Entscheide nicht anhand einer festen Phase, sondern anhand des aktuellen Repo-Zustands.
3. Kleine Batches bevorzugen. Wenn die Aenderung zu gross oder gemischt ist, splitte oder stoppe frueh statt unklar weiterzumergen.
4. Repo-native Checks bevorzugen. Rate keine Standardbefehle blind. Nutze die Checks, die dieses Repo wirklich verwendet.
5. Veroeffentlichte History respektieren. Bereits gepushte oder reviewte Commits werden nicht leichtfertig umgeschrieben.
6. Plattform-Automation nutzen. Auto-Merge, Merge Queue, Required Checks und Draft/Ready sind besser als eigenes Dauer-Babysitting.
7. Nur echte Hochrisiko-Probleme blockieren. Stoppe nicht wegen kleiner Reibung. Stoppe bei hohem Risiko und liefere dann Optionen.
8. Immer resume-faehig bleiben. Jeder neue Aufruf beginnt mit frischer Zustandserfassung. Ueberspringe Erledigtes und mache sinnvoll weiter.
9. Arbeit retten statt stumpf abbrechen. Wenn auf dem falschen Branch gearbeitet wurde, sichere die Arbeit in einen passenden Feature-Branch statt nur zu blockieren, sofern das risikoarm moeglich ist.

Phase 0: Snapshot bauen

Baue zuerst einen belastbaren Snapshot. Ohne Snapshot keine Aktion.

Ermittle mindestens:

• aktueller Branch, Upstream, ahead/behind, Default-Branch
• liegt die Arbeit versehentlich direkt auf main / master / Release-Branch
• staged, unstaged, untracked, lokale Commits seit Base
• existiert bereits ein PR fuer den Branch, ist er Draft oder Ready, was ist die URL
• Review-Entscheidung, offene Threads, requested changes, neue Kommentare
• Status Checks, Deployments, mergeable, Auto-Merge, Merge Queue
• Branch-Protection / Rulesets soweit mit den vorhandenen Tools sichtbar
• Repo-Konventionen fuer Commits, Merge-Methode und PR-Body
• relevante Dateien fuer Build, Tests, CI, Workflows, CODEOWNERS und PR-Templates

Lies dafuer gezielt die Repo-Dateien und GitHub-Metadaten.

Referenzen laden: Bevor du mit Phase 0 beginnst, lies die folgenden Referenz-Dateien fuer die konkreten Entscheidungsbaeume:

• references/repo-detection.md - Repo-Struktur, Git-Zustand, Policy, Checks
• references/commit-strategy.md - Commit-Entscheidungslogik nach Fall A-E
• references/review-and-merge.md - Review-Prioritaet, Merge-Methode, Flaky-Handling
• references/blockers-and-recovery.md - Hard/Soft Blocker, Recovery-Budget, Ausgabeformat

Die Referenzen enthalten die detaillierten Regeln. Dieses Hauptdokument gibt die Strategie vor.

Der Arbeitsmodus ist eine Decision Engine

Nach dem Snapshot klassifiziere den Zustand:

• worktree_state: clean, dirty, mixed, risky
• history_state: no-local-commit, local-unpushed, published, reviewed
• pr_state: none, draft, ready, waiting-checks, waiting-review, mergeable, blocked
• policy_state: unrestricted, protected, queue-required, auto-merge-possible, signed-commits-required Leite aus diesen Zustaenden ein risk_level ab: low, medium oder high. Das Risk-Level bestimmt, ob autonom weitergearbeitet wird oder ein Stopp noetig ist (siehe Abschnitt "Harte Stopps nur bei Hochrisiko-Faellen").

Waehle dann die naechste Aktion nach diesem Muster:

Wenn mehrere Aktionen moeglich sind, waehle die mit dem geringsten Risiko und der kleinsten History-Verzerrung.

Lokale Validierung

Fuehre nicht pauschal npm install, npm test oder generische Befehle aus. Erkenne zuerst:

• Package-Manager
• Task-Runner
• Test-Frameworks
• Linter / Formatter
• Build-Tools
• CI-Definition
• Security-Checks

Nutze dann eine gestufte Strategie:

1. Fast guardrails fuer schnelle Fehlererkennung
2. Repo-kritische Kernchecks passend zu den Required Checks
3. Nur wenn sinnvoll aufwaendigere oder langsame Checks

Mutiere die Dependency-Landschaft nicht ohne Grund. Installiere oder regeneriere nur dann, wenn es fuer eine fundierte Verifikation noetig ist oder das Repo diesen Schritt klar vorgibt.

Wenn Install-, Build- oder Codegen-Schritte neue Lockfiles oder Build-Artefakte aendern, entscheide aktiv:

• gehoeren diese Aenderungen fachlich zur Aufgabe oder zur Repo-Konvention, dann duerfen sie mit
• sind sie nur Nebenwirkung eines lokalen Checks, dann nicht automatisch mitcommitten

Details stehen in repo-detection.md.

Commit- und History-Strategie

Arbeite pragmatisch statt dogmatisch:

• Committe nur Dateien, die zur Aufgabe gehoeren
• Lasse unrelated User-Aenderungen unberuehrt
• Nutze git add . nicht blind
• NACH JEDEM COMMIT: Fuehre git status --short und git diff --stat aus. Wenn Modified oder Untracked Files uebrig bleiben, entscheide explizit: stage+commit oder bewusst auslassen mit Dokumentation warum. (Post-Mortem PR #503: selektives git add liess Workflow-Datei im Working Tree zurueck)
• Folge zuerst der Repo-eigenen Commit-Konvention
• Nutze Conventional Commits nur wenn das Repo sie sichtbar verwendet oder der User es will
• Bevorzuge neue Follow-up-Commits gegenueber History-Rewrites auf bereits gepushten oder reviewten Aenderungen
• Nutze Amend nur fuer lokale, unpublizierte, klar zusammengehoerige Aenderungen
• Wenn das Repo squash merge nutzt, optimiere auf eine saubere PR und sinnvolle Zwischen-Commits, nicht auf perfekte Branch-History
• Wenn versehentlich direkt auf main / master gearbeitet wurde und die Arbeit noch nicht publiziert ist, verschiebe sie zuerst auf einen Feature-Branch und setze dort fort

Die konkrete Entscheidungslogik steht in commit-strategy.md.

PR-Strategie

Draft-First-Prinzip

Erstelle PRs immer als Draft (gh pr create --draft). Das spart CI-Minuten (Workflows und externe Reviews laufen nur auf non-Draft PRs) und erzwingt Self-Review vor externem Feedback.

Der Ablauf ist:

1. Draft PR erstellen -- macht Arbeit sichtbar ohne CI oder externe Reviews auszuloesen
2. Self-Review auf dem Draft (siehe Self-Review-Checkliste unten)
3. Draft -> Ready (gh pr ready) -- erst wenn Self-Review abgeschlossen und lokale Tests gruen
4. CI + externe Reviews laufen -- Claude Review wird erst jetzt getriggert
5. Review-Findings bearbeiten -- wie bisher

Ausnahme: --ready Flag oder expliziter User-Wunsch erlaubt direktes Ready-PR.

Self-Review-Checkliste

Vor gh pr ready muessen diese Punkte erfuellt sein:

• Eigenen Diff gelesen (git diff main...HEAD oder PR-Diff)
• Keine offensichtlichen Bugs, fehlende Error-Handling, ungetestete Pfade
• Keine Secrets, Debug-Reste, TODO/FIXME als Implementation
• Commit-Messages sind aussagekraeftig (Wirkung, nicht nur Dateien)
• PR-Beschreibung enthaelt: Nutzer-/Systemwirkung, Risiko, Validierung
• Lokale repo-native Checks gruen (Tests, Lint, Build)

Fallback ohne claude review CLI: manueller Diff-Review reicht, die Checkliste gilt trotzdem.

PR-State-Machine

Bestehende PRs

• Bestehender Draft: weiterarbeiten, nicht neu erstellen
• Bestehender Ready-PR: wenn neuer Blocker auftaucht, gh pr ready --undo erwaegen
• Reopen-Fall: nach Reopen ist der PR wieder Ready, Draft-Filter greift nicht

PR-Body und Template

Beschreibe nicht nur Dateiaenderungen. Enthalte:

• Nutzer- oder Systemwirkung
• Wichtigstes Risiko
• Wichtigste Validierung
• Offene Punkte

Wenn ein PR-Template existiert, verwende es. Wenn das Repo Issue-Links oder Release-Notes erwartet, beruecksichtige das.

Review-, CI- und Merge-Strategie

Arbeite nach Prioritaet:

1. failing required checks
2. requested changes von Menschen
3. Security- und Dependency-Signale
4. fachliche Bugs oder fehlende Tests
5. klare Maintainability-Probleme
6. Stil, Nits, Kosmetik

Batche zusammengehoerige Review-Fixes. Push nicht fuer jeden Kommentar einzeln.

Wenn Checks flaky wirken:

• rerunne einen bekannten oder plausiblen Infra-Flake begrenzt
• aendere nicht vorschnell Code, nur um ein instabiles Signal "gruen zu raten"
• wenn ein required Check wiederholt flaky oder infrastrukturell blockiert ist, dokumentiere das und entscheide zwischen Auto-Merge-Warten, Queue-Warten oder Blocker-Meldung

Nutze Plattform-Features bewusst:

• Auto-Merge wenn nur noch formale Gruen-Checks / Approvals fehlen
• Merge Queue wenn der Zielbranch sie erfordert oder anbietet
• Draft -> Ready wenn der Zustand reviewbar ist
• Thread-Resolution nur wenn der Punkt wirklich bearbeitet oder sauber begruendet wurde

Details stehen in review-and-merge.md.

Harte Stopps nur bei Hochrisiko-Faellen

Unterbrich autonomes Weiterarbeiten nur bei schwerwiegenden Problemen, zum Beispiel:

• Secret, Token, Key oder Push-Protection-Fund
• unklare Datenverlust- oder Migrationsgefahr
• Branch-Protection / Auth / Berechtigungen verhindern den noetigen Schritt
• Merge-Konflikt oder Review-Forderung braucht eine fachliche Richtungsentscheidung
• mehrere unrelated Change-Sets lassen sich nicht sicher trennen, besonders wenn dieselben Dateien betroffen sind
• required checks schlagen fehl und die Ursache ist nach fokussiertem Versuch nicht belastbar klar
• Workflow- oder Infra-Aenderung waere ohne weitere Absicherung riskant
• Base-Branch oder Zielrepo ist in einem Fork-/Upstream-Setup nicht belastbar klar

Dann liefere nicht nur den Fehler, sondern immer:

• Blocker
• Beobachtete Fakten
• Warum autonomes Weiterarbeiten riskant waere
• Option A
• Option B
• Option C
• Empfehlung

Die genaue Matrix steht in blockers-and-recovery.md.

Resume-Verhalten

Dieser Skill muss jederzeit erneut aufgerufen werden koennen.

Deshalb gilt:

• Starte immer mit einem frischen Snapshot
• Erkenne vorhandene Commits, vorhandenen PR, vorhandene Reviews und vorhandene CI-Laeufe
• Ueberschreibe keine frueheren Entscheidungen blind
• Wenn Auto-Merge oder Queue bereits armed ist, greife nur bei neuen Problemen ein
• Wenn bereits Commits existieren, entscheide aktiv zwischen nichts tun, push, amend, follow-up commit
• Wenn bereits ein PR offen ist, arbeite auf diesem PR weiter, ausser es gibt einen sehr guten Grund fuer einen neuen

Abschlussformate

Wenn erfolgreich abgeschlossen

Liefere eine kurze, anwendungsbezogene Zusammenfassung:

• Was wurde fuer Nutzer oder System erreicht
• Welche relevanten Probleme wurden unterwegs entdeckt und behoben
• Was ist noch offen
• PR-Link, Branch, Merge-Status, wichtigste Validierungen

Wenn nicht final gemerged, aber sauber vorbereitet

Sage klar, ob der Zustand jetzt einer dieser Faelle ist:

• Draft PR erstellt -- Self-Review steht noch aus, dann gh pr ready
• Draft PR nach Self-Review auf Ready gesetzt -- wartet auf CI + Claude Review
• Ready PR zurueck auf Draft gesetzt -- Blocker wird bearbeitet
• Ready PR offen und wartet auf Reviews
• Auto-Merge armed
• Merge Queue armed
• Warten auf externe Freigabe / Berechtigung / Input

Wenn blockiert

Nutze das Blocker-Format aus blockers-and-recovery.md.

Claude-spezifische Hinweise

• Nutze bevorzugt vorhandene Repo-Tools und GitHub CLI.
• Formuliere Entscheidungen explizit, statt nur Befehle aneinanderzureihen.
• Wenn Shell-Syntax vom System abhaengt, passe sie an die tatsaechliche Shell an statt Bash blind anzunehmen.
• Halte den User ueber groessere Richtungswechsel auf dem Laufenden, aber stoppe nur bei echten Hochrisiko-Themen.