Skip to content

Customer-Facing Release Notes Drafter

Example prompt: "Every Thursday afternoon, look at the GitHub pull requests we've merged this week with the 'user-facing' label, draft customer-friendly release notes grouped into what's new, what's improved, and what we fixed, and put the draft into our Notion 'Release Notes' page for me to review before it goes out."

The Problem

The engineering changelog and the customer release notes are not the same document. The changelog is "fix bug in retry loop on payment webhook handler"; the release notes are "Payment confirmations now arrive reliably even when the bank takes a moment to respond." Translating one into the other takes a product manager an hour every Thursday — reading PR titles, working out which ones are visible to users, rephrasing them in customer language, grouping them sensibly. The week the PM has back-to-back interviews, the release notes do not go out, and customers find out their bug was fixed when they happen to retry.

How GloriaMundo Solves It

We build a workflow that runs every Thursday afternoon. An integration step queries GitHub for pull requests merged into main in the last seven days that carry the user-facing label. A conditional filters out anything also labelled internal or infrastructure. An LLM step reads each remaining PR's title and description and rewrites it as a customer-facing line, classifying each into "New", "Improved", or "Fixed". A code step groups the lines by category and orders them so the highest-impact entries are first within each group. An integration step appends the draft as a new dated section in the team's "Release Notes" Notion page, marked as a draft. A final integration step posts a short Slack message to the PM with a link and a one-line summary of the count per category. The PM reads, edits, and publishes from Notion; nothing goes out to customers without that human pass.

Example Workflow Steps

  1. Trigger (scheduled): Runs every Thursday at 14:00.
  2. Step 1 (integration): Query GitHub for pull requests merged into main since the previous Thursday, filtered to those with the user-facing label.
  3. Step 2 (conditional): Drop any PR that also carries internal or infrastructure — those are user-facing only by accident.
  4. Step 3 (LLM): For each remaining PR, rewrite the title and description as a customer-facing line and classify it as "New", "Improved", or "Fixed".
  5. Step 4 (code): Group the rewritten lines by category and order them so the most user-visible entries come first within each group.
  6. Step 5 (integration): Append a new dated draft section to the "Release Notes" Notion page with the grouped lines.
  7. Step 6 (integration): Post a Slack message to the PM with a link to the draft and a count per category.

Integrations Used

  • GitHub — source of merged pull requests and their labels
  • Notion — where the release notes draft is appended for the PM to review and publish
  • Slack — heads-up to the PM that a fresh draft is ready

Who This Is For

Product managers at engineering-led teams that ship continuously and want a published changelog for customers, but where translating PRs into customer language each week is the bottleneck that means the changelog often skips a week. Especially useful for teams of 5-25 engineers merging 20-60 PRs a week.

Time & Cost Saved

Reading a week's PR list, picking the user-visible ones, rewriting them, and grouping them takes a PM 45-90 minutes every Thursday. Over a year that is roughly 40-80 hours. This workflow delivers a draft in minutes and the PM's time goes into editing for tone and judgement, which is the part the workflow cannot do.