What the agent does
The agent starts with the team and its most recently completed cycle, recording the cycle identifier, boundaries and reporting cutoff. There is no repository resource. Attach an authorized Linear MCP connection id through connections in the body you actually submit; the minimal prompt below does not attach it. The developer quickstart's connection section currently says a built-in Linear sign-in connects but cannot yet be named on a run. Use a connected MCP server for this task rather than presenting that sign-in as working run access.
It reads cycle issues, project and assignee information, workflow states and the historical events the connection exposes. Completion at cycle end differs from completion today: an issue finished after the boundary should not retroactively improve the cycle's result. The agent resolves state meaning within the selected team rather than treating a state label shared by another team as equivalent. It paginates issue and history reads, records access gaps, and avoids treating an incomplete response as the entire cycle.
Scope change requires evidence of cycle membership over time. An issue's creation date alone cannot show when it entered the cycle, and current cycle membership can hide work that rolled forward. The agent looks for membership history, completion timestamps or a supplied start-of-cycle snapshot. It separates issues committed at the start, added later, removed and rolled over when the available evidence supports those categories. If the MCP tools provide only current issue fields, it reports the missing historical comparison instead of producing precise but unsupported scope totals.
For blockers, the agent reads accessible comments and issue relationships, cites the issue and relevant comment, and distinguishes an explicit blocking relationship from a person's description of a delay. It groups completion by assignee and project with unassigned and projectless work visible. Counts and estimates stay separate, with the denominator stated for any rate. It writes cycle-report.md as retrospective input, omitting unnecessary personal detail and leaving issue states, comments, assignments and cycle membership unchanged.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the attached Linear MCP connection to read the named team's most recently completed cycle. If the team is unspecified or inaccessible, report the missing scope instead of guessing. Write cycle-report.md with cycle boundaries and cutoff, issues completed by cycle end, rollover with observed state, issues added after the start, completion by assignee and project, and blockers supported by comments or issue relations. Use membership and state history where available; distinguish current fields from end-of-cycle facts and mark unavailable historical sections rather than inferring them from issue creation dates. Paginate, cite issue/comment links, state denominators and omit unnecessary personal data. Read only: change no issue, comment, project or cycle."
}- 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
cycle-report.md contains a cycle summary, completed-work list, rollover table, scope-change section, assignee and project breakdowns, and evidence-linked blockers. Its coverage note says whether the report reconstructs the cycle boundary from history or only describes the current fields it can read. That distinction prevents a report written after the retro from silently rewriting what the team had actually completed when the cycle closed.
The reviewer checks issue membership at the boundary, cancelled-work treatment, unassigned issues and the attribution rule for work that changed owners. Blocker summaries link to the supporting comment or relation without asserting an invented root cause. Rush returns the report as an artifact and the session answer summarizes missing evidence. The trajectory shows the read operations behind the analysis; this task writes no comments to Linear and makes no changes to the team's board.
Run it on every cycle close
Your scheduler or Linear webhook receiver can call POST /o/{org}/sessions after a cycle closes, using the team and cycle identifier as explicit input. Attach the Linear MCP connection and give that cycle's request an Idempotency-Key. Reuse the key for a retry of the same request, not for a later cycle or a changed cutoff.
Your service can collect the file after reading the finished session or receiving the key's completion webhook. Keep an opening snapshot if your connection cannot retrieve historical membership, and have the later report compare against that evidence. Publishing the report to a team channel or changing rollover assignments is a separate action, outside this read-only request.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A cycle review involves more than counting issues in a completed column. The agent needs to reconcile membership changes, state transitions and comment evidence while keeping the reporting boundary fixed. Rush gives that analysis its own sandbox and returns a report without requiring a repository or a developer's laptop to hold the working data.
The session record makes the summary auditable when a team asks why an issue counts as rollover or added scope. Separate team reviews can run within the API key's concurrency allowance, using explicitly attached connections and separate outputs. Your server gets files and the supporting read record rather than a board edit that changes the evidence being reviewed.
Frequently asked questions
Can I use my built-in Linear sign-in for this run?
The current quickstart says that sign-in can connect but cannot yet be named on a session. This page therefore uses an authorized Linear MCP server connection. Attach its id in connections before submitting the minimal request body.
How does it know an issue was added mid-cycle?
It needs a cycle-membership event or a trustworthy opening snapshot. An issue can exist long before being added to a cycle, so creation time does not answer that question. If the tools cannot expose the needed evidence, the report marks the scope-change section incomplete.
Does completion by assignee measure productivity?
It describes the selected work under an explicit attribution rule, not a person's productivity. Estimates, counts and issue types can represent very different effort. The report keeps those measures separate and avoids ranking people from a raw completion count.
Will it move unfinished issues into the next cycle?
No, this task reads and reports only. It records rollover evidence without changing cycle membership, status or ownership. Any board update or published summary needs a separate request that explicitly authorizes that action.