linear-ticket-lifecycle

Linear Ticket Lifecycle

Every deliberate work session must have a Linear ticket. This skill ensures tickets exist from the moment work begins — whether that's brainstorming, writing a spec, planning, or implementing. Uses In Progress and In Review as the two active states. (This example targets a team whose issue key is ENG; see the plugin README to adapt the key and state names to your workspace.)

Ticket Discovery

Before starting any deliberate work (brainstorming, spec, plan, or code), resolve the associated ticket. Follow this cascade — do not skip steps:

1. Explicit mention — user said a ticket ID (e.g. "ENG-123") → get_issue
2. Branch name — run git branch --show-current, match case-insensitively for eng-(\d+) → get_issue with ENG-{number}
3. Search Linear — list_issues filtered to your team, active states (e.g. Backlog, Todo, In Progress, In Review, Blocked). Present up to 5 matches, let the user pick. Do not auto-link.
4. Create new — if nothing fits, generate title + description from task context, use list_projects to pick the best-fit project, confirm everything with the user, create on your team via save_issue

You must always end up with a ticket. Do not ask the user whether to create one — if steps 1-3 found nothing, step 4 is mandatory. Confirm the details, but ticket creation itself is not optional.

Remember the ticket ID for the rest of the session.

State Transitions

Two states, three transitions. All silent — no user confirmation needed.

Starting work → In Progress

When you begin any deliberate work (brainstorming, spec, plan, or code), move the ticket to In Progress.

If the ticket is in any other active state (In Review, Blocked, etc.), move it to In Progress. If it's already In Progress, skip the API call.

Finishing implementation → In Review

When implementation is complete (code written, tests passing), move the ticket to In Review.

This signals "implementation run complete, ball is in the reviewer's court."