Release notes
Release notes written for the person reading them rather than the person who shipped it: what they can now do, in their words, from a Jira release or a pasted list of tickets. Every ticket left out of the notes is listed with the reason, so nothing disappears silently.
- Asks for
- The release — a Jira version, or a pasted list of shipped tickets
- Who reads your notes: customers, internal teams, both
- Anything you want named explicitly, or deliberately not mentioned
- Gives back
- Notes in the reader’s terms: what you can now do, what changed, what is fixed
- Internal work grouped or dropped rather than padded out
- Every excluded ticket listed, with the reason
- A flag on anything excluded that looks like a visible change
- Plan
- Free
- Use next
- One-pager, Document to tickets, Roadmap
What it gives you
New Import a backlog from a CSV. Columns are matched for you and you see the match before anything is saved. (PIKO-1401, 1402, 1419) Fixed A row with a missing effort value no longer rejects the whole file. (PIKO-1430) Not in these notes — 31 tickets 28 internal: refactors, tests, build. 2 not customer-visible. 1 ⚠ PIKO-1427 "tidy up export naming" — changes a filename customers see. Filed as internal. Check this one.
How it works
Release notes written from a ticket list read like a ticket list. "PIKO-1423: refactor import pipeline" tells a customer nothing, and a page of those trains people to stop reading the notes entirely, which is expensive the one time you ship something they needed to know about.
So this writes from the user’s side: what is now possible that was not, what changed about something they already use, what is fixed that was annoying them. Internal work gets grouped or dropped, because the honest translation of a refactor is nothing — and pretending otherwise is how notes get padded.
The left-out list is the part that makes it safe. Everything excluded is named with its reason, so you can scan it in ten seconds and catch the one ticket that was filed as an internal change and is actually a visible behaviour change. That is the mistake these notes are designed to prevent.
Who it is for
Anyone who has to publish notes on release day and has forty tickets, nine of which matter to a customer.
Where it stops
It can only describe what the tickets say: a ticket titled "fix thing" produces a note saying very little, and the fix is better tickets rather than a better generator. It also will not decide your communication policy — whether to mention a security fix at all is a judgement it hands back to you.
Questions people ask
Can it read a release straight from Jira?
Yes, from a connected project: give it the version and it reads the tickets in it. Pasting a list works the same way. The connection mainly saves the copying — the thinking is in the translation from ticket titles to what a customer can now do, and in the list of what was excluded, which is where the mistakes you want to catch tend to be hiding.
Why list the tickets that were left out?
Because a silent omission is the one failure mode that matters. Twenty-eight internal refactors genuinely do not belong in customer notes, but one of them is always a change somebody filed as internal that alters something visible — a filename, a default, a limit. Listing everything excluded with its reason lets you scan it in ten seconds and catch that one, which no amount of care in the writing would have found.
How does it decide what is customer-visible?
By what the ticket describes rather than how it was labelled, which is why the excluded list is flagged rather than just counted. Anything whose description implies a change a user could notice — naming, defaults, limits, errors, anything in the interface — is either written up or excluded with a warning. Labels lie often enough that trusting them is the reason notes miss things.
Run it on your own work
Release notes needs an account, because it writes against what you give it and remembers what you have told it before. It runs on the Free plan. Or see what the plans cost first.