Draft monthly release notes from what actually went live

On the first business day of every month, draft customer facing release notes covering everything that actually shipped to customers during the previous calendar month, and put that draft in front of a product manager for review before anything goes public.

Start in LaunchDarkly. Use "List feature flag statuses" against my production environment to find every flag whose status is launched. A flag reaching launched in production is the signal I trust that a feature genuinely became available to customers, far more than a merged pull request or a closed ticket, both of which land well before real availability. Then use "List audit log entries", filtered to the previous month's date range, to confirm the date each of those flags was fully turned on, and keep only the flags whose full rollout actually happened inside the reporting window. Note that the audit log returns newest entries first, caps each page at 20 entries and pages backwards, so keep paging using the date of the oldest entry you received until the whole month is covered.

For each remaining flag, call "Get feature flag" to read its name, description and tags. Drop any flag tagged internal or experiment, since those are not customer visible and must never appear in published notes. If you need to resolve flags across the wider project, "List feature flags" is also available.

Next, gather the engineering context. In GitHub, use "List Pull Requests" to find merged pull requests that mention each flag key in the title, body or branch name. Read those pull requests to understand what actually changed and why, so every release note entry can describe real user impact rather than restating an internal flag name.

Draft the release notes grouped by theme, for example by product area or by the kind of improvement, rather than one flat list in flag order. Write in plain customer language. The body must contain no flag keys, no ticket numbers, no repository or branch names and no internal engineering jargon. Each entry should say what is now possible for the customer and why it matters to them. If a change has no plausible customer impact, leave it out entirely rather than padding the notes.

Publish the draft as a new page in my Notion release notes database using "Create a Page", titled with the month and year it covers. Then use the Slack "Send a Message" action to post a link to that page in my product channel, together with a one line summary of how many changes are covered, making it explicit that this is a draft for a product manager to review and edit before it goes public.

If no flags reached launched status inside the reporting window, skip creating the Notion page and instead post a short Slack message saying there is nothing to publish this month.