Linear

Linear

Manage Linear issues, author VantageEx-compatible epics, and interact with the Linear API via MCP or direct GraphQL.

MCP Setup (Preferred)

The Linear MCP server provides tool-based access to Linear. Set up once:

claude mcp add --transport http linear-server https://mcp.linear.app/mcp

Then run /mcp in a Claude Code session to complete OAuth authentication (opens browser).

After setup, use MCP tools directly for all Linear operations. The MCP server handles authentication and provides structured tool interfaces.

For full setup details, troubleshooting, and alternative client configurations, read references/mcp-setup.md.

GraphQL Fallback

When MCP is unavailable (headless environments, scripting, CI), use the GraphQL API directly.

Endpoint: https://api.linear.app/graphql Auth: Bearer token via LINEAR_API_KEY environment variable

# Test connectivity
curl -s -H "Authorization: Bearer $LINEAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ viewer { id name email } }"}' \
  https://api.linear.app/graphql

For the full query catalog, read references/graphql-api.md.

The nushell client at scripts/0.1.0/linear.nu wraps common GraphQL operations.

Common Operations

Query an Issue

By key (e.g., MT-686):

query IssueByKey($key: String!) {
  issue(id: $key) {
    id identifier title url description
    state { id name type }
    project { id name }
    labels { nodes { name } }
    attachments { nodes { title url sourceType } }
  }
}

Create an Issue

mutation CreateIssue($teamId: String!, $title: String!, $description: String, $stateId: String, $labelIds: [String!]) {
  issueCreate(input: {
    teamId: $teamId
    title: $title
    description: $description
    stateId: $stateId
    labelIds: $labelIds
  }) {
    success
    issue { id identifier url }
  }
}

Update Issue State

Always fetch team workflow states first to get the exact stateId:

query IssueTeamStates($id: String!) {
  issue(id: $id) {
    team {
      states { nodes { id name type } }
    }
  }
}

Then transition:

mutation MoveIssue($id: String!, $stateId: String!) {
  issueUpdate(id: $id, input: { stateId: $stateId }) {
    success
    issue { id identifier state { name } }
  }
}

Add a Comment

mutation CreateComment($issueId: String!, $body: String!) {
  commentCreate(input: { issueId: $issueId, body: $body }) {
    success
    comment { id url }
  }
}

Attach a GitHub PR

Prefer the GitHub-specific mutation for PR metadata:

mutation AttachPR($issueId: String!, $url: String!, $title: String) {
  attachmentLinkGitHubPR(issueId: $issueId, url: $url, title: $title, linkKind: links) {
    success
    attachment { id title url }
  }
}

List Workflow States

query TeamStates($teamId: String!) {
  team(id: $teamId) {
    states { nodes { id name type position } }
  }
}

Introspection

When an unfamiliar mutation or type is needed, query the schema:

query ListMutations {
  __type(name: "Mutation") { fields { name } }
}

query InspectInput($typeName: String!) {
  __type(name: $typeName) {
    inputFields { name type { kind name ofType { kind name } } }
  }
}

VantageEx Epic Format

VantageEx epics follow a three-level hierarchy: Epic (user-authored) -> Issues (team leader creates) -> Tasks (agents create).

The user authors the epic description in Linear. The epic body uses markdown sections that VantageEx parses.

Required Sections

Optional Sections

Title and Slug

• Title: Imperative statement ("Implement OAuth2 PKCE flow for API gateway")
• Slug: kebab-case, max ~30 chars, URL-safe (oauth-pkce-flow)
• Branch: feature/<epic-slug>

For the full epic specification with examples and anti-patterns, read references/epic-format.md.

Epic Body Format Rules

Epic bodies use plain markdown for every section. Parsers that ingest epic bodies (including the /linear:audit-epics command and downstream consumers) capture YAML fences as garbage labels.

No YAML fences in epic bodies

WRONG:

## Skills

```yaml
- skill1
- skill2
```

CORRECT:

## Skills

- skill1
- skill2

Skills, Repos, and Constraints sections all use plain bullet lists. Code fences in these sections produce empty or junk labels in the parser output.

Skill-label discipline

Skill labels listed in the epic body must exist in the claude-skills marketplace at https://github.com/vinnie357/claude-skills/blob/main/.claude-plugin/marketplace.json. The audit command checks this; missing labels are flagged.

Core skills are implicit and MUST NOT be listed in epic bodies: anti-fabrication, git, tdd, twelve-factor, security, mise, nushell. Listing them adds noise without value — every epic loads them by default.

Self-contained content

Epic bodies are self-contained. Workers pick up epics on any machine; local-filesystem paths (~/.claude/plans/..., /Users/<name>/...) resolve only on the author's system and fail everywhere else.

WRONG — points at a local file:

See `~/.claude/plans/foo.md` for the design context.

CORRECT — embed the content inline under a ## Design context (or similarly named) section, or link to another epic by URL:

## Design context

[full design content pasted here]

## Instructions

Design rationale lives in the paired docs epic [VIN-316](https://linear.app/...).

When a design plan is too large for a single body, split into paired epics (docs + implementation) linked by URL. Each epic carries its own self-contained context; cross-references between epics use URLs, never filesystem paths.

Initial state

New epics start in Backlog. Labels are team-scoped; missing skill labels auto-create on first use via issueLabelCreate.

Workflow States

Linear uses typed workflow states. VantageEx maps these to its lifecycle:

Key transitions:

• ready -> up_next: User only (the gate)
• up_next -> in_progress: EpicPickerWorker (automatic)
• in_progress -> needs_help: ValidateWorker (after 3 fix cycles)
• needs_help -> up_next: User re-queues with ## Instructions
• in_progress -> review: Agent submits PR
• review -> complete: User merges PR

For the full state machine and cross-system mapping, read references/workflow-states.md.

Commands

References

Templates

Scripts

Usage Rules

• Prefer MCP tools over raw GraphQL when the Linear MCP server is configured
• For state transitions, always fetch team states first — never hardcode stateId values
• Prefer attachmentLinkGitHubPR over attachmentLinkURL when linking GitHub PRs
• Keep queries narrow — request only the fields needed
• Treat top-level errors array in GraphQL responses as failures
• When writing epic descriptions, follow the section format exactly — VantageEx parses these programmatically