linear

What this skill does

# Linear

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

## When to Use

Activate when:
- Querying, creating, or updating Linear issues
- Authoring epics for VantageEx agent consumption
- Auditing existing epics for VantageEx compatibility
- Grooming epics to fix audit findings
- Transitioning issue workflow states
- Attaching GitHub PRs to Linear issues
- Working with Linear comments or description sections

## MCP Setup (Preferred)

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

```bash
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

```bash
# 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`):

```graphql
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

```graphql
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`:

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

Then transition:

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

### Add a Comment

```graphql
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:

```graphql
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

```graphql
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:

```graphql
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

| Section | Purpose | Author |
|---------|---------|--------|
| `## Objective` | 2-3 sentences defining success criteria | User (immutable) |
| `## Skills` | Domain-specific skills needed (core skills implicit) | User (immutable) |
| `## Repos` | Target repositories | User (immutable) |

### Optional Sections

| Section | Purpose | Author |
|---------|---------|--------|
| `## Instructions` | User guidance added at re-queue (ADR-027) | User or dashboard |
| `## Constraints` | Boundaries (defaults: `mise run ci`, no attribution, squash merge) | User |
| `## Agents` | Priority-ordered agent CLIs from `{claude, codex, antigravity, local}` (default `[claude]`) | User |
| `## Team` | Claude model layer: lead, default, escalation (applies when Agents resolves to `claude`) | User |
| `## Escalation` | Failure and ambiguity policies | User |
| `## PR` | Pull request URL when submitted | Agent |

### 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:

````markdown
## Skills

```yaml
- skill1
- skill2
```
````

CORRECT:

```markdown
## 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:

```markdown
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:

```markdown
## Design context

[full design content pasted here]
```

```markdown
## 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:

| VantageEx Status | Linear State | Meaning |
|-----------------|--------------|---------|
| `ready` | Backlog / Ready | Epic in backlog, all fields present |
| `up_next` | Up Next | User approved for agent work |
| `in_progress` | In Progress | Agent actively working |
| `needs_help` | Needs Help | Agent exhausted fix cycles |
| `review` | In Review | CI passed, PR created |
| `complete` | Done | PR merged |
| `archived` | Archived | Hidden from dashboard |

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-q