From mg-harness
Event-driven automation that runs when an issue enters a team's Triage column in Linear. Handles duplicate detection, priority parsing from free text, owner assignment via Triage Intelligence with domain-based fallback, and moving the issue out of Triage. Use when the user asks to "triage Linear issues", "auto-triage", "process the Triage queue", "set priority and assign", "clear the Triage column", "run Linear triage", or "run linear-triage-automation". Org-agnostic — expects a routing table and a triage fallback owner to be supplied by the calling team. Does NOT handle handing tickets between engineers (use linear-handoff), and does not cover anything expressible as a native Linear Triage Rule (label→assignee/priority/team) — those belong in Linear, not an agent.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mg-harness:linear-triage-automationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill is meant to sit on top of Linear's native triage capabilities, not replace them. Keep responsibilities split as follows:
This skill is meant to sit on top of Linear's native triage capabilities, not replace them. Keep responsibilities split as follows:
label → assignee, label → priority, label → team/project, status moves. Configure these in Linear itself; they are cheaper and more reliable than agent logic.If a task can be expressed as a Triage Rule, prefer that path and skip the agent.
When an issue enters Triage in the target team, run the steps below in order. Process one issue fully before moving to the next.
Before touching priority or assignee, check for duplicates:
Canceled).Marked as duplicate of <ORIGINAL-ID>. Closing in favor of the original.Parse explicit priority hints from the issue, in this search order:
Priority: <value> (case-insensitive). Allow simple Markdown like **Priority:** High or _Priority:_ p1.Priority: <value> pattern, or a leading priority token such as [P1], (urgent), P0:.Map the parsed value to Linear's five priority levels:
| Hint values | Linear Priority |
|---|---|
urgent, p0, critical, blocker, sev0, sev1, 1 | Urgent |
high, p1, sev2, 2 | High |
medium, normal, default, p2, sev3, 3 | Medium |
low, minor, p3, sev4, 4 | Low |
none, no priority, n/a, 0 | No priority |
Best-practice rubric — use only when the issue contains a free-text severity description but no explicit code (e.g., "this is breaking prod for everyone"):
Rules:
If no explicit Priority: field or recognizable priority token exists, leave priority unchanged.
If a hint exists but the value is unclear, conflicting, or maps to multiple buckets, leave priority unchanged and add this exact comment:
Unable to set priority automatically due to ambiguous priority value.
Only assign if the issue currently has no assignee. If an assignee is already set (by Triage Rules, by Triage Intelligence auto-apply, or by a human), skip this step entirely.
Choose exactly one owner using this cascade, stopping at the first confident match:
Triage Intelligence suggestion. If Triage Intelligence has auto-applied an assignee, accept it and stop. If it has strongly surfaced a single suggested assignee (high confidence, on the target team), take that suggestion — it wins over the routing table because it incorporates signal the routing table can't see (recent ownership, code-area expertise, related work).
Routing table. If the issue carries a label matching a functional area in the routing table, assign to the configured owner for that area.
Root-cause domain inferred from title + description:
Fallback. If no confident match exists, assign to the configured triage fallback owner and add this exact comment:
Routed to triage fallback. Please reassign if needed.
Tie-breakers (apply in order):
Conflict between Triage Intelligence and routing table: Triage Intelligence wins when its confidence is high. If its suggestion conflicts with a label-based route and confidence is low or absent, prefer the routing table. Never split-assign.
After Steps 2 and 3, evaluate the issue's resulting state against this matrix. The issue moves to the team's post-triage status (default: Todo) only when explicitly indicated; otherwise it stays in Triage.
| Priority outcome | Assignee outcome | Action |
|---|---|---|
| Set (Urgent / High / Medium / Low) | Non-fallback owner (from Triage Intelligence, routing table, or domain inference) | Move to post_triage_status (default Todo) |
| Set (Urgent / High / Medium / Low) | Already assigned before Step 3 (skipped) | Move to post_triage_status (default Todo) |
| Set (Urgent / High / Medium / Low) | Fallback owner | Stay in Triage — fallback comment signals a human is needed |
Unchanged or No priority | Non-fallback owner | Stay in Triage — needs a priority decision |
Unchanged or No priority | Fallback owner | Stay in Triage |
| Ambiguous priority (comment posted) | Any | Stay in Triage |
Rule of thumb: an issue leaves Triage only when both a real priority and a real owner are in place. Any fallback, ambiguity, or missing-priority state keeps it in Triage for human review.
This skill is organization-agnostic. The invoking team must supply the following config. The recommended machine-safe form is a flat key -> handle mapping; any equivalent representation (YAML, JSON, structured prompt) is fine as long as keys match exactly.
Routing table:
frontend -> user
backend -> user
infra -> user
integrations -> user
product -> user
security -> user
Other settings:
triage_fallback_owner -> user
post_triage_status -> Todo
duplicate_status -> Canceled
Notes:
frontend, backend, infra, integrations, product, security).post_triage_status and duplicate_status must match status names that exist in the target team's workflow.Example invocation:
Run linear-triage-automation on team
Platform. Routing:frontend -> @sam,backend -> @jules,infra -> @priya,integrations -> @kai,product -> @noor,security -> @rae.triage_fallback_owner -> @eng-lead,post_triage_status -> Todo,duplicate_status -> Canceled.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub mgrabovskyi/skills --plugin mg-harness