Release notes nobody has to write

Release notes are the chore at the end of the sprint that everyone agrees matters and nobody wants. So they get written at 6pm from a git log, or they do not get written at all, and the client finds out what changed by noticing it.

The awkward part is that the information already exists. You closed eleven issues this week. Each one has a title, a description, a discussion and a resolution. That is the changelog — it is just in the wrong shape.

From completed tasks to a release

Pogpin’s changelog section says it plainly: turn completed tasks into clear product updates. The flow is four steps and none of them is “start from a blank page”.

1. Pick the completed tasks. The picker lists what is done and not yet included in a release; once a task is saved into one, it drops off the list so nothing gets shipped twice.
2. Generate the notes. Pogpin drafts a release from the selected issues — what changed, in language a customer can read rather than a list of ticket titles. AI generation is a Pro feature.
3. Edit it. The draft opens in the editor with a title and an optional version. Save it as a draft and come back, or rewrite whatever the draft got wrong — it is a starting point, not a publisher.
4. Publish. The release gets a public page you can link, and the copy link button hands you the URL.

It goes where your people already are

A published release fans out to your notification channels — the same per-event routing that carries pins to Slack, Discord, Telegram, Teams, Lark, email or a custom webhook. If no channel is enabled, the release still publishes; the product tells you so instead of failing quietly.

That closes a loop most teams never close: the client who reported the bug hears that it shipped, in the channel they already read, without anyone writing a separate announcement.

Why generating from issues beats generating from commits

Commit messages are written for the person doing the merge. Issues are written by the person who noticed the problem — often the client. Generating notes from resolved issues means the release describes the change the way it was experienced, not the way it was implemented:

• “Fixed the checkout button overlapping on mobile Safari” rather than “fix: adjust flex-basis on .cart-actions”.
• The context is already there — the page, the environment, the discussion — so the summary has something real to compress.
• Nothing is invented: the draft only sees issues you selected and marked done.

The honest limits

• AI generation needs Pro. Everything else — writing, drafting, publishing the page, notifying channels — does not.
• A draft is a draft. Nothing publishes itself. You read it, edit it and press publish, exactly like the AI triage suggestions that sit in a suggested state until you apply them.
• It only sees closed work. A release is built from tasks that reached Done, which is a good reason to actually close issues instead of letting them rot in In review.

A rhythm that works

Teams that get the most out of it treat the changelog as the end of triage, not a separate ritual:

1. Reviewers pin during the week — clients as guests, no accounts.
2. Work is triaged, assigned and closed on the board.
3. On release day, select the closed items, generate, edit for tone, publish.
4. The channels announce it; the public page becomes the link you paste into the client thread.

Ten minutes, and the thing that used to be skipped entirely gets done.

See how the closing half works in triage pins into tracked issues, and where the announcements go in route pins to Slack, Discord and webhooks.