What the agent does
There is no repository to clone. The agent reads Jira through the Atlassian connection and writes a proposal. The catalog entry is slug atlassian, titled Atlassian (Jira / Confluence), and it describes searching, creating and updating Jira issues and Confluence pages. The remote is https://mcp.atlassian.com/v2/mcp and the catalog marks it oauth. Connect it with POST /me/connections, type mcp, name atlassian, that url, and auth mode oauth. Open authorize_url while signed in to cloud.getrush.ai as the key's creator. The row you name on the run is the one GET /me/connections lists once status is connected. This job uses the search. It does not use the create or update the catalog also allows.
The cut is issues in the backlog with no update in 90 days. The agent asks the connection for those issues and reads the summary, the status, the project and the comments that are already there. It does not browse Confluence unless a comment links a page that is the only statement of the bug. A sprint issue updated inside the 90 days is out of the file even if it looks stale in the backlog view. The prompt's window is the rule, and the file says which JQL or filter the connection was given so a reviewer can run it again.
Each issue gets one proposal: close, merge into another issue, or keep. Close is for an issue whose comments show it shipped or no longer applies. Merge is for two issues that describe the same bug, and the file names both keys and which one should survive. Keep is for an issue that is old and still real. Every line has a one-line reason taken from the summary or a comment, not from a priority guess. Likely duplicates are grouped even when the proposal is keep, so a person can see the cluster. The agent does not transition an issue, edit a field, or rank the backlog.
The file is triage.md. It is grouped by project, then by proposal. A project with no issue older than 90 days is a short section that says so. If the connection cannot see a project, the file names that project as unread rather than proposing close on an empty result. The point of the file is a list a person applies by hand.
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 read Jira backlog issues with no update in 90 days. Write triage.md that proposes close, merge into another issue, or keep for each, groups likely duplicates, and gives a one-line reason per issue drawn from the summary or a comment. Include the query you ran. Do not transition, edit, rank or comment on any issue. If a project is not visible, say so. Do not read Confluence except to open a page a Jira comment already links."
}- 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
What comes back is triage.md as an artifact. The session gives it a name, a mime type and a url that downloads without the key until url_expires_at. GET /o/{org}/sessions/{id}/artifacts/triage.md with the key fetches it later. The transcript lists the Jira searches and the issue keys that became lines, which is how you check the agent did not skip a project.
The file is a proposal. Each issue key appears once, with close, merge or keep, a reason, and a group id when it is a duplicate of another key. The surviving key of a merge is named. No issue in Jira has a new status, a new comment or a new label from this run. The absence of those writes is something you can see in the transcript's tool calls.
A reviewer takes one project and compares the file to the Jira filter for updated <= -90d. Keys in Jira that are missing from the file, and keys in the file that were updated more recently, are the defects. A bad merge suggestion is corrected by a follow-up message on the same session, POST /o/{org}/sessions/{id}/messages, after status leaves running. The agent rewrites the file. It still does not touch Jira.
Run it on every Monday morning
A Monday job on your server POSTs this body to https://api.prix.dev/o/{org}/sessions. Leave resources out. Set connections to the Atlassian connection's name or id. Use an Idempotency-Key that includes the Monday date so a retry does not produce two triage files for the same week. A connection that is pending or unknown is 422 CONNECTION_NOT_READY.
When the turn finishes, the key's webhook posts run.completed and session_url. Download triage.md and send it to the people who triage that project. One session is one site. A key's max_concurrent, 4 by default, is the cap, and the next site waits on 429.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A 90-day backlog is a pile of issues nobody wants to open one by one, and a bulk close is how a real bug disappears. The agent reads them through the Atlassian connection in a sandbox and writes a proposal with a reason on every line. Applying the proposal stays a human action in Jira.
The transcript is the proof of what was read and of what was not written. You can see the query and the keys. Next Monday is a new session with a new Idempotency-Key, and a follow-up on this week's session can regroup one project without searching the whole site again.
Frequently asked questions
Will it close issues or add a label?
No. The prompt forbids transitions, edits, ranks and comments. The catalog's connection can update issues, which is why the prompt is explicit. The transcript's tool calls are the check. If a call is a write, you do not apply the file, and you send a follow-up that asks for a read-only rerun.
Where is the connections field?
Add connections to the body, set to the name or id from GET /me/connections. The JSON on this page is the task. A key run is given only the connections it names. The Atlassian remote is https://mcp.atlassian.com/v2/mcp, connected with auth mode oauth. Naming a connection that is still pending returns 422 CONNECTION_NOT_READY.
Does it include Confluence pages?
Only a page that a Jira comment already links, and only as evidence for that issue's reason. The job is the backlog, not a space audit. A Confluence-only stale page does not get a close, merge or keep line.
What counts as no update in 90 days?
No update on the issue in that window, which is the prompt's rule. The file records the query so you can see whether updated or a status change was the field. A comment inside the window counts as an update. The agent does not substitute created date when updated is available.
Two issues look similar but are not the same bug. What does merge mean?
Merge is a proposal that names both keys and the one to keep. It is not a Jira link the agent creates. If the summaries only share a word, the proposal should be keep, in a duplicate group marked as weak, with the reason saying they were not merged. You delete that group when you review.