Samengevoegde PR's naar Launch Copy
Okou leest de pull-aanvragen die u deze week hebt samengevoegd, behoudt de gebruikersgerichte, schrijft het changelog-bericht en publiceert het naar uw blog, uw Resend-lijst en X in dezelfde run, zodra u het concept goedkeurt.
Wat Okou levert: de post, de e-mail en de thread
Dit is een echte Okou productupdate, gepubliceerd op okou.ai op 20 juli 2026, precies zoals deze is uitgebracht: de blogpost, dezelfde update als nieuwsbrief, en als thread op X. Eén run schreef alle drie vanuit de samengevoegde pull requests van die week.
Wat is changelog-automatisering?
Changelog-automatisering is de praktijk van het genereren van je productupdate op basis van het werk dat je team daadwerkelijk heeft samengevoegd, in plaats van het aan het einde van de week uit het hoofd te schrijven. Okou fungeert als de agent in het midden: het leest samengevoegde pull-aanvragen in GitHub, behoudt de gebruikersgerichte, groepeert ze in thema's, schrijft de changelog-post en publiceert deze naar je blog, een Resend-nieuwsbrief en een X-thread in één keer. Het resultaat is een wekelijkse productupdate die op schema wordt geleverd en op elk kanaal hetzelfde zegt.
Waarom de wekelijkse changelog een vrijdag opslokt
Vrijdagmiddag. Dertig-en-nog-wat pull requests samengevoegd deze week en iemand moet ze omzetten in een update die mensen daadwerkelijk zullen lezen. Je scant de samenvoeglijst, raadt welke wijzigingen gebruikersgericht zijn, schrijft de post, kort deze in voor de e-mail, kort deze nogmaals in voor X, en plakt vervolgens elke versie in een ander hulpmiddel. Het is drie keer dezelfde lezing, en de versie die op X verschijnt, zegt meestal iets anders dan die in de inbox.
Hoe Okou een week aan merges omzet in een gepubliceerde changelog
Stap 1: Verbind uw tools
Stap 2: Vraag Okou
Stap 3: Ga verder
GitHub, Resend, X en Slack-integraties voor changelog-automatisering
Deze workflow leest van één tool en schrijft naar drie. GitHub is de enige bron van waarheid voor wat er is verzonden; Resend en X zijn bestemmingen; Slack is waar het concept wacht op een mens. Elke connector wordt afzonderlijk toegekend en beperkt tot wat de workflow daadwerkelijk gebruikt, dus leesrechten voor uw repository impliceren nooit het recht om vanaf uw account te posten.
GitHub-integratie: wat Okou leest om de changelog te bouwen
VereistOkou bevraagt de pull requests die binnen je venster zijn samengevoegd in de door jou genoemde repositories, en leest voor elk daarvan de titel, de body, de labels, de samenvoegtijd, de auteur en de gewijzigde bestandspaden. Die vijf signalen zijn wat een gebruikersgerichte wijziging scheidt van een interne refactor: een release-note label is het sterkst, de gewijzigde paden vangen degenen op die niemand heeft gelabeld, en de body levert de details die de titel weglaat. In deze workflow is de GitHub-integratie alleen-lezen. Okou opent geen issues, pusht geen commits en bewerkt geen pull requests. Richt het op meer dan één repository en het leest ze allemaal in dezelfde pass, zodat een gesplitste frontend en backend nog steeds een enkele changelog produceert.
Resend-integratie: de nieuwsbrief die Okou verstuurt
VereistOkou leest uw Resend-doelgroepen, zodat het de door u genoemde doelgroep bij naam kan aanspreken in plaats van via ID, en vervolgens de campagne maakt en verzendt: onderwerpregel, preheader, HTML-body en platte tekstalternatief. Na de verzending leest het het resultaat terug en rapporteert het hoeveel berichten zijn afgeleverd, uitgesteld en gebounced, daarom zijn het rapport en de campagne het altijd eens. Verzendtoestemming wordt afzonderlijk van de leestoegang tot de doelgroep verleend, en Okou voegt, verwijdert of exporteert nooit contacten.
X-integratie: de thread Okou-berichten
VereistDe thread is geschreven voor X, niet ingekort van de blogpost: één post per thema, een opening die vertelt wat er is veranderd, en een afsluitende post die teruglinkt naar de volledige uiteenzetting. Okou plaatst elke vermelding als een antwoord op de vorige, zodat de thread bij elkaar blijft, en het controleert de lengte voordat het post, in plaats van een post te laten afkappen. Schrijftoegang is beperkt tot het account dat u verbindt, en het plaatsen van de thread is alles wat het doet. Okou leest uw tijdlijn, uw vermeldingen of uw directe berichten niet.
Slack-integratie: waar het concept wacht op goedkeuring
OptioneelSlack is optioneel en verdient zijn plaats in de goedkeuringsstap. Okou plaatst het volledige concept in het kanaal dat u noemt, inclusief de blogtekst, de onderwerpregel van de e-mail en elke post in de thread, en stopt dan. Niets wordt gepubliceerd totdat iemand met goedkeuring antwoordt, en u kunt om een herschrijving vragen in dezelfde thread en een bijgewerkt concept krijgen. Sla Slack over en de workflow wordt nog steeds van begin tot eind uitgevoerd; het concept komt terug waar u de uitvoering bent begonnen.
Okou vs. handmatig schrijven vs. een changelog-generator
Changelog-automatisering splitst zich in twee problemen: beslissen wat het waard is om aan te kondigen, en de aankondiging naar elk kanaal krijgen. De meeste tools lossen één ervan op.
Met de hand schrijven
Iemand leest de samenvoeglijst, beslist wat belangrijk is, schrijft het bericht en herschrijft het twee keer voor e-mail en X. Het oordeel is goed en de tekst is merkgetrouw, maar het kost elke week dezelfde 90 minuten en het is het eerste dat wordt geschrapt in een drukke week.
Een changelog-generator
Commit- of pull request-titels worden automatisch verzameld op een release-notitiespagina. Het mist nooit een merge, maar het publiceert titels in plaats van thema's, kan geen refactor van een feature onderscheiden en stopt bij één bestemming.
Okou's changelog-workflow
Okou leest dezelfde samenvoegingen, past jouw regel toe voor wat als gebruikersgericht telt, groepeert de rest in thema's en schrijft tekst per kanaal. Blog, Resend en X publiceren vanuit één goedgekeurd concept in één run, en de run rapporteert wat het heeft tegengehouden en waarom.
Tips voor betere resultaten
Veelgestelde vragen
Hoe automatiseer ik een changelog van GitHub pull requests?
Verbind GitHub met Okou en geef het een schema of een releasetrigger. Okou leest de pull-aanvragen die in uw venster zijn samengevoegd, filtert ze met uw regel voor wat als gebruikersgericht telt, groepeert de overlevenden in thema's en schrijft de changelog-post. Voeg Resend en X toe en dezelfde run publiceert het ook naar die kanalen.
Hoe beslist Okou welke merges gebruikersgericht zijn?
Volgens de regel die u opgeeft, toegepast op vier signalen: het release-notitie label, de gewijzigde bestandspaden, de pull request titel en de body. Een label is het sterkste signaal en degene die de meeste teams standaardiseren. Alles wat Okou uitsluit, wordt vermeld in het uitvoerrapport met de reden, zodat een verkeerde oproep zichtbaar is in plaats van stil.
Kan één concept tegelijkertijd worden gepubliceerd naar een nieuwsbrief en X?
Ja. Okou schrijft de thema's één keer en past ze vervolgens per kanaal aan: de blogpost volledig, de e-mail op inboxlengte met een onderwerpregel en preheader, en een thread met één bericht per thema. Alle drie worden ze in dezelfde run gepubliceerd vanuit hetzelfde goedgekeurde concept, zodat de feiten niet kunnen afwijken tussen kanalen.
Wordt er iets gepubliceerd zonder mijn goedkeuring?
Niet tenzij je erom vraagt. De standaardstroom plaatst het concept in een kanaal en wacht. Je kunt het goedkeuren, een herschrijving aanvragen in dezelfde thread, of het laten vallen. Als je liever hebt dat het zonder toezicht wordt gepubliceerd, zeg dat dan in de prompt en Okou slaat de goedkeuringsstap over.
Welke tools heeft de changelog-automatisering nodig?
GitHub is vereist als bron van wat er is verzonden. Resend en X zijn vereist voor de twee publicatiedoelen. Slack is optioneel en wordt alleen gebruikt voor de goedkeuringsstap; zonder dit komt het concept terug waar u de run bent gestart.
Welke machtigingen heeft deze workflow nodig?
GitHub heeft leesrechten nodig voor de repositories waaruit u publiceert. Resend heeft verzendrechten en leesrechten voor het publiek nodig. X heeft schrijfrechten nodig op het account dat de thread plaatst. Slack, als u het gebruikt, moet posten in het goedkeuringskanaal. U verleent elke connector afzonderlijk in Okou, en het intrekken van één laat de andere onaangetast.
Kan Okou één changelog bouwen uit meerdere repositories?
Ja. Noem elke repository in de prompt en Okou leest ze in dezelfde pass, en groepeert vervolgens wijzigingen op basis van het gedrag dat ze wijzigen in plaats van op basis van de repository waaruit ze afkomstig zijn. Een gesplitste frontend en backend produceren nog steeds één post.
Kan ik het uitvoeren op een releasetag in plaats van een wekelijks schema?
Ja. Creëer een automatisering die de workflow start wanneer een release wordt getagd in GitHub. Okou bouwt dan de changelog op basis van de pull requests in die release in plaats van een datumbereik, en de rest van de run is identiek.
Publiceer de changelog van deze week
Verbind GitHub, Resend en X, en gebruik vervolgens de wekelijkse prompt om de hele run te zien: scannen, groeperen, opstellen, goedkeuren, publiceren.
