Von gemergten Pull Requests zum veröffentlichten Changelog

Zero liest die Pull Requests, die ihr diese Woche gemergt habt, behält die nutzerrelevanten, schreibt den Changelog-Beitrag und veröffentlicht ihn nach eurer Freigabe im selben Lauf auf dem Blog, über Resend und auf X.

Zero verbindet:GitHubResendX (Twitter)Slack

Was Zero liefert: den Beitrag, die Mail und den Thread

Das ist ein echtes Zero-Produkt-Update, am 20. Juli 2026 auf vm0.ai veröffentlicht und genau so gezeigt, wie es rausging: der Blogbeitrag, dasselbe Update als Newsletter und als Thread auf X. Ein Lauf hat alle drei aus den gemergten Pull Requests der Woche geschrieben.

Das veröffentlichte Produkt-Update lesen

Was ist Changelog-Automatisierung?

Changelog-Automatisierung heißt, das Produkt-Update aus der Arbeit zu erzeugen, die euer Team tatsächlich gemergt hat, statt es am Ende der Woche aus dem Gedächtnis zu schreiben. Zero ist der Agent dazwischen: Er liest gemergte Pull Requests in GitHub, behält die nutzerrelevanten, gruppiert sie zu Themen, schreibt den Changelog-Beitrag und veröffentlicht ihn in einem Lauf auf dem Blog, als Resend-Newsletter und als X-Thread. Das Ergebnis ist ein wöchentliches Produkt-Update, das pünktlich erscheint und auf jedem Kanal dasselbe sagt.

Warum der wöchentliche Changelog einen Freitag frisst

Freitagnachmittag. Diese Woche wurden gut dreißig Pull Requests gemergt, und jemand muss daraus ein Update machen, das Leute tatsächlich lesen. Man überfliegt die Merge-Liste, rät, welche Änderungen nutzerrelevant sind, schreibt den Beitrag, kürzt ihn für die Mail, kürzt ihn nochmal für X und kopiert jede Fassung in ein anderes Tool. Dreimal dieselbe Lektüre, und was auf X landet, sagt meistens etwas anderes als das, was im Postfach ankam.

Wie Zero aus einer Woche Merges einen veröffentlichten Changelog macht

Schritt 1: Tools verbinden

GitHub
GitHub
Erforderlich
Lesezugriff auf die Repositories, aus denen ihr veröffentlicht. Zero liest gemergte Pull Requests, ihre Labels, Beschreibungen und geänderten Pfade.
Verbinden
Resend
Resend
Erforderlich
OAuth-Verbindung zu eurem Resend-Workspace. Zero braucht Versandrechte und Lesezugriff auf die Zielgruppen.
Verbinden
X (Twitter)
X (Twitter)
Erforderlich
Schreibzugriff auf das X-Konto, das den Thread veröffentlicht. Zero postet den Thread und liest sonst nichts.
Verbinden
Slack
Slack
Optional
Optional. Zero postet den Entwurf in den Kanal, den ihr nennt, damit ein Mensch ihn freigibt, bevor etwas veröffentlicht wird.
Verbinden

Schritt 2: Zero fragen

