Changelog
Usero already authored the PRs that closed your feedback. Click Draft from shipped PRs and the entry assembles from what merged: grouped into features, fixes, and improvements, quoting the users who asked. Publishing tells those users their request is live, one email each, quoting their own words.
Every team means to keep a changelog and most quietly stop after month two, because writing one means a human reconstructing what shipped from git history and memory, on a Friday, from a blank text field.
The tools that promise to fix this with AI mostly reformat your own notes back at you. You paste bullet points into a textarea, wait out an opaque spinner, and get fluent prose about whatever you remembered to type, including plausible details you never shipped. The generator cannot see your repo, your merged PRs, or the feedback behind them, so a human is still the source of truth and the changelog still dies when that human gets busy. The actual job is bookkeeping: what merged since the last entry, what kind of change each one was, and who asked for it. All of that already exists as records. A changelog tool should read them.
How it works
Disclosure: I build Usero, so weigh that. Usero has had a manual changelog for a while: entries with a title and body, an editor in the dashboard, and a public page on your feedback board at /b/your-board/changelog. The new part is the draft button. Usero authors PRs from feedback (that is the core product), so when those PRs merge, the changelog composer can pull every PR merged since your last published entry and prefill the draft: PRs grouped by conventional-commit type into Features, Fixes, and Improvements, and where a PR traces back to feedback, the draft quotes the original report and credits the requester. The draft is deterministic and instant. Same merged PRs, same draft, no spinner, no invented details, because every line comes from a real PR or a real feedback item. You edit it into your voice and publish. Publishing then closes the loop the rest of the way: Usero walks entry to linked PRs to the feedback behind them, and emails each distinct person whose request shipped, quoting what they wrote and linking the entry. You see the count and a sample of the addresses before you click, the button reads Publish and notify N, and two stamps (one on the entry, one on each piece of feedback) mean nobody is written to twice. Every published board also gets an RSS feed at /b/your-board/changelog/rss.xml. An AI polish pass that rewrites the draft in your changelog voice is still a planned follow-up.
The draft pulls the PRs merged since your last published entry, so the window is exactly what your users have not heard about yet. Nothing depends on a human keeping notes during the sprint, and nothing shipped gets forgotten because it merged three weeks ago.
Where a PR traces to a feedback item, the entry quotes the report and credits the person who sent it. Your changelog stops being a list of changes and becomes proof that asking works, which is the strongest reason a user ever has to file feedback again.
The draft assembles from database records the moment you click. There is no multi-minute generation wait, and nothing to fact-check, because it cannot invent a feature you did not ship. Grouping into Features, Fixes, and Improvements comes from conventional-commit prefixes, parsed, not guessed.
Entries go live on the changelog tab of your public feedback board, next to the roadmap and the portal where the requests came in. The person who asked, voted, and watched the status change reads the shipped note in the same place.
A public page only reaches users who come looking. Publishing an entry emails every distinct person whose feedback shipped in it, quoting their own words and linking the entry, so the loop closes in their inbox instead of waiting for them to check. One email per person, however many of their requests made the release.
The honest objection
Today, closer to your git log than to polished release prose, and you should know that going in. The draft gives you accurate structure: the right PRs, grouped correctly, with the feedback quotes attached. The sentences are still PR titles, so a title like "fix: race in export queue" needs a human pass to become "Exports no longer stall when two run at once". That edit is minutes on top of a grounded skeleton, against the blank-page hour it replaces. An AI pass that does the rewording in your voice is a planned follow-up; the grounding came first on purpose, because fluent prose about the wrong facts is worse than rough prose about the right ones.
FAQ
On your public feedback board at /b/your-board/changelog, alongside the portal and roadmap. Each published entry also gets its own page at /b/your-board/changelog/entry-slug. There is no separate site to set up.
Every pull request merged since your last published changelog entry. The draft groups them by conventional-commit type (feat, fix, and the rest) into Features, Fixes, and Improvements, and where a PR is linked to feedback, it quotes the original report and credits the requester.
Not in the current version. The draft is deterministic: it assembles from your merged PRs and linked feedback records, instantly, with no generation step and no invented details. An AI polish pass that rewrites the draft into finished prose is a planned follow-up, running on the same flat-rate container infrastructure as the rest of Usero.
Usero-authored PRs carry the richest context because they are already linked to the feedback that prompted them, so those entries get quotes and requester credit automatically. The draft covers merged PRs on the connected repo; PRs without a linked feedback item appear grouped by type without attribution.
Yes, and you should. The draft prefills the composer; nothing publishes until you hit publish. Entries stay editable and unpublishable afterward, same as manually written ones.
The people whose feedback caused the work. Usero follows the entry to the merged PRs linked to it, then to the feedback behind each PR, then to the email address on that feedback. Anonymous reports have nobody to write to and are skipped. You see the count and a sample of the addresses on the draft before you publish, and the button says Publish and notify N.
They get one email listing all three, each quoting what they wrote and what shipped for it. Addresses are deduped case-insensitively, so one person is one email no matter how many requests of theirs made the release.
No. Two stamps prevent it. The entry is marked once its announcement has gone out, so unpublishing and republishing does not re-send. Each piece of feedback is also marked once it has been announced, so a later entry that happens to link the same feedback skips that person. Every email carries an unsubscribe link, and an unsubscribed address is never written to again.
They share the notify-submitters opt-in in your project settings with the feedback-resolved email, so one switch controls whether Usero may write to your end users at all. With it off, publishing is silent, and the changelog admin tells you which drafts have requesters behind them that are not being told.
Yes, at /b/your-board/changelog/rss.xml, and on your custom domain if you have one. It carries the 50 most recent published entries with the title, permalink, publish date, entry type as the category, the author, and the full body. No account needed to subscribe.
Free tier. No credit card. Two-minute install. The AI opens the PR, you merge it.
Keep reading