@kyaukyuai/linear-cli 2.14.0 → 3.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,30 @@
2
2
 
3
3
  ## [Unreleased]
4
4
 
5
+ ## [3.0.0] - 2026-04-04
6
+
7
+ ### Added
8
+
9
+ - extended the shared `operation` and `receipt` contract family across remaining high-value write commands, including issue assignment/estimate/move/priority, project create and project-label mutation flows, webhook writes, and batch issue creation
10
+ - published an agent-native v3 migration guide and rewrote the README and skill/docs stack around AI agent runtimes instead of mixed human/operator usage
11
+
12
+ ### Changed
13
+
14
+ - changed the default runtime to agent-native execution for core startup, read, and representative write surfaces by making machine-readable JSON the default output mode and relegating human-readable output to the explicit `--text` escape hatch
15
+ - removed implicit interactive fallback behavior from startup-critical paths; prompt-driven flows now require explicit `--profile human-debug --interactive`
16
+ - made `agent-safe` the default execution profile, so pager-off behavior, longer write timeout defaults, and explicit destructive confirmation semantics are the standard runtime path
17
+ - promoted the richer `linear capabilities` schema metadata to the default discovery surface and kept the legacy trimmed shape available only through explicit `--compat v1`
18
+
19
+ ## [2.15.0] - 2026-04-03
20
+
21
+ ### Added
22
+
23
+ - added a global `--profile agent-safe` execution profile that disables pager by default, extends write timeouts, and requires explicit `--yes` for destructive confirmation flows in automation contexts
24
+
25
+ ### Changed
26
+
27
+ - added downstream consumer certification to the release gate so startup discovery, resolve, preview/apply, and timeout-recovery paths used by real agent workflows cannot drift silently
28
+
5
29
  ## [2.14.0] - 2026-04-03
6
30
 
7
31
  ### Added
package/README.md CHANGED
@@ -1,41 +1,90 @@
1
1
  # linear-cli
2
2
 
