Jira will generate release notes for you, for free, in about four clicks. Most teams still rewrite them by hand before anyone outside engineering sees them. That gap between what the button produces and what actually ships is the whole job, and it is worth being precise about, because automating the wrong half of it wastes a week.
What Jira already does for free
Start here, because a surprising number of teams build an integration to fetch something Jira exposes natively. In a software space you go to the Releases tab, pick the version, select Release notes, then Create release notes in Jira. Formatting options let you choose which fields appear, and you can either copy the result to the clipboard as markdown or HTML, or save it into the Related work section of the version.
Two details in Atlassian's documentation are worth knowing before you design anything around it. The first is that release notes are regenerated every time you view them, based on the current state of the version, and when you save them you are saving the format, not the content. The output is a live view, not a snapshot, so it is not a record of what you shipped. The second is that media is not supported: rich text and plain text fields come through, but images, videos and other files do not. If your release notes carry screenshots, the native feature cannot be the final artefact.
You can also add your own rich text field, a Paragraph field named something like "Release notes", to individual work items, and then include it from the formatting options. That is the closest native Jira gets to a human-written note per ticket, and it works, provided somebody fills it in on every ticket, every time.
Why the output still gets rewritten
The native generator is faithful to Jira, and that is exactly the problem. It reproduces how engineering organised the work, when release notes are read by people who do not care how the work was organised.
| What Jira produces | What actually ships to users |
|---|---|
| Grouped by work type: Story, Bug, Task | Grouped by outcome: what is new, what got better, what got fixed |
| Ticket titles written for the assignee | Sentences written for someone who has never seen the codebase |
| Every item in the version | The subset a user would notice, with internal chores dropped |
| One flat list per version | Highlights first, detail below, breaking changes called out |
| No images, per the documented limitation | Screenshots for anything visual |
| A live view that changes when the version changes | A dated, immutable record of a specific release |
Read down the right-hand column and you have the actual job description for the agent. None of it requires access Jira does not already give you. All of it requires judgment applied to text, which is the thing worth delegating.
What to hand an agent
The instruction that works is narrower than "write our release notes". Specify the inputs, the exclusions and the shape of the output, and the quality jumps.
| Element | What to specify |
|---|---|
| Input | The version's generated notes, plus each work item's summary, description and your custom release notes field where it exists |
| Exclusions | Internal refactors, dependency bumps, test-only changes, reverted work, and anything labelled internal |
| Grouping | New, Improved, Fixed, and a separate Breaking changes block that is never merged into the others |
| Voice | Second person, present tense, no ticket keys in the customer-facing copy |
| Length | One sentence per item, with a highlights section capped at three to five entries |
| Escalation | Flag anything it cannot describe in user terms rather than inventing a benefit |
That last row is the one people leave out, and it is the one that keeps the output honest. A ticket titled "fix race condition in queue consumer" has no user-facing description, and an agent asked to write one will cheerfully invent "improved reliability and performance". Better that it hands the item back and says it needs a human sentence.
A working setup, end to end
The version ships. The agent pulls the work items for that version, filters against the exclusion list, and reads each remaining item's description rather than only its title, because titles are where the internal shorthand lives and descriptions are where the intent is. It drafts the note in the four blocks above, marks every item it could not translate, and posts the draft somewhere a human sees it before anything is published. A person spends five minutes on the flagged items and approves.
The approval step is not optional and it is not a transitional phase you graduate out of. Release notes are a public statement about what your software does, and the failure mode is not a typo, it is confidently describing a change that did not happen. If you want the wider pattern for keeping a human in the loop on agent output, AI agent security best practices covers permissions and approval gates, and connecting an agent to a private API covers the mechanics of the Jira side without over-scoping the credential.
This pairs naturally with the rest of the Jira housekeeping an agent can take over. If your versions are messy going into a release, the notes will be too, and Jira backlog grooming and issue grooming both cover cleaning that up upstream. For teams whose notes land in Confluence afterwards, Confluence stale page cleanup deals with the documentation that goes out of date the moment the release lands.
What goes wrong
We run this pattern on our own releases, and the failures have been consistent enough to be worth naming.
The first is over-inclusion. An agent given the whole version will faithfully report all of it, including the three tickets that were opened, worked on and reverted in the same sprint. The exclusion list is not a nicety, it is the difference between a note somebody reads and a changelog nobody does. The second is invented benefit, described above, and the fix is the escalation rule rather than a better prompt. The third is the quietest: because Jira regenerates its notes from the current state of the version, moving a ticket in or out of a version after the fact silently changes what the source looked like. If you care about an accurate historical record, save the agent's approved output somewhere immutable, because Jira is not storing it for you.
The honest limit of the whole exercise is that it does not remove the human, it moves them. You stop writing release notes and start editing them. For a fortnightly release that is a real saving. For a team shipping once a quarter it is probably not worth the setup, and you should write them by hand.
Frequently asked questions
Can Jira generate release notes automatically?
Yes. In a software space, open the Releases tab, select the version, choose Release notes, then Create release notes in Jira. You can pick which fields appear under Formatting options and copy the result as markdown or HTML, or save it to the Related work section of the version. It covers every work item in the version, grouped by work type.
Why do teams still rewrite Jira's release notes?
Because the native output is organised the way engineering worked, not the way users read. It groups by issue type rather than by outcome, uses ticket titles written for the assignee, includes internal work a customer would not notice, and cannot carry images. The rewrite is where the judgment lives, which is the part worth automating.
Does Jira save a copy of the release notes?
Not the content. Atlassian's documentation states that release notes are regenerated each time you view them based on the current state of the version, and that saving them stores the format rather than the content. If you need a fixed record of what a given release contained, store the approved version yourself.
Can release notes include screenshots?
Not through Jira's built-in generator. The documentation says release notes can include rich text and plain text fields, but media such as images, videos and other files are not yet supported. Anything visual has to be added in whatever document you publish.
What should the agent not be allowed to do?
Publish without review, and invent a user-facing benefit for a change it cannot describe. Give it an explicit instruction to flag untranslatable items rather than guessing, and keep a human approval step between the draft and anything customer-facing. The risk with release notes is not a typo, it is confidently describing a change that did not ship.
How much does it cost to run this?
Less than the meeting you would spend writing them. On Gravity the free tier covers one agent at $0 a month, which is enough to run this on a single project and see whether the output is usable, and paid plans start at $20 a month with $20 of usage included, with extra usage available beyond the plan. For how that compares across the category, see our roundup of the cheapest AI agent platforms.
Sources
- Atlassian. "Create release notes." support.atlassian.com, checked 21 August 2026. Source for the Releases tab workflow, the Formatting options and clipboard or Related work output, the grouping of work items by work type, the custom Paragraph field method, the statement that notes are regenerated on view and that saving stores the format rather than the content, and the documented lack of support for images, videos and other media.
- Gravity pricing: free tier with one agent at $0 per month; paid plans from $20 per month including $20 of usage, with extra usage available beyond the plan. Checked 21 August 2026.
- Related reading: Jira backlog grooming, Jira issue grooming, Confluence stale page cleanup, what an AI agent is.