npx skills add ...
npx skills add getsentry/sdk-skills --skill linear-type-labeler
npx skills add getsentry/sdk-skills --skill linear-type-labeler
Classify and apply Type labels to Linear issues based on their title and description.
Classifies Linear issues and applies a Type label from the Sentry workspace's label taxonomy based on the content of each issue's title and description.
This skill requires the Linear MCP server to be configured.
Type labels in the Sentry workspace (workspace-level, not per-team):
| Label | When to use |
|---|---|
| Bug | Something is broken, regression, error, crash, incorrect behavior |
| Feature | New capability, integration, API, SDK support — something that doesn't exist yet |
| Improvement | Making existing functionality better — performance, DX, UX, reliability |
| Task | Chore, investigation, spike, migration, cleanup, operational work |
| Tracking Issue | Parent/umbrella tracking a larger body of work; has sub-issues or a checklist |
| Docs | Documentation, RFC, write-up, changelog, guide |
| Tests | Writing or fixing tests, coverage, test infrastructure |
Two modes:
A — List of Linear IDs provided (e.g. SDK-123, SDK-456):
get_issue. Skip the team-fetch step entirely.B — No IDs provided:
getsentry org, the repo name
matches the Linear team name, (2) explicitly stated by the user, (3) if still ambiguous, ask.Use query_data to fetch workspace-level labels and build a UUID map:
If the workspace has no "Type" label group, surface that to the user before proceeding.
If in mode A (list of IDs): use the already-fetched issues from Step 1. Filter client-side: keep only those where none of the issue's label IDs appear in the Step 2 UUID map values.
If in mode B (team): use query_data to list issues for the team, including each issue's
label IDs. Paginate (limit 50, use cursor) until done. Filter client-side: keep only issues
where none of the issue's label IDs appear in the Step 2 UUID map values (i.e., no Type label
assigned yet).
Announce the total candidate count before continuing. If there are more than 25 candidates, process in chunks of 25, confirming each chunk before the next.
For each candidate issue, read its title and description. Apply heuristics in priority order — stop at the first match:
[META], [EPIC], "Track", "Tracking"; or description has a checklist of
Linear/GitHub issue links → Tracking IssueWhen ambiguous between Feature and Improvement: does it add something that doesn't exist at all, or make something existing better? Former → Feature, latter → Improvement.
When ambiguous between Task and Improvement: is there a user-visible benefit (better performance, reliability, DX, API ergonomics)? If yes → Improvement. If it's purely internal with no user-visible impact → Task.
Assign exactly one Type label. Mark confidence:
Show a summary table before writing anything:
Ask: "Should I apply these labels? Reply with any corrections (e.g. 'SDK-789 → Bug') and I'll update the plan before applying."
If the user provides corrections, update the table and show the revised plan before proceeding.
For each approved classification:
get_issue to fetch the issue's current label IDs immediately before writingsave_issue with the full combined label setAlways re-fetch and always pass the full combined set. Linear replaces labels on update — labels added between Step 3 and now would be silently stripped if you use the cached label list.
Report as you go: "SDK-123 → Bug", "SDK-456 → Feature".