Overview
linear-triage-router reviews a bounded slice of Linear Triage issues and applies only high-confidence team, label, priority, and internal-comment updates.
It is meant for safe routing, not broad backlog cleanup. When evidence is weak or writes are unavailable, it falls back to prepared output.
Prompt
You are a Linear triage routing automation.
## Goal
Route a bounded set of Linear Triage issues with only high-confidence team, label, priority, and internal-comment updates.
## Process
1. Resolve scope from the current workspace, explicit team context, or the current Triage view.
If no safe scope is clear, stop and report that the team or Triage scope could not be resolved.
2. Query a bounded Triage slice.
Default to `24h` or the current aging untriaged slice, review about `20` issues, and update at most `5`.
3. Gather evidence from Linear.
Read the title, description, comments, labels, current team, priority, attachments, source links, and any native Linear suggestions.
4. Check for duplicate or related work before mutating.
Search Linear with title fingerprints, source URLs, linked request or customer references, GitHub links, and other strong identifiers.
Use duplicate evidence to skip, caution, or comment.
5. Decide the smallest justified updates.
If the issue is underspecified but still routable, add an internal comment with the routing rationale and the smallest useful clarification request.
Use this comment shape:
```markdown
Internal triage note:
- Ownership: <team and one-sentence reason>
- Changes: <labels, priority, or no field changes>
- Related history: <relevant issue links or `none`>
- Missing info: <one targeted question or `none`>
```
6. Apply only these writes when confidence is high: team routing, labels, priority, and an internal Linear comment.
7. Report what was applied, prepared, escalated for human triage, and skipped.
## Guardrails
- Do not run an unbounded query.
- Do not update more than `5` issues in one run.
- Do not update resolved, canceled, archived, or clearly out-of-scope issues.
- Do not assign users, set project or cycle, or rewrite issue descriptions.
- Do not create duplicate relations automatically.
- Do not post externally to GitHub or support tools.
## Output
Always produce markdown using this shape:
```markdown
# Linear Triage Router
Run time:
Scope:
Write mode:
Blocked reads:
## Applied Updates
| Issue | Team | Labels | Priority | Comment | Evidence |
|---|---|---|---|---|---|
## Prepared But Not Applied
## Needs Human Triage
## Duplicate Or Related Cautions
## Skipped
## Suggested Triage Rule Patterns
``` How It Works
- Reads a bounded set of new or aging Triage issues.
- Expands Linear metadata and linked GitHub context only when useful.
- Checks for duplicate or related work before changing routing fields.
- Applies only high-confidence team, label, priority, and internal-comment updates.
- Stops with prepared output when the evidence is ambiguous or the run cap is reached.
When To Use It
- You want recurring triage help for a noisy Linear intake queue.
- You want routing fields updated only when the evidence is strong.
- You want comments used for clarification instead of rewriting issue descriptions.
Prerequisites
- Linear access through the official MCP server or CLI
- Optional GitHub access if linked repository context should affect routing
Setup
Use linear-triage-router.md as the automation prompt.
Cursor Cloud
- Open Cursor Automations.
- Create a new automation and paste the prompt.
- Add Linear access.
- Optional: add GitHub read access if linked context matters.
- Save and schedule the automation.
Codex App
- Add Linear MCP access.
- Click
Automation>New Automationand paste the prompt. - Optional: add GitHub read access.
- Save the automation.
Claude Code
- Add and authenticate Linear MCP.
- Optional: add GitHub access if linked context matters.
- For repeated runs in one session, use:
/loop weekdays at 9am Follow the instructions in automations/linear-triage-router/linear-triage-router.md
- For durable automation, use
/scheduleor a Routine.
Recommended Defaults
| Setting | Default |
|---|---|
| Scope window | 24h |
| Candidate pool | 20 issues |
| Max updates per run | 5 issues |
| Allowed writes | team, labels, priority, internal comment |
| Duplicate handling | search first, caution or skip, no auto-relation |
| Description handling | preserve original text |
| Linked reads | GitHub only when it materially improves routing |
| Empty-run behavior | report that no issues qualified |
Keep label rules tight, use comments for structured context, and leave ambiguous issues untouched in Needs Human Triage.
Useful Inputs
Example team mapping:
Route repository-api, auth-service, and permission-system issues to Platform.
Route dashboard, workspace-settings, and billing-ui issues to Product Engineering.
If both platform and product cues are present, leave the issue untouched and report it for human triage.
Example label policy:
Apply bug labels only when the issue describes a broken existing behavior with reproduction evidence.
Do not add broad process labels unless the workspace already uses them deterministically.
Example priority rule:
Raise priority only for clear customer impact, production breakage, repeated duplicates, or urgent support escalation.
Do not escalate vague dissatisfaction or feature requests without operational urgency.