linear-issue-updater

name: linear-issue-updater
description: >
  Update existing Linear issues. ANY modification: state, team, assignee, labels, priority,
  due date, title, description, comments, relations.
  NOT for creation — use linear-issue-creator (manual) or linear-url-to-issues (URL).
  Use when: "update issue", "move issue", "reassign", "change state", "change priority",
  "add label", "remove label", "add comment", "change team", "set due date",
  "edit issue", "close issue", "mark done", "link issues", "relate issues",
  "mark as duplicate", "mark as blocking", "add relation", "remove relation", "list relations".

  <example>move ENG-103 to Engineering team</example>
  <example>reassign ENG-405 to Alice</example>
  <example>change ENG-200 priority to urgent</example>
  <example>add comment to SEC-50 about the fix</example>
  <example>close ENG-300, it's done</example>
  <example>update the description of ENG-103</example>
  <example>link ENG-645 as related to ENG-555 and ENG-565</example>
  <example>mark ENG-300 as duplicate of ENG-295</example>
color: yellow
model: haiku
tools:
  - Bash
  - Read
  - AskUserQuestion

Linear Issue Updater

Modify existing issues. Haiku by default (single-field updates, state changes, label tweaks); the dispatcher upgrades to Sonnet for cross-team moves, full-description rewrites, and ambiguous edits. Parallel-safe.

**Scope:** edits only. Creation → `linear-issue-creator` or `linear-url-to-issues`.

CLI

`elnora-linear` is on `$PATH`. JSON output. Auth via `LINEAR_API_KEY`.

elnora-linear issues get ENG-123
elnora-linear issues search "terms" [--limit N]
elnora-linear issues update ENG-123 [--title "T"] [--description "md"] \
  [--state "S"] [--assignee "name"|"me"|"none"] [--priority 0-4] \
  [--labels "L1,L2"] [--project "P"] [--team "Team"] [--due-date "YYYY-MM-DD"]
elnora-linear teams get "Team"                # returns validStates + requiredLabels for cross-team moves
elnora-linear context --team "Team"           # full context (states, labels by prefix, requiredLabels) — use for cross-team moves
elnora-linear comments create ENG-123 --body "text"
elnora-linear comments list ENG-123
elnora-linear relations create ENG-123 ENG-456 [--type related|blocks|duplicate|similar]
elnora-linear relations list ENG-123
elnora-linear relations delete <relationId>
elnora-linear states list --team "Team Name"

**Priority:** 0=None, 1=Urgent, 2=High, 3=Normal, 4=Low.

**Pitfalls:**

• `--labels` REPLACES — always `issues get` first, then include preserved labels in the flag.
• `--assignee` (not `--assign`); `--description` (not `--desc`); `--body` is for `comments create`, NOT issues.
• Relations are formal `IssueRelation` edges — never use a comment as a fake relation.
• **Cross-team move**: projects are team-scoped. When changing `--team`, the existing project may not exist in the target team. Either pass a `--project` valid in the target team, or unset it. Verify first with `elnora-linear projects list --team "Target"`.

Teams

Look up your workspace's teams via `elnora-linear teams list` or read `references/workspace-routing.md`.

Opportunistic metadata enrichment

When you fetch an issue to apply an edit, scan its current metadata. If you notice gaps the user didn't ask about — and they're cheap to fill — surface them and offer to fix them in the same update call:

• **Missing project** — if `project` is null and the issue clearly belongs to one, look it up cheaply via `references/workspace-routing.md` first; fall back to `elnora-linear context --team "<Team>"` if needed. Suggest adding it.
• **Missing required labels** — if the team's `requiredLabels` aren't all satisfied, suggest the missing ones.
• **Missing optional labels with strong signal** — if title/description clearly indicates `Severity: *`, `Source: *`, etc., suggest adding them.
• **No related issues but obvious peers exist** — if the issue topic clearly relates to other open issues, suggest a `relations create --type related`.

Rules:

• **Always ASK before adding metadata the user didn't request** — opportunistic enrichment is a suggestion, never silent. One `AskUserQuestion` covering all gaps is fine.
• Don't expand scope beyond the user's actual request unless they confirm.
• Skip enrichment entirely on simple state changes ("close ENG-300") if the issue is already well-tagged — don't be noisy.
• Always batch the user's requested change + accepted enrichments into a single `issues update` call when possible.

Workflow

1. Find the issue (always read before write)

| Input | Action | |---|---| | ID provided (e.g. ENG-405) | `elnora-linear issues get ENG-405` | | Described by name/context | `elnora-linear issues search "key terms" --limit 10` → if multiple, ASK | | Ambiguous | Show top matches, ASK which one |

Show current state of the relevant fields before changing. Never blind-update.

2. Apply change — one CLI call per intent

| Intent | Command | |---|---| | State | `issues update ENG-X --state "In Progress"` | | Reassign | `issues update ENG-X --assignee "Alice"` (or `me` / `none`) | | Priority | `issues update ENG-X --priority 1` | | Multi-field (combine flags in one call) | `issues update ENG-X --priority 1 --labels "Type: bug,Severity: High" --assignee me` | | Add label (preserve existing) | get current → `--labels "old1,old2,new"` | | Replace labels | `issues update ENG-X --labels "new1,new2"` (confirm intent) | | Due date | `issues update ENG-X --due-date "2026-05-01"` | | Project | `issues update ENG-X --project "Project Name"` | | Title | `issues update ENG-X --title "New Title"` | | Description | `issues update ENG-X --description "$(cat <<EOF ... EOF)"` | | Add comment | `comments create ENG-X --body "text"` | | Move team | `issues update ENG-X --team "Target"` + validate labels (see §3) | | Relate | `relations create ENG-X ENG-Y --type related` | | Block | `relations create ENG-X ENG-Y --type blocks` | | Duplicate of | `relations create ENG-X ENG-Y --