What's missing
`linear update` operates on a single ticket. Triage moves like "pull these 24 tickets out of the current cycle" become 24 sequential CLI calls (24 process spawns, 24 GraphQL round-trips).
Proposed surface
Two options, either or both:
```
1. Multiple positional IDs:
linear update RUSH-1009 RUSH-1013 RUSH-1014 RUSH-1015 --cycle none
2. Read IDs from stdin (xargs-friendly):
linear tasks --json | jq -r '.issues[].identifier' | linear update --cycle none --stdin
```
The single-ticket invocation continues to work unchanged.
Why it matters
Cleanup sessions where an agent or human is moving 20–50 tickets out of a cycle, applying a label, or marking a batch done with the same proof URL. Today this is a shell loop; native bulk is faster, atomic-ish, and lets the CLI batch GraphQL mutations.
Implementation notes
- `linear` line 981 — `# Cycle move: --cycle active | next | none` — is the dispatcher; bulk wraps this in a loop or batches via Linear's `issueBatchUpdate` if available.
- Surface a progress indicator (`[12/24] RUSH-1042 -> backlog`) so subagents have something to parse and humans can ^C cleanly.
- Roll up errors at the end rather than aborting mid-batch.
What's missing
`linear update` operates on a single ticket. Triage moves like "pull these 24 tickets out of the current cycle" become 24 sequential CLI calls (24 process spawns, 24 GraphQL round-trips).
Proposed surface
Two options, either or both:
```
1. Multiple positional IDs:
linear update RUSH-1009 RUSH-1013 RUSH-1014 RUSH-1015 --cycle none
2. Read IDs from stdin (xargs-friendly):
linear tasks --json | jq -r '.issues[].identifier' | linear update --cycle none --stdin
```
The single-ticket invocation continues to work unchanged.
Why it matters
Cleanup sessions where an agent or human is moving 20–50 tickets out of a cycle, applying a label, or marking a batch done with the same proof URL. Today this is a shell loop; native bulk is faster, atomic-ish, and lets the CLI batch GraphQL mutations.
Implementation notes