Release notes people actually read

Your changelog already exists. The problem is that nobody reads a wall of monospace attached to a Git tag.

# The last mile of shipping

The build is green, the tag is pushed, and then the release notes go out as plain text — the one document your users are guaranteed to open, dressed like an accident. Release notes are a product surface. They deserve the same care as the release itself.

With lucid.page the ritual stays exactly as heavy as it should be: paste the notes, publish, drop the link into Slack. The share card is generated for you, and tables render as tables rather than ASCII art:

# One page per release — or the whole story

A single release is a page. A release train is a bundle: chapters under one link, with a landing page and previous/next navigation, so “what changed in 1.4” and “what changed in 1.5” read like consecutive chapters of the same book instead of orphaned posts.

# A record you can defend

Notes sometimes need correcting after they go out — a pulled feature, a wrong version number. Edits keep the URL and add a revision; the earlier wording is never silently gone. When someone asks “was that always in the notes?”, you have an answer.

# Common questions

# Can I publish release notes from CI?

Yes — publishing is a single POST with your Markdown, so a release workflow can ship notes the moment a tag lands. See the agent documentation for the interface.

# Can I group many releases under one link?

Yes. Bundles turn any set of pages into a multi-chapter book with its own landing page and chapter navigation — one durable link for the whole release history.

# What if I need to fix a note after publishing?

Edit and republish. The URL is unchanged, and the previous version is preserved as a restorable revision.