PR Babysitter

Was macht PR Babysitter?

Ziel

Überwachen Sie einen PR persistent, bis einer dieser Endzustände eintritt:

• Der PR wird gemergt oder geschlossen.
• Eine Situation erfordert Benutzerhilfe (z. B. CI-Infrastrukturprobleme, wiederholte flaky Fehler nach Erschöpfung des Wiederholungsbudgets, Berechtigungsprobleme oder Mehrdeutigkeiten, die nicht sicher aufgelöst werden können).
• Optionaler Übergabe-Meilenstein: Der PR ist derzeit grün + mergebar + review-sauber. Behandeln Sie dies als Fortschrittszustand, nicht als Stopp für die Überwachung, damit spät eintreffende Review-Kommentare zeitnah angezeigt werden, solange der PR offen bleibt.

Stoppen Sie nicht nur, weil eine einzelne Momentaufnahme idle zurückgibt, während Prüfungen noch ausstehen.

Eingaben

Akzeptieren Sie Folgendes:

• Kein PR-Argument: PR aus dem aktuellen Branch ableiten (--pr auto)
• PR-Nummer
• PR-URL

Kern-Workflow

1. Wenn der Benutzer darum bittet, einen PR zu "überwachen"/"beobachten"/"babysitten", starten Sie den Überwachungsmodus (--watch), es sei denn, Sie führen absichtlich eine einmalige Diagnose-Momentaufnahme durch.
2. Führen Sie das Überwachungsskript aus, um den PR-/Review-/CI-Zustand zu erfassen (oder konsumieren Sie jede gestreamte Momentaufnahme von --watch).
3. Untersuchen Sie die actions-Liste in der JSON-Antwort.
4. Wenn diagnose_ci_failure vorhanden ist, untersuchen Sie die Logs der fehlgeschlagenen Läufe und klassifizieren Sie den Fehler.
5. Wenn der Fehler wahrscheinlich durch den aktuellen Branch verursacht wird, patchen Sie Code lokal, committen und pushen Sie. Patchen Sie keine zufälligen flaky Tests, CI-Infrastruktur, Abhängigkeitsausfälle, Runner-Probleme oder andere Fehler, die nicht mit dem Branch zusammenhängen.
6. Wenn process_review_comment vorhanden ist, untersuchen Sie die angezeigten veröffentlichten Review-Elemente und entscheiden Sie, ob Sie sie bearbeiten.
7. Wenn ein Review-Element umsetzbar und korrekt ist, patchen, committen und pushen Sie Code lokal und lösen Sie dann den zugehörigen Review-Thread auf, wenn dies durch die Richtlinie zur Zustandsänderung auf GitHub unten erlaubt ist.
8. Posten Sie keine Antworten auf von Menschen verfasste Review-Kommentare/Threads, es sei denn, der Benutzer bestätigt die genaue Antwort explizit. Wenn ein menschliches Review-Element nicht umsetzbar, bereits behandelt oder nicht gültig ist, zeigen Sie das Element und die empfohlene Antwort dem Benutzer an, anstatt auf GitHub zu antworten.
9. Wenn der Fehler wahrscheinlich flaky/nicht zusammenhängend ist und retry_failed_checks vorhanden ist, führen Sie fehlgeschlagene Jobs mit --retry-failed-now erneut aus.
10. Wenn sowohl umsetzbares Review-Feedback als auch retry_failed_checks vorhanden sind, priorisieren Sie zuerst das Review-Feedback; ein neuer Commit wird CI erneut auslösen, daher vermeiden Sie das erneute Ausführen von flaky Prüfungen auf dem alten SHA, es sei denn, Sie verschieben die Review-Änderung absichtlich.
11. Suchen Sie in jeder Schleife nach neu aufgetauchtem Review-Feedback, bevor Sie auf CI-Fehler oder den Merge-Zustand reagieren, und überprüfen Sie dann den Merge-/Konfliktstatus (z. B. über gh pr view) zusammen mit CI.
12. Kehren Sie nach jedem Push oder erneuten Ausführen sofort zu Schritt 1 zurück und setzen Sie die Abfrage auf dem aktualisierten SHA/Zustand fort.
13. Wenn Sie vor dem Pausieren zum Patchen/Commiten/Pushen --watch verwendet haben, starten Sie --watch in derselben Runde sofort nach dem Push neu (warten Sie nicht, bis der Benutzer die Fähigkeit erneut aufruft).
14. Wiederholen Sie die Abfrage, bis stop_pr_closed erscheint oder ein Blockierer, der Benutzerhilfe erfordert, erreicht wird. Ein grüner + review-sauberer + mergebarer PR ist ein Fortschritts-Meilenstein, kein Grund, die Überwachung zu stoppen, solange der PR noch offen ist.
15. Behalten Sie die Terminal-/Sitzungskontrolle: Solange das Babysitten aktiv ist, konsumieren Sie weiterhin die Ausgabe des Überwachungsprogramms in derselben Runde; lassen Sie keinen losgelösten --watch-Prozess laufen und beenden Sie die Runde, als ob die Überwachung abgeschlossen wäre.