3
- `linear-cli` is an agent-first Linear CLI for Claude Code, Codex, and other automation that needs a stable command surface instead of screen scraping or ad-hoc GraphQL scripts. this fork of [`schpet/linear-cli`](https://github.com/schpet/linear-cli) keeps the git and [jj](https://www.jj-vcs.dev/) workflow ergonomics from upstream, then adds stable JSON contracts, dry-run previews, retry-safe error semantics, and pipeline-friendly command behavior for automation-heavy teams.
3
+ `linear-cli` is an agent-native Linear runtime for Claude Code, Codex, and other automation that needs a stable command surface instead of screen scraping or ad-hoc GraphQL scripts. this fork of [`schpet/linear-cli`](https://github.com/schpet/linear-cli) keeps the git and [jj](https://www.jj-vcs.dev/) workflow ergonomics from upstream, then layers on stable JSON contracts, startup discovery, dry-run previews, operation receipts, and workflow-safe error semantics for agent-controlled execution.
4
4
 
5
- if you want an agent to read Linear state, preview a write, apply it, and return structured output without leaving the shell, this repo is designed for that path first.
5
+ if you want an agent to read Linear state, resolve refs, preview a write, apply it, and return structured output without leaving the shell, this repo is designed for that path first. `main` now reflects the `v3.0.0` runtime direction: core surfaces default to machine-readable output, startup flows are non-interactive, and human-oriented terminal output is an explicit escape hatch instead of the primary product surface.
6
6
 
7
7
  ```bash
8
- linear capabilities --json
9
- linear capabilities --json --compat v2
10
- linear resolve issue ENG-123 --json
11
- linear issue list --json
12
- linear issue view ENG-123 --json
8
+ linear capabilities
9
+ linear capabilities --compat v1
10
+ linear resolve issue ENG-123
11
+ linear issue update ENG-123 --state done --dry-run --json
12
+ linear issue list
13
+ linear issue view ENG-123
13
14
  linear issue create -t "Backfill webhook contract docs" --team ENG --dry-run --json
14
- linear issue update ENG-123 --state done --comment "Shipped in v2.10.0" --json
15
- linear project view "Automation Contract v3" --json
16
- linear notification list --json
15
+ linear issue update ENG-123 --state done --comment "Shipped in v2.10.0"
16
+ linear project view "Automation Contract v3"
17
+ linear notification list
17
18
  ```
18
19
 
19
- interactive commands still exist for humans, but the primary design goal is that an agent can discover commands incrementally, pass all important input as flags or stdin, and get machine-readable success or failure back.
20
+ the core agent surfaces now default to machine-readable JSON. use `--text` when a human wants terminal-oriented output for ad-hoc inspection or debugging.
21
+
22
+ ## what v3.0.0 means
23
+
24
+ `v3.0.0` is the release where `linear-cli` stops behaving like a mixed human/agent CLI and starts behaving like an agent-native control plane by default.
25
+
26
+ - startup discovery defaults to the richer `linear capabilities` schema
27
+ - startup-critical reads and representative writes default to machine-readable JSON
28
+ - prompt fallbacks are no longer implicit; use `--profile human-debug --interactive` when a maintainer explicitly wants them
29
+ - `agent-safe` is the default execution profile
30
+ - preview/apply/result flows share `operation`, `receipt`, and structured `error.details`
31
+
32
+ if you are integrating `linear-cli` into an agent runtime, assume the defaults above and treat `--text` plus `--profile human-debug` as secondary debugging tools.
33
+
34
+ ## agent-native runtime
35
+
36
+ Treat `linear-cli` as a shell-native control plane for agents:
37
+
38
+ - startup discovery comes from `linear capabilities`
39
+ - startup-critical reads and core write surfaces default to machine-readable JSON
40
+ - refs can be normalized with `linear resolve ...`
41
+ - write previews use `--dry-run --json`
42
+ - write results expose `operation`, `receipt`, and structured `error.details`
43
+ - human/debug behavior is explicit with `--text` and `--profile human-debug --interactive`
44
+
45
+ The practical default loop is:
46
+
47
+ 1. `linear capabilities`
48
+ 2. `linear resolve ...`
49
+ 3. default-JSON reads such as `linear issue view ENG-123`
50
+ 4. `--dry-run --json` previews for writes
51
+ 5. apply the mutation and inspect `operation`, `receipt`, and `error.details`
20
52
 
21
53
  ## for agents
22
54
 
23
55
  If an agent only reads one page, it should be this README plus the two contract docs below.
24
56
 
25
- - start with `linear capabilities --json` for the stable startup-safe shape; use `linear capabilities --json --compat v2` when you also need required/optional input refs, constrained values, defaults, context resolution hints, input constraints, canonical argv examples, stdin/file targets, and structured output semantics
26
- - resolve ambiguous issue/team/state/user/label refs with `linear resolve ... --json` before previewing or applying writes
27
- - prefer stable read surfaces such as `issue`, `project`, `cycle`, `milestone`, `document`, `webhook`, `notification`, `team`, `user`, `workflow-state`, `label`, `initiative`, and update feeds with `--json`
57
+ - start with `linear capabilities` for the default schema-like discovery shape; use `linear capabilities --compat v1` only when an older consumer still expects the legacy startup shape
58
+ - use the default runtime for predictable non-interactive agent execution; `--profile human-debug` is the explicit escape hatch for pager and prompt-driven debugging
59
+ - resolve ambiguous issue/team/state/user/label refs with `linear resolve ...` before previewing or applying writes
60
+ - prefer stable read surfaces such as `issue`, `project`, `cycle`, `milestone`, `document`, `webhook`, `notification`, `team`, `user`, `workflow-state`, `label`, `initiative`, and update feeds; those agent-first entrypoints now default to machine-readable JSON
28
61
  - preview writes with `--dry-run --json` before mutating Linear
29
- - apply writes with `--json`, then inspect exit codes and `error.details` instead of parsing terminal text
62
+ - apply writes on default-JSON surfaces without `--text`, then inspect exit codes and `error.details` instead of parsing terminal text
63
+ - use `--profile human-debug --interactive` for human/debug prompt flows; missing required inputs now fail fast by default
30
64
  - use stdin or file flags for Markdown-heavy descriptions and comments instead of long inline shell strings
31
65
 
32
66
  Recommended docs:
33
67
 
34
68
  - [Agent workflow guide](docs/agent-first.md)
35
69
  - [Automation contracts](docs/json-contracts.md)
70
+ - [Agent-only v3 release guide](docs/agent-only-v3.md)
36
71
  - [stdin and pipeline policy](docs/stdin-policy.md)
37
72
 
38
- ## screencast demos
73
+ ## migration from 2.x
74
+
75
+ If a downstream consumer still assumes the older mixed human/agent behavior, migrate in this order:
76
+
77
+ 1. stop parsing styled terminal output
78
+ 2. use `linear capabilities` for startup discovery and pin `--compat v1` only where a legacy consumer still needs it
79
+ 3. treat `operation`, `receipt`, and `error.details` as the canonical execution surface
80
+ 4. add `--text` anywhere a maintainer still wants terminal-oriented output
81
+ 5. add `--profile human-debug --interactive` anywhere a maintainer still wants prompts or pager-oriented debugging
82
+
83
+ The detailed release and migration guide lives in [docs/agent-only-v3.md](docs/agent-only-v3.md).
84
+
85
+ ## human-debug demos
86
+
87
+ These demos are intentionally secondary. they show the explicit human/debug escape hatch, not the primary runtime path for agents.
39
88
 
40
89
  <details>
41
90
  <summary><code>linear issue create</code></summary>
@@ -127,7 +176,7 @@ deno task install
127
176
  compared to upstream, this fork adds and maintains capabilities aimed at automation-heavy workflows:
128
177
 
129
178
  - stable JSON contracts for the automation tier, with machine-readable failures for parser, validation, and runtime errors
130
- - a self-describing `linear capabilities --json` surface with a backward-compatible default and an explicit `--compat v2` mode for richer schema and output metadata
179
+ - a self-describing `linear capabilities` surface with richer schema and output metadata by default and an explicit `--compat v1` fallback for legacy consumers
131
180
  - `--dry-run` previews for high-value write commands, including `issue start`, issue writes, and non-issue writes
132
181
  - additive operation receipts on high-value JSON write success paths
133
182
  - a shared top-level `operation` contract on representative preview/apply JSON write paths
@@ -153,14 +202,23 @@ Use the docs in this order if you are building an agent integration:
153
202
 
154
203
  1. [docs/agent-first.md](docs/agent-first.md) for the recommended discover/read/preview/apply/recover loop
155
204
  2. [docs/json-contracts.md](docs/json-contracts.md) for stable JSON payloads, exit codes, timeout semantics, and dry-run envelopes
156
- 3. [docs/stdin-policy.md](docs/stdin-policy.md) for pipeline and file-input conventions
157
- 4. [`linear capabilities --json`](#automation-contract) for machine-readable command metadata at runtime
205
+ 3. [docs/agent-only-v3.md](docs/agent-only-v3.md) for the `v3.0.0` release contract and downstream migration checklist
206
+ 4. [docs/stdin-policy.md](docs/stdin-policy.md) for pipeline and file-input conventions
207
+ 5. [`linear capabilities`](#automation-contract) for machine-readable command metadata at runtime
158
208
 
159
209
  ## automation contract
160
210
 
161
- for bot and org-wide automation use cases, `linear-cli` defines a stable JSON contract for a focused automation tier.
211
+ for bot and org-wide automation use cases, `linear-cli` defines a stable machine-readable contract for a focused automation tier. that contract is the primary runtime surface. `--text` and prompt flows are secondary human/debug escape hatches.
212
+
213
+ to discover the curated agent-facing command surface programmatically, use `linear capabilities`. the default shape now returns the richer v2 schema metadata for agent-native startup. when an older consumer still expects the trimmed legacy shape, pin it explicitly with `linear capabilities --compat v1`.
214
+
215
+ `agent-safe` is now the default execution profile for agent-controlled runs. it disables pager-by-default behavior, extends the built-in write timeout to `45000ms` unless `--timeout-ms` or `LINEAR_WRITE_TIMEOUT_MS` is set, and keeps destructive confirmation bypass explicit with `--yes`. use `--profile human-debug` when a maintainer explicitly wants prompt-driven or pager-oriented debugging behavior.
216
+
217
+ non-goals:
162
218
 
163
- to discover the curated agent-facing command surface programmatically, use `linear capabilities --json`. the default shape preserves the v1-compatible startup contract for existing bots. when you need richer metadata such as required vs optional primary inputs, constrained values, defaults, context resolution hints, input constraints, canonical argv examples, stdin/file targets, structured output semantics, and timeout/no-op traits, opt into `linear capabilities --json --compat v2`.
219
+ - it does not force `--json` on commands outside the agent-native default-JSON surface
220
+ - it does not auto-confirm destructive actions
221
+ - it does not replace explicit human/debug prompt flows; callers should pass flags, stdin, file inputs, or opt into `--profile human-debug --interactive`
164
222
 
165
223
  - v1 in scope: `issue list/view/create/update --json`, `issue relation add/delete/list --json`, `issue comment add --json`, `team members --json`, `issue parent/children/create-batch --json`
166
224
  - v2 additions: `project list/view --json`, `cycle list/view/current/next --json`, `milestone list/view --json`
@@ -170,7 +228,7 @@ to discover the curated agent-facing command surface programmatically, use `line
170
228
  - v6 additions: `resolve issue/team/workflow-state/user/label --json`
171
229
  - out of scope: non-JSON terminal output, `linear api`, and other `--json` commands that are not listed above
172
230
 
173
- the contract fixes top-level success payload shapes and requires machine-readable failure payloads for the automation tier. see [docs/json-contracts.md](docs/json-contracts.md) for the full contract, compatibility rules, and example payloads. that guarantee also covers parser and argument validation failures when `--json` is present.
231
+ the contract fixes top-level success payload shapes and requires machine-readable failure payloads for the automation tier. see [docs/json-contracts.md](docs/json-contracts.md) for the full contract, compatibility rules, and example payloads. that guarantee also covers parser and argument validation failures when the command is in machine-readable mode, whether that is the default or was requested explicitly with `--json`.
174
232
 
175
233
  for automation consumers, auth and authorization failures now use exit code `4`, free-plan or workspace-plan limit failures use exit code `5`, and client-side write confirmation timeouts use exit code `6`. other contract failures remain non-zero and currently use `1`. rate-limited responses remain on exit code `1`, but now include retry guidance and, when available, `error.details.rateLimit` metadata.
176
234
 
@@ -178,7 +236,7 @@ high-value write commands honor `LINEAR_WRITE_TIMEOUT_MS` and accept `--timeout-
178
236
 
179
237
  the same document also defines the shared preview contract for future `--dry-run` write commands. those commands are not all implemented yet, but the contract now fixes the expected `stdout`, `exit code`, and `--json --dry-run` envelope shape ahead of rollout.
180
238
 
181
- representative preview/apply JSON write paths may add a top-level `operation` field so agents can diff preview intent against apply results with one parser path. successful high-value JSON writes may also add a top-level `receipt` field. this gives agents a shared place to inspect `operationId`, `resolvedRefs`, `appliedChanges`, `noOp`, and `nextSafeAction` without inferring those traits from command-specific payload fields.
239
+ representative preview/apply JSON write paths may add a top-level `operation` field so agents can diff preview intent against apply results with one parser path. successful high-value JSON writes may also add a top-level `receipt` field. this gives agents a shared place to inspect `operationId`, `resolvedRefs`, `appliedChanges`, `noOp`, and `nextSafeAction` without inferring those traits from command-specific payload fields. current coverage includes issue create/update/comment/relation, issue batch creation, issue assignment/estimate/move/priority, project create and label add/remove, webhook create/update/delete, and notification read/archive.
182
240
 
183
241
  destructive commands use `--yes` as the canonical confirmation-bypass flag. legacy `--force` and `--confirm` flags are still accepted where older workflows already depended on them.
184
242
 
@@ -209,17 +267,17 @@ this fork is intentionally diverging from upstream in a few ways:
209
267
  2. authenticate with the CLI:
210
268
 
211
269
  ```sh
212
- linear auth login
270
+ linear auth login --profile human-debug --interactive
213
271
  ```
214
272
 
215
273
  3. configure your project:
216
274
 
217
275
  ```sh
218
276
  cd my-project-repo
219
- linear config
277
+ linear config --profile human-debug --interactive
220
278
  ```
221
279
 
222
- see [docs/authentication.md](docs/authentication.md) for multi-workspace support and other authentication options.
280
+ For unattended agent runtimes, prefer injected credentials and explicit config over prompt flows. see [docs/authentication.md](docs/authentication.md) for multi-workspace support and other authentication options.
223
281
 
224
282
  the CLI works with both git and jj version control systems:
225
283
 
@@ -238,11 +296,11 @@ the current issue is determined by:
238
296
  note that [Linear's GitHub integration](https://linear.app/docs/github#branch-format) will suggest git branch names.
239
297
 
240
298
  ```bash
241
- linear issue view # view current issue details in terminal
299
+ linear issue view # emit machine-readable current issue details
242
300
  linear issue view ABC-123
243
301
  linear issue view 123
244
- linear issue view ABC-123 --json # emit stable machine-readable issue details
245
- linear issue view ABC-123 --json --no-comments # skip raw comments but keep commentsSummary
302
+ linear issue view ABC-123 --text # human/debug output
303
+ linear issue view ABC-123 --no-comments # skip raw comments but keep commentsSummary
246
304
  linear issue view -w # open issue in web browser
247
305
  linear issue view -a # open issue in Linear.app
248
306
  linear issue id # prints the issue id from current branch (e.g., "ENG-123")
@@ -259,9 +317,10 @@ linear issue list --all-states --query auth --priority high --updated-before 202
259
317
  linear issue list --parent ENG-100 --json # filter sub-issues of a parent issue
260
318
  linear issue list -w # open issue list in web browser
261
319
  linear issue list -a # open issue list in Linear.app
262
- linear issue start # create/switch to issue branch and mark as started
320
+ linear issue start ENG-123 # create/switch to issue branch and mark as started
321
+ linear issue start --interactive # choose an issue interactively in a terminal
263
322
  linear issue start ENG-123 --dry-run # preview the branch and target state
264
- linear issue create # create a new issue (interactive prompts)
323
+ linear issue create --interactive # create a new issue with interactive prompts
265
324
  linear issue create -t "title" -d "description" # create with flags
266
325
  cat description.md | linear issue create -t "title" --team ENG # read description from stdin
267
326
  linear issue create -t "title" --team ENG --json # emit machine-readable created issue data
@@ -269,7 +328,7 @@ linear issue create -t "title" --team ENG --dry-run --json # preview the create
269
328
  linear issue create-batch --file ./issue-batch.json --json # create a parent issue and child issues from JSON
270
329
  linear issue create-batch --file ./issue-batch.json --dry-run --json # preview a batch without creating issues
271
330
  linear issue create --project "My Project" --milestone "Phase 1" # create with milestone
272
- linear issue update # update an issue (interactive prompts)
331
+ linear issue update ENG-123 --interactive # update an issue with interactive prompts
273
332
  cat description.md | linear issue update ENG-123 --state started # read description from stdin
274
333
  linear issue update ENG-123 --due-date 2026-03-31 # set an issue due date
275
334
  linear issue update ENG-123 --clear-due-date # clear an issue due date
@@ -496,7 +555,7 @@ linear user view <userId> --json # emit contract-stable user details
496
555
  ```bash
497
556
  linear --help # show all commands
498
557
  linear --version # show version
499
- linear config # setup the project
558
+ linear config --profile human-debug --interactive # maintainer setup flow
500
559
  linear completions # generate shell completions
501
560
  ```
502
561
 
@@ -23,7 +23,7 @@
23
23
  "hasInstallScript": true,
24
24
  "license": "MIT",
25
25
  "name": "@kyaukyuai/linear-cli",
26
- "version": "2.14.0"
26
+ "version": "3.0.0"
27
27
  },
28
28
  "node_modules/@isaacs/cliui": {
29
29
  "engines": {
@@ -542,5 +542,5 @@
542
542
  }
543
543
  },
544
544
  "requires": true,
545
- "version": "2.14.0"
545
+ "version": "3.0.0"
546
546
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "artifactDownloadUrls": [
3
- "https://github.com/kyaukyuai/linear-cli/releases/download/v2.14.0"
3
+ "https://github.com/kyaukyuai/linear-cli/releases/download/v3.0.0"
4
4
  ],
5
5
  "bin": {
6
6
  "linear": "run-linear.js"
@@ -85,7 +85,7 @@
85
85
  "zipExt": ".tar.xz"
86
86
  }
87
87
  },
88
- "version": "2.14.0",
88
+ "version": "3.0.0",
89
89
  "volta": {
90
90
  "node": "18.14.1",
91
91
  "npm": "9.5.0"