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".
license: Apache-2.0
---

# 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