Befehle

Einmalige Momentaufnahme

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --once

Kontinuierliche Überwachung (JSONL)

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --watch

Flaky-Wiederholungszyklus auslösen (nur wenn Überwachung anzeigt)

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --retry-failed-now

Explizites PR-Ziel

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr <number-or-url> --once

CI-Fehlerklassifikation

Verwenden Sie gh-Befehle, um fehlgeschlagene Läufe zu untersuchen, bevor Sie sich für eine Wiederholung entscheiden.

• gh run view <run-id> --json jobs,name,workflowName,conclusion,status,url,headSha
• gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs -X GET -f per_page=100
• gh api repos/<owner>/<repo>/actions/jobs/<job-id>/logs > /tmp/codex-gh-job-<job-id>-logs.zip
• gh run view <run-id> --log-failed als Fallback, nachdem der gesamte Workflow-Lauf abgeschlossen ist

gh run view --log-failed ist auf Workflow-Lauf-Ebene und zeigt möglicherweise keine Logs fehlgeschlagener Jobs an, bis der gesamte Lauf abgeschlossen ist. Für eine schnellere Diagnose fragen Sie zuerst die Jobs des Laufs ab, und sobald ein bestimmter Job fehlgeschlagen ist, rufen Sie die Logs dieses Jobs direkt vom Actions-Job-Logs-Endpunkt ab. Der Überwacher enthält eine failed_jobs-Liste mit der job_id und dem logs_endpoint jedes fehlgeschlagenen Jobs, wenn GitHub einen bereitstellt.

Bevorzugen Sie die Behandlung von Fehlern als branchbezogen, wenn die Logs fehlgeschlagener Jobs auf geänderten Code verweisen (Kompilierung/Tests/Linting/Typechecking/Snapshots/Statische Analyse in betroffenen Bereichen).

Bevorzugen Sie die Behandlung von Fehlern als flaky/nicht zusammenhängend, wenn die Logs vorübergehende Infrastruktur-/externe Probleme zeigen (Timeouts, Runner-Bereitstellungsfehler, Registry-/Netzwerkausfälle, GitHub-Actions-Infrastrukturfehler).

Versuchen Sie nicht, flaky/nicht zusammenhängende Fehler zu beheben, indem Sie Tests, Build-Skripte, CI-Konfiguration, Abhängigkeits-Pins oder infrastrukturnahen Code ändern, es sei denn, die Logs verknüpfen den Fehler eindeutig mit dem PR-Branch. Für flaky/nicht zusammenhängende Fehler wiederholen Sie nur, wenn der Überwacher retry_failed_checks empfiehlt; andernfalls warten Sie oder stoppen Sie, um Benutzerhilfe zu erhalten.

Wenn die Klassifikation mehrdeutig ist, führen Sie einen manuellen Diagnoseversuch durch, bevor Sie sich für eine Wiederholung entscheiden.

Lesen Sie .codex/skills/babysit-pr/references/heuristics.md für eine prägnante Checkliste.

Behandlung von Review-Kommentaren

Der Überwacher zeigt Review-Elemente an von:

• PR-Issue-Kommentaren
• Inline-Review-Kommentaren
• Review-Einreichungen (COMMENT / APPROVED / CHANGES_REQUESTED)

