# Linear

## Access

Prefer Linear's MCP server or another available Linear connector. Otherwise use a Linear CLI or API access the user has already configured. Never ask for an API key in chat or write one into a file or command. If neither is available, hand back the drafts.

## Destination and visibility

An issue needs a **team**; a **project** (and a project milestone) is optional. List teams and projects to confirm exact names rather than guessing. Issues are visible to workspace members who can access the team, and a private team limits that further; say which applies in the preview.

Leave the issue in the team's default state, and don't set assignee, priority, estimate, or cycle unless the user asks or the source specifies them.

## Duplicates and labels

Search the team's issues by title and description keywords, including completed and canceled ones (and archived ones when the tool allows).

Labels exist at the workspace and team level. Retired labels and label groups can't be applied. Create an approved missing label on the team unless the user asks for a workspace label, which every team would see.

## Create and read back

Pass the description as Markdown with real newlines, not escaped sequences. Attach the source spec as a link on the issue when the tool supports links, in addition to the body's Source spec line. After creating, fetch each issue and confirm its title, description, labels, and relations.

## Dependencies

Linear has native relations. Create blockers first, then set **blocked by** on each dependent issue (in Linear's MCP server, the `blockedBy` field of `save_issue`). Keep the body's Dependencies section as well. Use a parent issue with sub-issues only when the user wants that structure.