Customer changelog email from each 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.