What the agent does
The run reads Jira through Atlassian's remote MCP server, https://mcp.atlassian.com/v2/mcp, the Atlassian entry in the Rush connector catalog, which covers Jira and Confluence. Connect it once with POST /me/connections {"type": "mcp", "name": "atlassian", "url": "https://mcp.atlassian.com/v2/mcp", "auth": {"mode": "oauth"}} and finish the Atlassian sign-in from the authorize_url. The agent can then search issues in every Jira site and project the signed-in account can see.
It begins by finding the sprint. A JQL search such as project = WEB AND sprint in closedSprints() ORDER BY updated DESC returns issues that belonged to closed sprints, and each issue's sprint field names the sprint with its start and end dates. The agent picks the one that ended most recently, then lists every issue in it with its type, status, assignee, story points (the custom field your site uses for them, which it identifies by name) and resolution.
From that list it sorts issues into done and not done by status category, so a team's own status names ("Ready for QA", "Blocked") still land on the right side. For scope added after the start, it reads each issue's change history where the server returns it and looks for the sprint being added after the start date; where history is not available it falls back to comparing the issue's creation date with the sprint start, and the report says which method each flagged issue came from. It adds up points committed at the start against points done at the end.
Last, it reads the comments on every issue that did not finish, looking for blockers people wrote down: waiting on another team, a failed review, a missing design. Each blocker in the report quotes the comment and links the issue. The prompt says read only, so the agent moves no issue, edits no field and posts no 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 to find the most recently closed sprint in Jira project WEB. Write sprint-report.md with: the sprint name and dates; issues completed; issues not completed with their current status and assignee; issues added after the sprint started and how you determined that; story points committed at the start versus done at the end; and blockers mentioned in comments on unfinished issues, quoting the comment and linking the issue. Read only: change no issue, field or comment.",
"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 session returns sprint-report.md as an artifact. It starts with the sprint's name, dates and a points line (committed, done, added), then four lists: completed, not completed, added after the start, and blockers. Every issue appears by key with a link back to Jira, so the retro can open any of them in one click.
The not-completed list is the part a team argues about, and each entry carries the status it ended in and the comment that explains it, when there is one. The session's transcript holds every JQL search and issue read the agent made, with what came back, so a scrum master can check why an issue was counted as added mid-sprint. Before the retro, check that the points field the agent used is the one your board uses, and that issues moved to the next sprint are counted the way your team counts them.
Run it on every sprint end
If your sprints are a fixed length, an automation with a schedule trigger in a Project can fire on the morning after the last day, on a cron like every second Monday. If they are not, a Jira automation rule on sprint completion can call a small endpoint on your server that sends this request with the project key in the prompt.
When the turn finishes, Rush POSTs run.completed to the key's webhook with the session_url. Your server can read the session and drop the report into the retro's Confluence page or Slack channel, so the team arrives with the facts already gathered.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Jira's built-in sprint report shows the burndown but not the reasons, and gathering the comments that explain each slipped issue is the slow part of preparing a retro. The agent reads every unfinished issue's comments in its own sandbox and writes the reasons next to the numbers, so the meeting spends its time on what to change.
It is a real read of your Jira, not a summary from memory: each search and its result are kept in the session's transcript. Several teams' reports can run at once, one per project, up to the key's concurrent run limit, and each is a separate session you can read, follow up on or share.
Frequently asked questions
We use a custom field for story points. Will it find it?
Usually. The agent reads the field names on the sprint's issues and picks the one named for story points or estimates. If your site uses a different name, put the field's name in the prompt and it uses that one.
Can it also write the report into Confluence?
Yes. The same Atlassian connection reaches Confluence. Change the prompt to create a page in your retro space, and the report lands there instead of, or as well as, the Markdown file.
How does it decide an issue was added mid-sprint?
From the issue's change history when the server returns it: the sprint field was set after the sprint's start date. Without history it compares creation date and start date, which misses issues created earlier and pulled in later. The report labels which method each flagged issue came from.
Will it touch our board?
The prompt says read only, and the transcript lists every tool call, so you can confirm that nothing was written. Connecting with a Jira account that can only browse projects makes that a hard limit.