Can it tell which changes are user-facing?

You tell it how to decide, in the draft prompt — most teams define it by area or label conventions in their changelog and release docs. The editorial review is the second net: it flags entries that read internal, and the approver is the third.

What gets published, exactly?

The approved document, as a shareable public link. The approval record pins which revision was signed off; if the draft changes after review, that's a new artifact and a new approval.

AI Workflows for Release Notes

Name: Fleet
Author: Fleet

Release notes are written twice: once badly by whoever drew the short straw — a paste of commit subjects nobody outside the team can parse — and once more by support, in apology emails explaining what actually changed. Public changelogs also leak things: internal fix details, security specifics, names of things that shouldn't be named.

The job needs translation (commit-speak to user-speak), filtering (what's public, what isn't), and an editorial gate. That's three roles, every release, under time pressure.

How it works with an agent fleet

A Fleet workflow drafts user-facing notes from the shipped work, a review step checks both accuracy and audience (no internal-only details), and a named owner approves the exact text before it publishes.

Step	Kind	What it does
`draft`	Document	“Write user-facing release notes for this release. Translate changes into user impact; exclude internal-only fixes.” Reads `CHANGELOG.md`, `docs/releases/*.md`.
`editorial`	Review	“Flag anything inaccurate, internal-only, or unclear to a customer.”
`owner-ok`	Approval gate	Pauses the run for a human sign-off; records the approver, timestamp, and note.
`publish`	Publish	Shares the approved document at a link.

You build this once on the dashboard canvas; your self-hosted Fleet worker pulls the definition and runs it against your repository.

The publish step shares the approved document at a public link only after the gate clears. A flagged draft — say the reviewer catches an internal incident reference — parks at the approval with the flag shown, and rejecting routes it back for another pass.

The fleet pattern

Draft → editorial review (accuracy + audience) → approval → publish. The same shape as a human editorial desk, with the human concentrated where judgment lives: the gate.

Guardrails that matter here

Nothing publishes without the recorded approval — the publish step depends on the gate
The review step is specifically prompted for audience leaks (internal details, security specifics), the class of mistake that hurts most in public changelogs
Published artifacts are content-addressed and versioned — what went out is provable, revision by revision

Who this is for

Teams that ship on a cadence and maintain a public changelog, especially where the gap between 'what the commits say' and 'what users should read' is wide.