Configures a Linear team end to end - team structure, minimal workflow states, cycles, a small label taxonomy, a daily triage rotation, and priority SLAs with breach views. Use when someone asks "set up Linear for my team", "how should we structure teams and labels in Linear", "our Linear backlog is a mess", or "how do we handle inbound bugs in Linear". Do NOT use for writing the tickets themselves - acceptance criteria, story points, Definition of Ready - use jira-ticket-writer instead (its ticket anatomy applies to Linear issues too). For deciding sprint scope and capacity, use sprint-planning.
Click to play with sound.
---
name: Linear Workflow
description: Configures a Linear team end to end - team structure, minimal workflow states, cycles, a small label taxonomy, a daily triage rotation, and priority SLAs with breach views. Use when someone asks "set up Linear for my team", "how should we structure teams and labels in Linear", "our Linear backlog is a mess", or "how do we handle inbound bugs in Linear". Do NOT use for writing the tickets themselves - acceptance criteria, story points, Definition of Ready - use jira-ticket-writer instead (its ticket anatomy applies to Linear issues too). For deciding sprint scope and capacity, use sprint-planning.
---
# Linear Workflow
Linear rewards lightweight, opinionated process; teams that port over a heavyweight Jira scheme get the worst of both worlds - ceremony without clarity. This skill sets up a team so issues flow predictably from idea to done, and inbound noise never silts up the backlog.
## Inputs to collect
1. Delivery units: which groups actually ship together? (Squads, not departments.)
2. Team size and count - decides whether sub-teams are justified yet.
3. Inbound volume: roughly how many bugs/requests arrive per week, and from where.
4. Current cadence, if any (1- or 2-week sprints, or none). If unknown, default to 2-week cycles and label it a default.
5. The 3-5 product areas people already use in conversation ("auth", "billing") - these become area labels.
## Operating procedure
Do the steps in order: states before cycles (cycles report on states), labels before triage (triage applies labels), triage before SLAs (SLAs are measured from triage decisions).
### Step 1: Team structure
- Create one **team per delivery unit** - a squad that ships together - not per function. A "Frontend team" and "Backend team" split guarantees every feature spans two boards.
- Keep team identifiers short (`ENG`, `WEB`) - they prefix every issue ID.… install to load the full skill