Claude Code with Linear

Updated January 2026 | 6 min read

Linear tracks your development work. Issue backlogs. Sprint planning. Feature priorities. Team capacity. All the context you need to understand what you're building and why.

But Claude Code can't see any of it. Every time you ask Claude to help plan a sprint, write a project update, or explain a technical decision, you're re-explaining context that already exists in Linear.

You describe issue states. You list sprint goals. You explain why features were prioritized. You copy-paste issue descriptions. You're building software with AI, but the AI doesn't know what you're building.

Why Linear Needs AI Memory

Linear organizes your development process. It doesn't help AI understand your project context.

Claude doesn't know:

• What features are in your current sprint
• Why you prioritized them over other backlog items
• How your team defines "in progress" versus "ready for review"
• Which issues are blocked and why
• Your team's velocity and capacity
• The relationship between epics, issues, and sub-tasks
• Technical decisions documented in issue comments

Linear's interface shows this information. But it's trapped there. Claude can't access it. You're the translator between your project management tool and your AI assistant.

You need a context bridge that makes your Linear workspace readable by Claude.

How to Connect Linear to Claude Code

You're not building a custom integration. You're creating a markdown-based memory layer that captures your Linear context and makes it accessible to Claude.

The architecture:

1. Export project structure — Teams, projects, workflow states
2. Export active work — Current sprint, backlog priorities, blocked issues
3. Export key decisions — Technical discussions from issue comments
4. Store in Obsidian vault as markdown files
5. Create a CLAUDE.md file that explains your development process
6. Let Claude Code read the vault for project context

Linear stays your source of truth. The vault becomes Claude's project memory. Updates flow manually when context changes.

What to Export from Linear

Don't export everything. Linear can contain thousands of issues. Export the context Claude needs to understand your current work and past decisions:

• Project structure — Teams, projects, workflow states, labels
• Current sprint — Active issues, assignees, progress
• Backlog priorities — Top 20 issues, why they're prioritized
• Epic definitions — Major features, their scope, and status
• Blocked issues — What's stuck and why
• Technical decisions — Architecture choices, tradeoffs, discussions from comments
• Team velocity — Historical sprint completion rates

Focus on active context and reference data, not complete history.

Exporting Project Structure

Your Linear workspace has organizational logic. Claude needs to understand it.

Document:

• Team names and their focus areas
• Project names and purposes
• Workflow states and what they mean
• Label taxonomy
• Priority levels

Example markdown format:

---
workspace: Acme Software
last-updated: 2026-01-28
---

# Linear Workspace Structure

## Teams

### Engineering
**Focus:** Core product development
**Members:** 8 engineers
**Projects:** Web App, Mobile App, API

### Design
**Focus:** UI/UX for all products
**Members:** 3 designers
**Projects:** Design System, User Research

## Workflow States

- **Backlog** — Not yet prioritized
- **Todo** — Prioritized for upcoming work
- **In Progress** — Actively being worked on
- **In Review** — Code written, awaiting review
- **Done** — Completed and deployed
- **Canceled** — Decided not to pursue

## Priority Levels

- **Urgent** — Blocking production, security issues
- **High** — Key features for current quarter
- **Medium** — Important but not time-sensitive
- **Low** — Nice-to-have improvements

## Labels

- `bug` — Something broken
- `feature` — New functionality
- `improvement` — Enhancement to existing feature
- `tech-debt` — Code quality, refactoring
- `customer-request` — Came from customer feedback
    

This schema helps Claude understand your Linear organization without seeing every issue.

Exporting Current Sprint

Your active sprint is the most important context. Export it as a markdown table.

In Linear, filter for current cycle/sprint. Export or copy issues into markdown:

## Current Sprint: Jan 22-Feb 5, 2026

**Goal:** Ship payment integrations and improve dashboard performance

| ID | Title | Assignee | Status | Priority | Labels |
|----|-------|----------|--------|----------|--------|
| ENG-234 | Add Stripe payment integration | Sarah | In Progress | High | feature, customer-request |
| ENG-235 | Optimize dashboard query performance | Mike | In Review | High | improvement, tech-debt |
| ENG-236 | Fix mobile nav bug on iOS | Jennifer | Done | Urgent | bug |
| ENG-237 | Add CSV export for reports | Alex | Todo | Medium | feature |

**Capacity:** 8 engineers × 8 days = 64 dev-days
**Committed:** 48 dev-days
**Completed:** 12 dev-days (25%)

**Blockers:**
- ENG-234 blocked on Stripe API keys (waiting for DevOps)
    

Update this at the start of each sprint. Claude can reference it when helping with sprint-related work.

Exporting Backlog Priorities

Your backlog contains future work. Export the top priorities with context about why they matter.

## Backlog Priorities (Top 20)

Updated: 2026-01-28

### Tier 1 (Next Sprint)

**ENG-240: Multi-user account support**
- Priority: High
- Why: 12 enterprise customers requesting it, blocking $400K in expansion deals
- Estimate: 13 points
- Dependencies: None

**ENG-241: Email notification system**
- Priority: High
- Why: Top feature request (47 votes), core to product experience
- Estimate: 8 points
- Dependencies: Email service provider decision

### Tier 2 (This Quarter)

**ENG-245: Dark mode**
- Priority: Medium
- Why: Nice-to-have, 23 customer requests
- Estimate: 5 points
- Dependencies: Design system updates
    

