What the agent does
The run reaches Jira and Confluence through one connection: Atlassian's remote MCP server, https://mcp.atlassian.com/v2/mcp, the Atlassian entry in the Rush connector catalog. Connect it once with POST /me/connections {"type": "mcp", "name": "atlassian", "url": "https://mcp.atlassian.com/v2/mcp", "auth": {"mode": "oauth"}} and approve it from the authorize_url. The page is created as that Atlassian user, so connect with an account that can add pages in the release notes space.
The agent finds the version with a JQL search: project = APP AND fixVersion in releasedVersions(APP), ordered so the most recent release comes first, and reads the version's name and release date from the matching issues. Then it reads every issue in that fix version with its key, type, summary, description, status, labels and components.
Each issue gets one line. Stories and features go under "New", bugs under "Fixed", and anything labelled as a known issue, or still open in the version, under "Known issues". The line is rewritten for a customer: "Fix NPE in InvoiceExporter when currency null" becomes "Exporting an invoice with no currency no longer fails." Internal work such as refactors and test changes, by issue type or label, is left out and listed at the end of the run's answer so someone can put an item back. Every line keeps its Jira key.
Last, it creates the Confluence page Release notes <version> in the space named in the prompt, with the three sections and a line at the top giving the release date. If a page with that title already exists, it stops and says so rather than overwrite it. It does not edit any Jira issue, version or comment.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Atlassian connection. In Jira project APP, find the most recently released fix version and read every issue in it. In the Confluence space REL, create a page titled `Release notes <version>` with the release date and three sections: New, Fixed and Known issues, one plain-language line per issue written for customers, each ending with its Jira key. Leave out internal work (refactors, tests, chores) and list what you left out in your answer. If a page with that title exists, stop and tell me. Change no Jira issue.",
"connections": [
"atlassian"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The result is a new Confluence page in the space, titled with the version, holding the release date and the New, Fixed and Known issues sections. Each line is one sentence a customer can read, followed by the Jira key so your team can trace it. The session's result names the page, and lists the issues the agent left out as internal and why.
A product manager reads the page before sharing it. Check the rewritten lines against the issues they came from, especially for anything security-related or customer-specific that should not be public, and check the left-out list for something that belonged in the notes. The transcript holds the JQL search and every issue read, and the call that created the page.
Run it on every Jira version release
Release notes are due the moment a version is marked released. A Jira automation rule on the "Version released" event can send a web request to your endpoint with the version name, and your endpoint posts this request to POST /o/{org}/sessions with the version in the prompt.
When the run.completed webhook comes back, your server can read the session's result for the page's title and post it to the release channel for a final read before the notes go to customers.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Writing release notes means reading every issue in the version and translating ticket titles into sentences customers understand, which is why notes often ship days late or not at all. The agent does the reading and the first draft in its own sandbox, keeps every issue key, and puts the result where your team already publishes.
The page is created by one tool call you can see in the transcript, Jira is read only by prompt, and an existing page is never overwritten. Teams with several products can run one session per project at the same release, each with its own page.
Frequently asked questions
Can it write the notes to a draft instead of publishing the page?
Ask for that in the prompt, or have it create the page under a parent page your team keeps private until review. Either way, a person reads the page before it is shared.
What if our fix versions span several projects?
Name each project in the prompt. The agent searches each for the version and groups the lines by project inside the same three sections.
Will it change the Jira issues?
No. The prompt says change no Jira issue, and the transcript shows only search and read calls on the Jira side.
Can it match our existing release notes style?
Link last release's page in the prompt and ask the agent to follow its headings and tone. It reads that page through the same connection before writing the new one.