Release Notes Composer

Turn a Jira release into polished Confluence release notes in one conversation — every line traceable to a real issue.

Comment

Inspiration

What it does

How I built it

Challenges I ran into

Accomplishments that I'm proud of

What I learned

What's next for Release Notes Composer

Inspiration

Every release ends with the same unpaid work: someone opens Jira, filters dozens of tickets, copies titles into a document, rewrites them for humans, groups them, and then formats a Confluence page. It takes an afternoon and nobody enjoys it.

We noticed the worst part is not the writing — it is the reconciliation: making sure the notes mention only what actually shipped, and that every claim can be traced back to a ticket when a customer asks. That is exactly the kind of job an agent should do, and exactly the kind of job where a plain chatbot is not enough.

What it does

Release Notes Composer is a Forge app for Jira and Confluence. It adds a Rovo agent with two actions:

  1. Collect release changes. The agent asks for a project key and, optionally, a fix version, a "since" date or a custom JQL query. It runs the search as the signed-in user and returns a compact list: key, type, status, priority, assignee, labels, fix versions and a relative link.
  2. Publish release notes. After the user confirms the Confluence space and page title, the app converts the markdown draft into Confluence storage format, creates the page through the Confluence API v2, and turns every [ABC-123] marker into a real link back to Jira.

Between the two actions the agent does the part that needs judgement: it groups issues into New features, Improvements and Fixes, rewrites ticket titles into benefits for the reader, keeps the key at the end of each line, and refuses to publish without confirmation.

How we built it

  • Forge (Node.js 24 runtime) with one rovo:agent module and two action modules backed by functions.
  • Jira REST API v3 (/rest/api/3/search/jql) for the release query.
  • Confluence API v2 (/wiki/api/v2/spaces, /wiki/api/v2/pages) for publishing. API v1 returned HTTP 410 for both endpoints, so the whole publishing path is v2.
  • asUser() everywhere. The app never acts with broader permissions than the person talking to it; Jira and Confluence enforce that user's access.
  • No storage. No database, no key-value store, no external calls. The app is eligible for Runs on Atlassian.

Challenges we ran into

  • Confluence v1 is retired. The classic /wiki/rest/api/content endpoint answers 410 Gone. Moving to v2 meant resolving a numeric spaceId from a space key first, and rewriting the body as storage-format XHTML.
  • Links that 404. Confluence reports its base URL as .../wiki, while Jira issue pages live at the site root. Naively concatenating produced .../wiki/browse/ABC-1. Trimming /wiki fixed it.
  • Scopes. API v2 needs granular scopes (read:space:confluence, write:page:confluence) on top of the classic ones. Without them every call returns 401 Unauthorized; scope does not match.
  • Agents are opt-in. A Forge Rovo agent does not appear in the picker until the user enables it once under Browse agents. This is documented Forge behaviour, and it is the first thing a judge has to do.

Accomplishments that we're proud of

  • A complete loop: Jira query → human-readable draft → published Confluence page with clickable issue links, tested on a project with more than 50 issues.
  • The agent declines to invent content: when a fix version had no shipped issues, it said so instead of writing notes about work in progress.
  • Runs on Atlassian, zero storage, no third-party data flows.

What we learned

  • Rovo actions are a good fit for "read from one product, write to another" workflows: the model handles language, the functions handle permissions and formats.
  • Granular Confluence scopes are not optional any more; the classic ones silently fail on v2 endpoints.
  • A demo is only convincing when the output is a real artefact in a real product — a generated page beats a screenshot of generated text.

What's next

  • Diff mode: compare two releases and mark what changed since the last published page.
  • Bitbucket integration: include merged pull requests and their authors.
  • Templates per team (customer-facing vs internal), stored as Confluence templates.
  • Publish to Confluence and post a summary to a Jira release comment.

Judges: two-minute test

  1. Open the installation link, choose a site with Jira and Confluence, click Get app. The app installs into Jira (required) and can connect to Confluence (optional).
  2. In Jira open Chat (Ask Rovo) → agent selector → Browse agents → Release Notes Composer → Enable.
  3. Select the agent and send: Collect changes for project <KEY>, JQL: project = <KEY> ORDER BY created DESC
  4. Review the draft, then reply: Publish to <SPACE>, title: <TITLE> and confirm.
  5. The agent returns a link to the created Confluence page.

The agent needs permission to read issues in the project you name and to create pages in the space you confirm — both are checked as the signed-in user.

Share this project:

Updates

Submission history