This page shows the workflow we want to validate: pull context from shipped work, generate a user-facing draft, and keep publish and email approval in human hands. The live product now has a testable GitHub-to-draft path in the release composer.
This is a validation demo, not a live MCP integration yet. The point is to test whether AI-first drafting plus human approval feels meaningfully better than starting from a blank editor. For local testing, the composer also includes a demo GitHub source so you can run import and draft generation without wiring a real account first.
The AI should start from GitHub, issue, and launch context that already exists. The team should still decide what belongs in a release note, what tone to use, and whether the update should be published or emailed.
Adds role-based release visibility controls so workspace admins can hide internal-only updates from external subscribers.
Users said they were confused when internal fixes showed up in customer update emails. Need a cleaner way to mark audience visibility before publish.
Top customer-facing benefit: teams can now share fewer noisy updates and make release emails easier to trust.
More control over which updates customers actually see
You can now keep internal-only changes out of public release notes and subscriber emails, so customers only receive updates that matter to them.
Added audience visibility controls for each release, made publish settings clearer before send, and reduced accidental noise in update emails.
This update helps teams send cleaner release emails by making it easier to decide which changes belong in customer-facing announcements.