Handeln Sie nur bei veröffentlichtem Feedback. Ignorieren Sie Review-Einreichungen im PENDING-Status von GitHub und Inline-Kommentare, die an diese ausstehenden Reviews angehängt sind. Markieren Sie ausstehendes Review-Feedback nicht als gesehen; es sollte berechtigt sein, nach der Einreichung des Reviews durch den Reviewer angezeigt zu werden.

Es zeigt absichtlich Feedback des Codex-Reviewer-Bots (z. B. Kommentare/Reviews von chatgpt-codex-connector[bot]) zusätzlich zu menschlichem Reviewer-Feedback an. Das meiste nicht zusammenhängende Bot-Rauschen sollte trotzdem ignoriert werden. Aus Sicherheitsgründen zeigt der Überwacher nur vertrauenswürdige menschliche Review-Autoren (z. B. Repo-OWNER/MEMBER/COLLABORATOR, plus den authentifizierten Operator) und genehmigte Review-Bots wie Codex automatisch an. Bei einer frischen Überwacher-Statusdatei können vorhandene, nicht behandelte, veröffentlichte Review-Feedbacks sofort angezeigt werden (nicht nur Kommentare, die nach Beginn der Überwachung eintreffen). Dies ist beabsichtigt, damit bereits offene Review-Kommentare nicht übersehen werden.

Wenn Sie mit einem Kommentar übereinstimmen und er umsetzbar ist:

