Using Linear

Linear issue tracking for CaseMark projects via the Linear MCP.

Related Skills

Skill	Use When
contributing	Branch naming, commits, PR workflow
using-vercel	Linking deployment URLs to issues
using-neon	Database issues to track
configuring-mcps	Setting up Linear MCP

Linear MCP Tools

See configuring-mcps for setup. Auth via OAuth (browser popup).

Tool	Purpose
linear_get_issue	Get issue details
linear_update_issue	Update status, assignee, labels
linear_create_issue	Create new issues
linear_create_comment	Add comments to issues
linear_list_issues	Search/filter issues
linear_list_teams	List available teams
linear_list_projects	List projects
linear_list_issue_statuses	Get workflow states for a team

Quick Patterns

// Get issue details
linear_get_issue({ id: "CD-123" })

// Update status
linear_update_issue({ id: "CD-123", state: "In Progress" })

// Add comment
linear_create_comment({ issueId: "CD-123", body: "Started work. Creating branch..." })

// Create issue
linear_create_issue({
  title: "Fix auth bug",
  description: "Details...",
  team: "CaseDev",
  labels: ["bug"]
})

// List my in-progress issues
linear_list_issues({ assignee: "me", state: "In Progress" })

Workflow States

State	Meaning
Triage	New, needs review
Backlog	Approved, not started
In Progress	Actively working
In Review	PR open, awaiting review
Done/Merged	Complete

Starting Work Checklist

Load contributing skill for full git workflow. Quick reference:

Start Work:
- [ ] Get ticket: linear_get_issue({ id: "CD-xxx" })
- [ ] Update status: linear_update_issue({ id: "CD-xxx", state: "In Progress" })
- [ ] Create branch: git checkout -b agent/CD-xxx-slug
- [ ] Make changes, commit with ticket ID
- [ ] See `contributing` skill for PR workflow

Discovered Issues Pattern

When you find an unrelated bug while working:

When to Create Separate Issue

Create a new issue if:

• Different app/package than current work
• Conceptually unrelated to ticket scope
• Would make PR harder to review

When to Fix Inline

Fix directly if:

• Trivial (<5 lines)
• Directly related to ticket scope

Creating a Blocking Issue

// 1. Create the blocking issue
linear_create_issue({
  title: "Fix router auth middleware null check",
  description: "Discovered while working on CD-123. The middleware crashes when...",
  team: "CaseDev",
  labels: ["bug"],
  blocks: ["CD-123"]
})

// 2. Document in original issue
linear_create_comment({
  issueId: "CD-123",
  body: "Discovered router bug that blocks this. Created CD-124 to track."
})

Scope Creep Detection

Signs your branch is growing beyond ticket scope:

• Changes span multiple unrelated areas
• Fixing "while I'm here" issues
• Commit messages reference different problems

Action: Stop, propose splitting into focused issues:

linear_create_issue({
  title: "Refactor auth middleware",
  description: "Split from CD-123. Focused on...",
  team: "CaseDev",
  labels: ["refactor"]
})

Linking PRs

After creating a PR (see contributing skill):

linear_update_issue({ id: "CD-123", state: "In Review" })

linear_create_comment({
  issueId: "CD-123",
  body: "PR: https://github.com/CaseMark/repo/pull/456"
})

Stop and Ask

Stop and ask if:

• Ticket requirements are ambiguous
• Discovered bug blocks current work
• Changes growing beyond ticket scope
• Need to modify shared infrastructure

Proceed if:

• Ticket is clear and scoped
• Creating blocking issues for discovered bugs
• Updating status through normal workflow