Linear Method

Linear explicitly rejects user stories as an anti-pattern. Write short, concrete tasks in plain language.

Good title: Verify login credentials in HandleSync Bad title: As a developer, I want login verification so that multi-user sync is secure

Priority Levels

Linear has exactly 4 priorities + none. Don't over-specify — if you need more granularity, use labels or workflow statuses instead.

Tie-breaking within priority: Use drag-and-drop ordering in Linear views — this is a persistent global sort visible to the whole workspace. There is no numeric sub-priority field.

Enablers vs Blockers

Before assigning priority, classify the work:

• Blocker — gap or friction that prevents users from using the product. Fix these first.
• Enabler — adds new capability, makes the product more valuable. Build these strategically.

Ask: Does this help move the needle this week or month? What compounding effects come from building it now? What complexity does it add?

Hierarchy

Initiatives (company goals)
  └── Projects (time-bound deliverables, 1-3 weeks, 1-3 people)
        └── Milestones (meaningful stages within a project)
              └── Issues (concrete tasks with clear outcomes)
                    └── Sub-issues (breakdowns, can cross teams)

Initiatives — ambitious, focused goals. Curated list of projects. Projects — scope to 1-3 weeks with 1-3 people. If it can't fit, break into phases. Milestones — stages of completion within a project. Filter and track progress per milestone. Issues — single tasks. Required: title + status. Everything else is optional. Sub-issues — can be assigned to any team/member, not just the parent's.

Cycles

Cycles are automated, repeating time-boxes (1-8 weeks). They are NOT releases.

• Unfinished issues auto-roll to next cycle
• Use cooldown periods between cycles for tech debt
• Capacity is calculated from velocity of previous 3 cycles
• Auto-add active issues to current cycle (configurable)
• Cycles are per-team; sub-teams inherit parent schedule

When to use cycles vs projects: Cycles are recurring cadence (like sprints). Projects are goal-oriented (ship feature X). An issue can belong to both.

Workflows (Issue Statuses)

Default: Backlog → Todo → In Progress → Done → Canceled

Linear's own workflow: Icebox | Backlog → Todo → In Progress → In Review → Ready to Merge → Done | Canceled | Could not reproduce | Won't Fix | Duplicate

Categories (fixed order): Triage → Backlog → Unstarted → Started → Completed → Canceled

• Let integrations update status automatically (GitHub PR → In Progress → In Review → Done)
• Auto-close stale issues, auto-archive completed ones
• Triage is an optional inbox for new issues before they enter the workflow

Labels

• Use workspace-level labels for cross-team concepts (Bug, Feature, Improvement)
• Use team-level labels for team-specific concepts
• Labels within a group are mutually exclusive (only one from each group)
• Use prefix convention for filtering: type:bug, comp:sync, area:auth
• Add descriptions to labels so Triage Intelligence can suggest them

Relations and Dependencies

• Blocks / Blocked by — hard dependency, issue can't proceed
• Related — soft connection for context
• Duplicate — marks issue as duplicate, moves to Canceled
• Sub-issue — hierarchical breakdown
• Parent — the inverse of sub-issue

Use blocks/blockedBy to express ordering when priority alone isn't sufficient.

Backlog Hygiene

Linear's method: curate ruthlessly. Important items resurface; forgotten ones rarely matter.

• Triage new issues before they enter the workflow
• Archive aggressively — auto-archive completed/canceled issues
• Don't let the backlog become a graveyard
• If an issue has been in backlog for months untouched, it's probably not important

Project Scoping

Target: 1-3 weeks, 1-3 people. If it doesn't fit:

1. Break into sequential phases (each is its own project)
2. Ship MVP first, iterate based on feedback
3. Use milestones within a project for longer efforts

Benefits: forced prioritization, continuous shipping, rapid feedback loops, reduced risk.

Quick Reference for Agents

When creating issues via MCP tools:

Required: title, team
Recommended: priority, project, description (brief)
Optional: labels, assignee, estimate, dueDate, milestone, cycle
Relations: blocks, blockedBy, relatedTo, parentId, duplicateOf

Priority decision tree:

1. Is production broken or users blocked? → Urgent (1)
2. Is it on the critical path or blocking other work? → High (2)
3. Is it normal planned work? → Medium (3)
4. Is it a nice-to-have or speculative? → Low (4)
5. Not yet assessed? → None (0)

Deduplication: Before creating, search existing issues. Use duplicateOf if found.

Common Mistakes