1. Patchen Sie Code lokal.
2. Committen Sie mit codex: address PR review feedback (#<n>).
3. Pushen Sie in den PR-Head-Branch.
4. Lösen Sie nach erfolgreichem Push den zugehörigen GitHub-Review-Thread auf, wenn dies durch die Richtlinie zur Zustandsänderung auf GitHub unten erlaubt ist.
5. Setzen Sie die Überwachung auf dem neuen SHA sofort fort (stoppen Sie nicht nach dem Melden des Pushs).
6. Wenn die Überwachung im --watch-Modus lief, starten Sie --watch sofort nach dem Push in derselben Runde neu; warten Sie nicht, bis der Benutzer erneut fragt.

Posten Sie keine Antworten auf von Menschen verfasste GitHub-Review-Kommentare/Threads automatisch. Wenn Sie mit einem menschlichen Kommentar nicht einverstanden sind, glauben, dass er nicht umsetzbar/bereits behandelt ist, oder eine Frage beantworten müssen, melden Sie das Element dem Benutzer mit einer vorgeschlagenen Antwort und warten Sie auf explizite Bestätigung, bevor Sie etwas auf GitHub posten. Wenn der Benutzer eine Antwort genehmigt, stellen Sie ihr [codex] voran, damit klar ist, dass die Antwort automatisiert ist und nicht vom menschlichen Benutzer stammt. Wenn der Überwacher später Ihre eigene genehmigte Antwort anzeigt, weil der authentifizierte Operator als vertrauenswürdiger Review-Autor behandelt wird, behandeln Sie dieses selbst verfasste Element als bereits erledigt und antworten Sie nicht erneut. Wenn ein Code-Review-Kommentar/Thread in GitHub bereits als "gelöst" markiert ist, behandeln Sie ihn als nicht umsetzbar und ignorieren Sie ihn sicher, es sei denn, es taucht neues, ungelöstes Follow-up-Feedback auf.

Richtlinie zur Zustandsänderung auf GitHub

Sie können jeden PR-Zustand lesen, den Sie für die Überwachung benötigen. Schreibvorgänge müssen dieser Richtlinie entsprechen.

Sie können PRs pushen, um den überprüften Code zu aktualisieren oder um CI-Neustarts wie oben beschrieben zu erzwingen.

Sie können Review-Kommentar-Threads von der Person, die das Babysitten angefordert hat, oder vom Codex-Review-Bot auflösen. Lassen Sie beim Auflösen einen Kommentar mit dem Präfix [from Codex]: und erklären Sie, welche Änderungen Sie vorgenommen haben und welcher Commit sie enthält. Berühren Sie keine Review-Threads, wenn andere Menschen als der Benutzer, der das Babysitten angefordert hat, beteiligt waren.

Bevor Sie Änderungen vornehmen, rufen Sie den PR-Zustand selbst ab, anstatt sich auf die Ausgabe des PR-Überwachungsskripts zu verlassen.

Sofern nicht ausdrücklich darum gebeten, tun Sie Folgendes nicht:

• Kommentieren Sie nicht die Review-Threads anderer Menschen, kommunizieren Sie stattdessen im Chat mit dem Benutzer
• Lösen Sie keine Review-Threads von Menschen außer dem Benutzer auf
• Interagieren Sie nicht mit anderen Menschen als dem Benutzer
• Markieren Sie PRs nicht als Entwürfe oder als bereit zur Überprüfung
• Schließen oder öffnen Sie PRs nicht erneut

Handeln Sie im Allgemeinen niemals auf GitHub in einer Weise, die es schwer machen würde zu sagen, ob Sie oder der Benutzer etwas getan haben, das für andere Menschen sichtbar ist. Fragen Sie im Zweifelsfall den Benutzer im Chat um Klärung.

Git-Sicherheitsregeln

• Arbeiten Sie nur am PR-Head-Branch.
• Vermeiden Sie destruktive Git-Befehle.
• Wechseln Sie nicht die Branches, es sei denn, es ist notwendig, um den Kontext wiederherzustellen.
• Überprüfen Sie vor dem Bearbeiten auf nicht zusammenhängende, nicht committete Änderungen. Wenn vorhanden, stoppen Sie und fragen Sie den Benutzer.
• Nach jeder erfolgreichen Korrektur committen und git push ausführen, dann den Überwacher erneut starten.
• Wenn Sie eine laufende --watch-Sitzung unterbrochen haben, um die Korrektur vorzunehmen, starten Sie --watch sofort nach dem Push in derselben Runde neu.
• Führen Sie nicht mehrere gleichzeitige --watch-Prozesse für denselben PR/dieselbe Statusdatei aus; behalten Sie eine Überwacher-Sitzung aktiv und verwenden Sie sie wieder, bis sie stoppt oder Sie sie absichtlich neu starten.
• Ein Push ist kein Endzustand; setzen Sie die Überwachungsschleife fort, es sei denn, eine strikte Stoppbedingung ist erfüllt.

Standard-Commit-Nachrichten:

• codex: fix CI failure on PR #<n>
• codex: address PR review feedback (#<n>)

Überwachungsschleifenmuster

Verwenden Sie diese Schleife in einer Live-Codex-Sitzung:

1. Führen Sie --once aus.
2. Lesen Sie actions.
3. Überprüfen Sie zuerst, ob der PR jetzt gemergt oder anderweitig geschlossen ist; wenn ja, melden Sie diesen Endzustand und stoppen Sie die Abfrage sofort.
4. Überprüfen Sie die CI-Zusammenfassung, neue Review-Elemente und den Merge-/Konfliktstatus.
5. Diagnostizieren Sie CI-Fehler und klassifizieren Sie sie als branchbezogen vs. flaky/nicht zusammenhängend. Wenn der Gesamtlauf noch aussteht, aber failed_jobs bereits einen fehlgeschlagenen Job enthält, rufen Sie die Logs dieses Jobs ab und diagnostizieren Sie sofort, anstatt zu warten, bis der gesamte Workflow-Lauf abgeschlossen ist. Patchen Sie nur, wenn der Fehler branchbezogen ist.
6. Patchen/Commiten/Pushen Sie für jedes angezeigte Review-Element eines anderen Autors, wenn es umsetzbar ist, und lösen Sie es dann auf, wenn dies durch die Richtlinie zur Zustandsänderung auf GitHub oben erlaubt ist. Wenn es nicht umsetzbar, bereits behandelt ist oder eine schriftliche Antwort erfordert, zeigen Sie es dem Benutzer mit einer vorgeschlagenen Antwort an, anstatt es automatisch zu posten. Wenn eine spätere Momentaufnahme Ihre eigene genehmigte Antwort anzeigt, behandeln Sie sie als informativ und fahren Sie fort, ohne erneut zu antworten.
7. Verarbeiten Sie umsetzbare Review-Kommentare vor flaky Wiederholungen, wenn beide vorhanden sind; wenn eine Review-Korrektur einen Commit erfordert, pushen Sie ihn und überspringen Sie das erneute Ausführen fehlgeschlagener Prüfungen auf dem alten SHA.
8. Wiederholen Sie fehlgeschlagene Prüfungen nur, wenn retry_failed_checks vorhanden ist und Sie nicht gerade dabei sind, den aktuellen SHA durch einen Review-/CI-Korrektur-Commit zu ersetzen. Nehmen Sie keine Code-Änderungen für nicht zusammenhängende Flakes oder Infrastrukturfehler vor, nur um CI grün zu bekommen.
9. Wenn Sie einen Commit gepusht, einen berechtigten Review-Thread aufgelöst oder eine Wiederholung ausgelöst haben, melden Sie die Aktion kurz und setzen Sie die Abfrage fort (stoppen Sie nicht). Wenn ein menschlicher Review-Kommentar eine schriftliche GitHub-Antwort benötigt, stoppen Sie und fragen Sie nach Bestätigung, bevor Sie posten.
10. Starten Sie nach einem Review-Korrektur-Push proaktiv die kontinuierliche Überwachung (--watch) in derselben Runde neu, es sei denn, eine strikte Stoppbedingung wurde bereits erreicht.
11. Wenn alles erfolgreich ist, mergebar ist, nicht durch eine erforderliche Review-Genehmigung blockiert wird und keine unbehandelten Review-Elemente vorhanden sind, melden Sie, dass der PR derzeit bereit zum Mergen ist, aber lassen Sie den Überwacher laufen, damit neue Review-Kommentare schnell angezeigt werden, solange der PR offen bleibt.
12. Wenn ein Problem blockiert, das Benutzerhilfe erfordert (Infrastrukturausfall, erschöpfte flaky Wiederholungen, unklare Reviewer-Anfrage, Berechtigungen), melden Sie den Blockierer und stoppen Sie.
13. Andernfalls schlafen Sie gemäß der unten stehenden Abfragerate und wiederholen Sie den Vorgang.

Wenn der Benutzer explizit darum bittet, einen PR zu überwachen/beobachten/babysitten, bevorzugen Sie --watch, damit die Abfrage autonom in einem Befehl fortgesetzt wird. Verwenden Sie wiederholte --once-Momentaufnahmen nur zum Debuggen, für lokale Tests oder wenn der Benutzer explizit um eine einmalige Überprüfung bittet. Stoppen Sie nicht, um den Benutzer zu fragen, ob die Abfrage fortgesetzt werden soll; fahren Sie autonom fort, bis eine strikte Stoppbedingung erfüllt ist oder der Benutzer explizit unterbricht. Geben Sie die Kontrolle nicht nach einem Review-Korrektur-Push einfach an den Benutzer zurück, nur weil ein neuer SHA erstellt wurde; das Neustarten des Überwachers und das erneute Eintreten in die Abfrageschleife sind Teil derselben Babysitting-Aufgabe. Wenn ein --watch-Prozess noch läuft und keine strikte Stoppbedingung erreicht wurde, ist die Babysitting-Aufgabe noch im Gange; streamen/konsumieren Sie weiterhin die Überwacher-Ausgabe, anstatt die Runde zu beenden.

Abfragerate

Behalten Sie eine aggressive Review-Abfrage bei und setzen Sie die Überwachung fort, auch nachdem CI grün wird:

• Solange CI nicht grün ist (ausstehend/laufend/in der Warteschlange oder fehlschlagend): alle 1 Minute abfragen.
• Nachdem CI grün wird: Abfrage mit der Basisrate fortsetzen, solange der PR offen bleibt, damit neu gepostete Review-Kommentare zeitnah angezeigt werden, anstatt auf eine lange Rückstellung im grünen Zustand zu warten.
• Setzen Sie die Rate sofort zurück, wenn sich etwas ändert (neuer Commit/SHA, Statusänderungen der Prüfungen, neue Review-Kommentare, Änderungen der Merge-Fähigkeit, Änderungen der Review-Entscheidung).
• Wenn CI wieder nicht grün wird (neuer Commit, erneuter Lauf oder Regression): bei der Basis-Abfragerate bleiben.
• Wenn eine Abfrage zeigt, dass der PR gemergt oder anderweitig geschlossen ist: Abfrage sofort stoppen und den Endzustand melden.

Stoppbedingungen (Streng)

…