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, one link for all of them

Each release is its own page. Collect them in a binder and the whole history sits behind one link, in the order you choose, with a short note on each entry if you want one. Make the binder public and it gets its own indexable page.

# 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. Collect the release pages in a binder: one link for the whole release history, and each entry can carry a short note.

# 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.