Send a customer changelog email when you publish a GitHub release

Build me an agent workflow that turns every new GitHub release into a customer-friendly changelog email queued in Resend.

Trigger: a GitHub webhook for a release event on a specific repository I configure (owner and repo name). Only act when the event action is 'published' and the release is not a draft and not a prerelease. Skip everything else immediately.

Inputs I want to configure on the workflow: the GitHub repository (owner/repo), the Resend audience or segment ID for my product updates list, a tone setting (formal or casual), a send mode (draft only, send immediately, or schedule for next business morning at 9am in a timezone I pick), and an optional from name and from address for the broadcast.

Steps the agent should take:

1. Read the release payload from the webhook to get the tag name, release name, body (markdown release notes), html_url, published_at, prerelease, and draft fields. If prerelease or draft is true, stop and log a skip reason.

2. Call GitHub's Get a Release operation using the release id from the webhook to fetch the full, canonical release notes and assets in case the webhook payload was truncated.

3. Rewrite the raw release notes into a polished customer-facing changelog. The output should have: a one-sentence headline that names the version and the single biggest change in plain language; a 'What's new' section split into two groups, Features and Fixes, with short bullet points written for non-technical readers; and a 'Why it matters' callout of two or three sentences explaining the customer benefit. Strip pull request numbers, commit hashes, contributor handles, internal-only labels, and references to private repositories. Match the configured tone (formal or casual). If a style guide or example past announcement is provided, follow it.

4. Render the rewritten changelog as a clean HTML email body. Include the headline as an h1, the version tag and release date as a subhead, the What's new groups as h2 sections with bullet lists, the Why it matters callout in a styled block, and a footer link back to the GitHub release page (html_url) for readers who want the full technical notes.

5. Use Resend's Create Broadcast operation to create a marketing broadcast against the configured audience/segment. Set the subject to the headline, the from address to the configured sender, the html to the rendered body, and a plain-text fallback. Give the broadcast a recognizable name like 'Changelog: {{tag_name}}'.

6. Based on the send mode: if 'draft only', stop after creating the broadcast and return a link so I can review it in the Resend dashboard. If 'send immediately', call Resend's Send Broadcast operation right away. If 'schedule for next business morning', compute the next weekday 9am in my configured timezone (skipping Saturday and Sunday) and call Send Broadcast with scheduled_at set to that ISO timestamp.

7. Return a short run summary: which release was processed (tag, name, url), whether it was skipped (and why), the Resend broadcast id, and the scheduled or sent timestamp.

Guardrails: never invent features that are not in the release notes; if the notes are empty or only contain auto-generated 'Full Changelog' links, create the broadcast as a draft and flag it for manual review instead of sending. Do not include internal-only sections (anything under a heading containing 'internal', 'chore', or 'dependency bump') in the customer email.

Additional information

What does this prompt do?

Listens for new published releases in a GitHub repository you choose and ignores drafts and prereleases.
Rewrites the raw release notes into a customer-friendly email with a one-line headline, a grouped What's new section for features and fixes, and a short Why it matters callout.
Strips internal jargon, PR numbers, and contributor handles so the copy reads like marketing, not a commit log.
Drafts a Resend broadcast targeted at your Product Updates audience, then either sends it right away or schedules it for the next business morning.

What do I need to use this?

A GitHub account with access to the repository whose releases you want to announce.
A Resend account with a verified sending domain and an audience or segment for your product updates list.
A short style guide or two example past announcements if you want the agent to match your brand voice.

How can I customize it?

Point it at any repository you own, or run multiple copies for different products.
Switch the tone between formal and casual, or paste in a brand voice snippet for the agent to match.
Send immediately, hold for review, or schedule for a fixed time like 9am next business day.
Choose which Resend audience receives the broadcast so beta users and general customers can be on different lists.

Frequently asked questions

Does this send the email automatically, or do I get to review it first?

Your choice. By default the broadcast lands in Resend as a draft so you can read it, tweak copy, and click send. You can also tell the agent to send right away or to schedule it for the next business morning.

What happens with draft releases or prereleases?

They are skipped. The workflow only acts on releases marked as published and non-prerelease, so beta tags and work-in-progress notes never reach your customers.

Can I match my company's voice?

Yes. You can pick a formal or casual tone, and you can paste in a short style guide or a few example past announcements. The agent uses them when rewriting the headline, the What's new bullets, and the Why it matters callout.

Which audience does the email go to?

Whichever Resend audience or segment you point the workflow at. Most teams use a Product Updates list, but you can target customers, beta users, or any other segment you have set up.

Do I need to write release notes in any special format?

No. Write your GitHub release notes the way you already do. The agent reads the raw markdown, groups features and fixes, removes internal references, and rewrites it for a customer audience.