What the agent does
The agent reads Linear through Linear's own remote MCP server, https://mcp.linear.app/mcp, connected once as an MCP server: POST /me/connections {"type": "mcp", "name": "linear-mcp", "url": "https://mcp.linear.app/mcp", "auth": {"mode": "oauth"}}, then the Linear sign-in from the authorize_url. Rush's built-in Linear sign-in, the one the console uses to pick issues and to fire Linear triggers, connects but cannot yet be named on a run, so this run names the MCP connection instead.
It starts by learning the team. It lists the team's workflow states to find the one of type triage, reads the team's labels so it suggests only labels that already exist, and reads issues closed or updated in the last two cycles to see who works on what. That history is how it suggests an assignee: the person who most recently closed issues touching the same area, label or component, with the issues it based that on.
Then it reads every issue in Triage: title, description, reporter, attachments it can read, and comments. For each one it searches the workspace for likely duplicates using the issue's key phrases, error strings and the screen or feature it names, and keeps a candidate only when the two describe the same behaviour, not merely the same area. It proposes a priority on Linear's own scale (Urgent, High, Medium, Low) with one sentence on why, such as a reported data loss or a workaround that exists.
The prompt says to change no issue, so the agent moves nothing out of Triage, sets no field and posts no comment. It writes triage.md in its sandbox, one entry per issue, ordered with the issues it would call Urgent or High first, for the team lead to apply in a few minutes.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Linear connection to read team ENG's workflow states, labels, and the issues completed in its last two cycles. Then read every issue in the team's Triage state with its description and comments. For each, search for likely duplicates and write triage.md proposing a priority (Urgent, High, Medium or Low) with a one-sentence reason, labels chosen only from the team's existing labels, an assignee based on who recently completed similar issues (name the issues), and any duplicate with a link and why. Order the file by proposed priority. Change no issue, field or comment.",
"connections": [
"linear-mcp"
]
}- 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 triage.md as an artifact. Each entry has the issue key and title linked to Linear, the proposed priority and its reason, labels, an assignee with the issues that suggest them, and a duplicate candidate when there is one. Issues the agent could not judge (a one-line report with no steps, say) are listed as needing more information, with the question to ask the reporter.
Every search and issue read is in the session's transcript, so a lead who disagrees with a duplicate call can see what the agent compared. Before applying the list, the lead checks the priority calls on anything customer-facing and confirms each duplicate before closing one, since closing the wrong issue loses a report.
Run it on every weekday morning
An automation with a schedule trigger in a Project starts this every weekday, with a cron such as 0 8 * * 1-5 and the team's timezone, and the Project's connections. The run reads Triage as it is at that moment, so the list covers whatever came in overnight.
With a webhook URL on the key, Rush POSTs run.completed when the turn ends. Your server can post the link to triage.md in the team's channel. If the lead wants the agent to apply its own suggestions, a follow-up message to the same session can ask it to, once a person has read the list.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Triage is the job that gets skipped when a team is busy, and a backlog of untriaged issues hides the one that matters. The agent reads every issue and searches for duplicates before anyone is online, in its own sandbox, and leaves a list a person can apply quickly instead of a queue they have to read from scratch.
Nothing changes in Linear until a person decides, and the session's transcript records each search the agent ran, so its duplicate and owner calls can be checked. One run per team can go at the same time, up to the key's concurrent run limit.
Frequently asked questions
Why connect Linear's MCP server instead of the Linear sign-in?
A run can name an MCP server connection today, while the built-in Linear sign-in connects but cannot yet be named on a run. Linear's own MCP server gives the agent issue search and reads, which is what triage needs.
Can it apply the priorities and labels itself?
It can, through the same connection, but this prompt tells it not to. Most teams read the list first; a follow-up message to the session can then ask it to apply the entries the lead approved.
Will it invent labels we do not use?
No. The prompt has it read the team's labels first and choose only from them. If nothing fits, the entry says so rather than proposing a new label.
How does it pick an assignee?
From the last two cycles: whoever completed issues with the same labels or touching the same feature. The entry names those issues, so the lead can see the reason and overrule it.