@Zero lies jeden Freitag um 9 Uhr die Pull Requests, die in den letzten 7 Tagen in vm0-ai/vm0 gemergt wurden. Behalte die nutzerrelevanten, gruppiere sie zu Themen und schreib einen Changelog-Beitrag. Zeig ihn mir in #marketing, veröffentliche ihn dann auf dem Blog, verschick ihn über Resend an die Zielgruppe 'subscribers' und poste einen Thread auf X.
Zero liest die gemergten Pull Requests der Woche
Zero holt jeden Pull Request, der im gewählten Zeitraum in die von euch genannten Repositories gemergt wurde, und liest Titel, Beschreibung, Labels und geänderte Pfade, um nutzerrelevante Änderungen von Refactorings, reinen Teständerungen und Abhängigkeits-Updates zu trennen.
Ausgelieferte Änderungen werden zu Themen gebündelt
Zehn kleine Merges bedeuten selten zehn Ankündigungen. Zero gruppiert Änderungen danach, welches Verhalten sich ändert, nicht danach, welcher Code angefasst wurde, und ordnet die Themen so, dass der Beitrag mit dem beginnt, das die meisten Menschen betrifft.
Ein Entwurf, pro Kanal angepasst
Zero schreibt den Changelog-Beitrag und formuliert ihn dann für jedes Ziel neu: eine Mail in Postfachlänge mit Betreff und Preheader und einen Thread mit einem Beitrag pro Thema. Überall dieselben Fakten, weil sie aus derselben Quelle stammen.
Nach eurer Freigabe auf Blog, Resend und X veröffentlichen
Der Entwurf wartet im Kanal, den ihr nennt. Sobald ihr freigebt, veröffentlicht Zero den Beitrag, verschickt die Resend-Kampagne an die genannte Zielgruppe und postet den Thread auf X, alles im selben Lauf, und meldet danach die Zustellzahlen zurück.

Schritt 3: Weiterführende Aktionen

Ändern, was es in den Beitrag schafft
Justiert, welche Merges als nutzerrelevant gelten, bevor der Beitrag geschrieben wird.
@Zero nimm in den wöchentlichen Changelog nur Pull Requests mit dem Label 'release-note' auf. Alles andere listest du am Ende in je einer Zeile.
Statt Zeitplan lieber per Release auslösen
Ersetzt den Wochenplan durch einen Release-Tag, damit der Beitrag dann erscheint, wenn ihr ausliefert.
@Zero stopp den Freitagsplan. Schreib und veröffentliche den Changelog stattdessen immer dann, wenn wir ein Release in vm0-ai/vm0 taggen.
Eine monatliche Zusammenfassung ergänzen
Behaltet den Wochenrhythmus und legt eine längere Rückschau obendrauf.
@Zero fass am ersten Montag jedes Monats die letzten vier Wochen-Changelogs zu einem Rückblick zusammen und verschick ihn über Resend.

GitHub-, Resend-, X- und Slack-Integration für die Changelog-Automatisierung

Dieser Workflow liest aus einem Tool und schreibt in drei. GitHub ist die einzige Quelle dafür, was ausgeliefert wurde; Resend und X sind Ziele; Slack ist der Ort, an dem der Entwurf auf einen Menschen wartet. Jeder Connector wird einzeln freigegeben und auf das beschränkt, was der Workflow tatsächlich nutzt. Lesezugriff auf euer Repository bedeutet also nie das Recht, aus eurem Konto zu posten.

GitHub

GitHub-Integration: was Zero für den Changelog liest

Erforderlich

Zero fragt die Pull Requests ab, die im gewählten Zeitraum in die genannten Repositories gemergt wurden, und liest zu jedem Titel, Beschreibung, Labels, Merge-Zeitpunkt, Autor und die geänderten Dateipfade. Diese fünf Signale trennen eine nutzerrelevante Änderung von einem internen Refactoring: Ein Release-Notiz-Label ist das stärkste, die geänderten Pfade fangen die ungelabelten ab, und die Beschreibung liefert die Details, die der Titel auslässt. In diesem Workflow ist die GitHub-Integration schreibgeschützt. Zero legt keine Issues an, pusht keine Commits und bearbeitet keine Pull Requests. Nennt ihr mehrere Repositories, liest Zero sie im selben Durchlauf, sodass getrenntes Frontend und Backend trotzdem einen einzigen Changelog ergeben.

Resend

Resend-Integration: der Newsletter, den Zero verschickt

Erforderlich

Zero liest eure Resend-Zielgruppen, damit ihr die gewünschte über den Namen statt über eine ID ansprechen könnt, und erstellt und versendet dann die Kampagne: Betreff, Preheader, HTML-Text und Nur-Text-Variante. Nach dem Versand liest Zero das Ergebnis zurück und meldet, wie viele Nachrichten zugestellt, zurückgestellt und abgewiesen wurden. Deshalb widersprechen sich Report und Kampagne nie. Versandrechte werden getrennt vom Lesezugriff auf Zielgruppen erteilt, und Zero fügt niemals Kontakte hinzu, entfernt oder exportiert sie.

