linear-usage

name	linear-usage
description	This skill should be used when user asks about "Linear issues", "issue tracking best practices", "sprint planning", "Linear project management", or "creating Linear issues".

Linear & Issue Tracking Best Practices

Issue Writing Guidelines

Clear Titles

Write titles that describe the problem or outcome:

• Good: "Users can't reset password on mobile Safari"
• Bad: "Password bug"
• Good: "Add export to CSV for user reports"
• Bad: "Export feature"

Effective Descriptions

Include:

1. Context: Why this matters
2. Current behavior: What happens now (for bugs)
3. Expected behavior: What should happen
4. Steps to reproduce: For bugs
5. Acceptance criteria: Definition of done

Templates

Bug report:

## Description
Brief description of the issue.

## Steps to Reproduce
1. Step one
2. Step two
3. Issue occurs

## Expected Behavior
What should happen.

## Actual Behavior
What happens instead.

## Environment
- Browser/OS
- User type

Feature request:

## Problem Statement
What problem does this solve?

## Proposed Solution
High-level approach.

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

Label Taxonomy

Recommended Labels

Type labels:

• bug - Something isn't working
• feature - New functionality
• improvement - Enhancement to existing feature
• chore - Maintenance, refactoring

Area labels:

• frontend, backend, api, mobile
• Or by feature area: auth, payments, onboarding

Status labels (if not using workflow states):

• needs-triage, blocked, needs-design

Label Best Practices

• Keep label count manageable (15-25 total)
• Use consistent naming convention
• Color-code by category
• Review and prune quarterly

Priority and Estimation

Priority Levels

• Urgent (P0): Production down, security issue
• High (P1): Major functionality broken, key deadline
• Medium (P2): Important but not urgent
• Low (P3): Nice to have, minor improvements

Estimation Tips

• Use relative sizing (points) not hours
• Estimate complexity, not time
• Include testing and review time
• Re-estimate if scope changes significantly

Cycle/Sprint Planning

Cycle Best Practices

• Duration: 1-2 weeks typically
• Capacity: Plan for 70-80% to allow for interrupts
• Carryover: Review why items didn't complete
• Retrospective: Brief review at cycle end

Planning Process

1. Review backlog priorities
2. Pull issues into cycle
3. Break down large items (>5 points)
4. Assign owners
5. Identify dependencies and blockers

Project Organization

Projects vs Initiatives

Projects: Focused, time-bound work (1-3 months)

• Single team typically
• Clear deliverable
• Example: "Mobile app v2 launch"

Initiatives: Strategic themes

• May span multiple projects
• Longer-term goals
• Example: "Platform reliability"

Roadmap Tips

• Keep roadmap items high-level
• Update status regularly
• Link to detailed issues/projects
• Share with stakeholders

Triage Workflows

Triage Process

1. Review new issues daily
2. Add missing information (labels, priority)
3. Assign to appropriate team/person
4. Link related issues
5. Move to backlog or close if invalid

Closing Issues

Close with clear reason:

• Completed: Work is done
• Duplicate: Link to original
• Won't fix: Explain why
• Invalid: Missing info, not reproducible

GitHub Integration

Linking PRs to Issues

• Reference Linear issue ID in PR title or description
• Linear auto-links and updates status
• Use branch names with issue ID for automatic linking

Workflow Automation

• PR opened → Issue moves to "In Progress"
• PR merged → Issue moves to "Done"
• Configure in Linear settings