This context helps Claude understand why features are prioritized and what's coming next.

Documenting Technical Decisions

Linear issue comments contain valuable technical discussions. Architecture choices. Tradeoffs considered. Implementation approaches.

Export key decision threads:

## Technical Decision: API Architecture

**Issue:** ENG-234 (Stripe integration)
**Date:** 2026-01-20
**Participants:** Sarah, Mike, Tech Lead

### Context
Need to integrate Stripe payments. Two approaches considered:

1. Direct Stripe API calls from frontend
2. Backend proxy with our API wrapping Stripe

### Discussion

**Sarah:** Direct calls are simpler, less code on our end.

**Mike:** But then we're exposing Stripe API keys to frontend. Security risk. Also harder to test.

**Tech Lead:** Agree with Mike. Backend proxy gives us better control, lets us add business logic, easier to swap payment providers later if needed.

### Decision
Backend proxy approach. Create `/api/payments` endpoint that wraps Stripe calls.

**Tradeoffs:**
- More backend code (estimated +2 days)
- Better security
- More flexibility for future changes
- Easier testing

**Implementation plan:** See ENG-234 for details
    

When Claude reads this, it understands not just what you're building, but why you're building it that way.

Setting Up Your Vault Structure

Your Obsidian vault needs clear organization so Claude can find Linear context fast.

Example structure:

/Linear/
  /Structure/
    workspace-organization.md
    workflow-states.md
    team-structure.md
  /Active-Work/
    current-sprint.md
    backlog-priorities.md
    blocked-issues.md
  /Epics/
    payment-integrations.md
    dashboard-redesign.md
  /Decisions/
    api-architecture.md
    tech-stack-choices.md
  /Metrics/
    team-velocity.md
    cycle-completion-rates.md
    

Creating Your CLAUDE.md Context File

CLAUDE.md tells Claude how to use your Linear data.

Key sections:

• Development process overview — How your team works
• Linear structure guide — Where different types of information live
• Current focus — What the team is working on right now
• Priority framework — How you decide what to build next
• Common queries — Examples of questions Claude can answer

Example snippet:

## Development Process

We work in 2-week sprints. Sprint planning on Mondays. Retrospectives on Fridays.

Current sprint details: `/Linear/Active-Work/current-sprint.md` (updated weekly)

### Priority Framework

Feature prioritization based on:
1. Revenue impact (blocking deals or expansion)
2. Customer request volume (votes in Linear)
3. Strategic importance (aligns with company goals)
4. Technical dependencies (what unlocks other work)

See `/Linear/Active-Work/backlog-priorities.md` for current rankings.

### Workflow

**Issue states:** Defined in `/Linear/Structure/workflow-states.md`

**Standard flow:** Backlog → Todo → In Progress → In Review → Done

**Review process:** All code reviewed by at least one other engineer before merge.

### Common Queries

- "What's in the current sprint?" → Read `/Active-Work/current-sprint.md`
- "What are we building next?" → Read `/Active-Work/backlog-priorities.md`
- "Why did we choose this architecture?" → Search `/Decisions/`
- "What's blocking progress?" → Read `/Active-Work/blocked-issues.md`
    

Workflows That Work

Planning Sprint Work

Before: You manually review Linear, estimate capacity, pick issues, explain context to the team.

After: You tell Claude "help me plan next sprint." Claude reads team velocity, checks backlog priorities, suggests issues that fit capacity, explains why they're prioritized.

Writing Project Updates

Before: You scan Linear, manually note progress, copy issue titles, write an update.

After: You ask Claude "write this week's engineering update." Claude reads current sprint status, identifies completed work, in-progress items, blockers, drafts an update with actual issue IDs and progress metrics.

Making Technical Decisions

Before: You discuss architecture in Slack or meetings, context gets lost.

After: You ask Claude "what did we decide about API architecture?" Claude reads your decision docs, explains the choice, summarizes the tradeoffs.

Onboarding New Developers

Before: You explain the codebase, project structure, current priorities, workflow. Takes hours.

After: New dev asks Claude. Claude reads your Linear structure, explains teams, projects, workflow states, current sprint goals, backlog priorities. New dev gets up to speed without pulling you away from work.

Understanding Feature Context

Before: You see an issue, don't remember why it's prioritized, dig through comments and Slack.

After: You ask Claude "why are we building multi-user accounts?" Claude reads backlog priorities, tells you it's blocking $400K in enterprise deals and 12 customers need it.

Maintenance and Updates

Your vault stays useful with regular updates.

Weekly: Export current sprint status. Update progress, completed items, blockers. Takes 10 minutes at sprint standup.

Bi-weekly: Refresh backlog priorities after sprint planning. Update top 20 issues if priorities shifted.

Monthly: Update team velocity metrics. Document any new technical decisions. Review and archive completed epics.

Quarterly: Audit Linear structure docs. Did workflow change? New teams or projects? Update accordingly.

Most of your Linear structure is stable. You're updating active work status, not rebuilding the whole system.

What This Isn't

This isn't a Linear API integration. Claude doesn't read Linear directly, update issues, or sync in real-time.

This isn't a replacement for Linear. You still work in Linear. The vault is Claude's project memory, not your issue tracker.

This isn't automatic. You export manually when context changes. But sprint structure is stable week-to-week.

It's a context layer. Linear tracks your work. Claude gets the memory to understand and reference it.