X (Twitter)

X-Integration: der Thread, den Zero postet

Erforderlich

Der Thread ist für X geschrieben, nicht aus dem Blogbeitrag gekürzt: ein Beitrag pro Thema, ein Auftakt, der sagt, was sich geändert hat, und ein Abschluss, der auf den vollständigen Text verlinkt. Zero postet jeden Eintrag als Antwort auf den vorherigen, damit der Thread zusammenhält, und prüft die Länge vor dem Posten, statt einen Beitrag abschneiden zu lassen. Der Schreibzugriff ist auf das verbundene Konto beschränkt, und mehr als den Thread zu posten tut Zero nicht. Timeline, Erwähnungen und Direktnachrichten liest Zero nicht.

Slack

Slack-Integration: wo der Entwurf auf die Freigabe wartet

Optional

Slack ist optional und verdient sich seinen Platz beim Freigabeschritt. Zero postet den vollständigen Entwurf in den genannten Kanal, inklusive Blogtext, Betreffzeile und jedem Beitrag des Threads, und hält dann an. Nichts wird veröffentlicht, bevor jemand freigibt, und ihr könnt im selben Thread eine Überarbeitung anfordern und bekommt den aktualisierten Entwurf an Ort und Stelle. Ohne Slack läuft der Workflow trotzdem vollständig durch; der Entwurf kommt dann dort zurück, wo ihr den Lauf gestartet habt.

Zero im Vergleich zu Handarbeit und zu einem Changelog-Generator

Changelog-Automatisierung zerfällt in zwei Probleme: zu entscheiden, was eine Ankündigung wert ist, und diese Ankündigung auf jeden Kanal zu bringen. Die meisten Tools lösen nur eines davon.

Von Hand geschrieben

Jemand liest die Merge-Liste, entscheidet, was zählt, schreibt den Beitrag und formuliert ihn zweimal für Mail und X neu. Das Urteil ist gut und der Text sitzt, aber es kostet jede Woche dieselben 90 Minuten und fällt in einer vollen Woche als Erstes weg.

Ein Changelog-Generator

Commit- oder Pull-Request-Titel landen automatisch auf einer Release-Notes-Seite. Kein Merge geht verloren, aber veröffentlicht werden Titel statt Themen, ein Refactoring lässt sich nicht von einem Feature unterscheiden, und es bleibt bei einem Ziel.

Zeros Changelog-Workflow

Zero liest dieselben Merges, wendet eure Regel für nutzerrelevant an, gruppiert den Rest zu Themen und schreibt den Text pro Kanal. Blog, Resend und X werden aus einem freigegebenen Entwurf in einem Lauf veröffentlicht, und der Lauf meldet, was zurückgehalten wurde und warum.

Tipps für bessere Ergebnisse

Nennt Zeitraum und Repository ausdrücklich. 'In den letzten 7 Tagen in vm0-ai/vm0 gemergt' ergibt einen deutlich präziseren Beitrag als 'was wir kürzlich ausgeliefert haben'.
Gebt Zero eine einzige Regel dafür, was nutzerrelevant ist, etwa ein Release-Notiz-Label. Eine Regel schlägt eine lange Ausnahmeliste und hält das Ergebnis Woche für Woche konsistent.
Schickt den Entwurf immer durch einen Freigabekanal. Genau dann, wenn an drei Stellen gleichzeitig veröffentlicht wird, soll ein Mensch vorher lesen.

Häufige Fragen

Wie automatisiert man einen Changelog aus GitHub-Pull-Requests?

