Linear

Claude skills, scripts and configs for everyday use

Install

npx -y skills add sakydev/claude --skill linear

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use this skill whenever the user shares a Linear.app ticket link or ticket ID (e.g. FLX-123, https://linear.app/…/issue/FLX-123/…). Fetch and deeply read the full ticket — description, status, assignee, all comments and replies — before doing any work. Raise concerns if the user's request conflicts with or diverges from what the ticket actually describes.

SKILL.md

2.1 KB, 447 tokens by cl100k_base, as published. Nobody here has run it

Linear Ticket Skill

Step 1 — Get the ticket ID

Parse it from whatever was given.

Input	Extracted
`FLX-123`	`FLX-123`
`https://linear.app/fluxend/issue/FLX-123/some-title`	`FLX-123`

Step 2 — Read everything

Do not skip a step.

mcp__linear-server__get_issue - title, description, status, priority, assignee, labels, parent, project.
mcp__linear-server__list_comments - every comment, every reply. Read them all. Replies often override the description.
mcp__linear-server__get_project - if the ticket belongs to a project.
mcp__linear-server__get_issue on the parent - if one exists.

Step 3 — Understand before acting

Build a clear picture of:

What the ticket asks for.
What comments changed or decided.
Current status.
Who owns it.

Step 4 — Raise concerns first

Check the user's request against what you read. Speak up before writing a single line of code.

Situation	Say
Ticket is Done or Cancelled	"This ticket is already [status]. Sure you want this?"
Request contradicts the ticket	"Ticket says X. You're asking for Y. Which one?"
Request is narrower than ticket	Say what you're not doing. Confirm that's fine.
Request is broader than ticket	"You're asking for Z. That's outside FLX-123. Include it or stay scoped?"
Comment overrides description	"Per [author] on [date], approach changed to X. Following that unless you say otherwise."
Ticket is vague	Ask the one most important question. Just one.

Nothing looks wrong? Proceed without comment. No "ticket looks good" preamble.

Step 5 — Work

Do what was asked with full ticket context in your head.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.