Verbindet GitHub mit Zero und gebt einen Zeitplan oder einen Release-Auslöser vor. Zero liest die im Zeitraum gemergten Pull Requests, filtert sie mit eurer Regel für nutzerrelevante Änderungen, gruppiert den Rest zu Themen und schreibt den Changelog-Beitrag. Kommen Resend und X dazu, veröffentlicht derselbe Lauf ihn auch auf diesen Kanälen.

Woran erkennt Zero, welche Merges nutzerrelevant sind?

An der Regel, die ihr vorgebt, angewandt auf vier Signale: das Release-Notiz-Label, die geänderten Dateipfade, den Titel des Pull Requests und seine Beschreibung. Ein Label ist das stärkste Signal und das, worauf sich die meisten Teams festlegen. Alles, was Zero ausschließt, steht mit Begründung im Report des Laufs, sodass eine falsche Einschätzung sichtbar wird statt still zu verschwinden.

Lässt sich ein Entwurf gleichzeitig als Newsletter und auf X veröffentlichen?

Ja. Zero schreibt die Themen einmal und passt sie dann pro Kanal an: den Beitrag in voller Länge auf dem Blog, die Mail in Postfachlänge mit Betreff und Preheader und einen Thread mit einem Beitrag pro Thema. Alle drei erscheinen im selben Lauf aus demselben freigegebenen Entwurf, sodass die Fakten zwischen den Kanälen nicht auseinanderlaufen können.

Wird etwas ohne meine Freigabe veröffentlicht?

Nur wenn ihr es so wollt. Standardmäßig postet Zero den Entwurf in einen Kanal und wartet. Ihr könnt freigeben, im selben Thread eine Überarbeitung anfordern oder ihn verwerfen. Soll es unbeaufsichtigt veröffentlicht werden, schreibt das in den Prompt, und Zero überspringt den Freigabeschritt.

Welche Tools braucht diese Changelog-Automatisierung?

GitHub ist als Quelle dafür erforderlich, was ausgeliefert wurde. Resend und X sind als die beiden Veröffentlichungsziele erforderlich. Slack ist optional und wird nur für den Freigabeschritt genutzt; ohne Slack kommt der Entwurf dort zurück, wo ihr den Lauf gestartet habt.

Welche Berechtigungen braucht dieser Workflow?

GitHub braucht Lesezugriff auf die Repositories, aus denen ihr veröffentlicht. Resend braucht Versandrechte und Lesezugriff auf die Zielgruppen. X braucht Schreibzugriff auf das Konto, das den Thread postet. Slack braucht, falls genutzt, das Recht, im Freigabekanal zu posten. Jeder Connector wird in Zero einzeln freigegeben, und ein Widerruf lässt die anderen unberührt.

Kann Zero einen Changelog aus mehreren Repositories bauen?

Ja. Nennt jedes Repository im Prompt, dann liest Zero sie im selben Durchlauf und gruppiert die Änderungen danach, welches Verhalten sich ändert, nicht danach, aus welchem Repository sie stammen. Getrenntes Frontend und Backend ergeben trotzdem einen Beitrag.

Kann ich ihn statt wöchentlich per Release-Tag auslösen?

Ja. Legt eine Automatisierung an, die den Workflow startet, sobald in GitHub ein Release getaggt wird. Zero baut den Changelog dann aus den Pull Requests dieses Releases statt aus einem Zeitfenster, der Rest des Laufs bleibt identisch.

Veröffentlicht den Changelog dieser Woche

Verbindet GitHub, Resend und X und nutzt den Wochen-Prompt, um den ganzen Lauf zu sehen: prüfen, gruppieren, entwerfen, freigeben, veröffentlichen.

@Zero lies jeden Freitag um 9 Uhr die Pull Requests, die in den letzten 7 Tagen in vm0-ai/vm0 gemergt wurden. Behalte die nutzerrelevanten, gruppiere sie zu Themen und schreib einen Changelog-Beitrag. Zeig ihn mir in #marketing, veröffentliche ihn dann auf dem Blog, verschick ihn über Resend an die Zielgruppe 'subscribers' und poste einen Thread auf X.