## Summary
This makes Linear document comments visible to agents/automation and
prevents `linear document update` from silently orphaning inline comment
anchors.
- include paginated document comments in `linear document view <id>
--json`
- guard Markdown content updates when active inline document comments
are present
- allow top-level document comments to pass through, since they do not
carry losable inline anchors
- add `--force` to opt back into the existing replacement behavior when
the caller intentionally accepts the risk
## Background / related work
Closes#230, which reports that document comments are currently
unreachable from the CLI and omitted from `document view --json`.
Related:
- #219 added richer `document view` behavior for downloaded inline
images; this PR keeps normal/raw rendered views lean and only expands
`--json` with comment metadata.
- #121 added the raw `linear api` GraphQL escape hatch. That is useful
for inspection, but it does not make `documentUpdate(content)` safe for
inline document comments.
## API limitation
This is intentionally a safety guard plus read fix, not a
comment-preserving writer.
From the schema used by this CLI:
- `Document.comments(...)` exposes document comments and
`Comment.quotedText`, which is enough to detect inline comments.
- `DocumentUpdateInput` only accepts Markdown `content` for document
body writes; it does not accept `contentState`/YJS/ProseMirror data or
comment anchor metadata.
- `CommentCreateInput`/`CommentUpdateInput` expose `quotedText`, but
live testing showed raw GraphQL `commentUpdate(quotedText: ...)` returns
success without recreating an inline anchor. Writing
`<linear-comment>`-style tags through `documentUpdate(content)` stores
literal text, not an anchor.
So the CLI cannot preserve or restore inline anchors through the public
GraphQL write path it uses. The best safe behavior here is to make
comments visible and convert silent data loss into an explicit stop.
`--force` remains the old replacement behavior behind an intentional
flag.
## Behavior
`linear document view <id> --json` now returns a flattened, paginated
`comments.nodes` list with fields useful to agents:
- `id`, `body`, `quotedText`, `documentContentId`
- timestamps / archive / resolution metadata
- `url`, `user`, and `parent.id`
- final `pageInfo`
`linear document update <id> --content...` now scans active document
comments page-by-page. It blocks only when it finds a comment with
`quotedText`, i.e. an inline comment anchor that can be detached by
replacing Markdown content. Top-level document comments with
`quotedText: null` do not block.
## Testing
- `deno task validate`
- `deno test --allow-all --quiet`
Full suite result locally: `338 passed`, `0 failed`, `5 ignored`.
#228 fixes milestone view silently capping its issue list, adding --all to
paginate. Two corrections:
1. Fail loudly on inconsistent --all pagination. The loop guarded on
`while (pageInfo.hasNextPage && pageInfo.endCursor)` and `if (next == null)
break`, so if Linear advertised another page but returned no cursor (or the
milestone vanished mid-pagination), --all would stop early and return a
*partial* list with no error — reintroducing the exact silent-truncation bug
this command exists to fix. Now throws CliError / NotFoundError instead, with
a regression test.
2. Fix timezone-flaky snapshots. The new "Truncated" and "--all paginates" tests
used midnight-UTC timestamps (2020-01-01T00:00:00Z) whose snapshots were
generated in a US timezone, so `formatRelativeTime`'s toLocaleDateString
fallback rendered 12/31/2019 there but 1/1/2020 under CI's UTC — failing CI
(fork CI never ran, so it slipped through). Moved the fixtures to noon UTC so
they render the same date in every timezone; verified passing under TZ=UTC and
TZ=America/Los_Angeles.
milestone view silently capped its issues list at 10 items. A user with
12 issues would see only 10 and could miss issues entirely when
iterating over the visible output in a script. The cap was also
undocumented in --help.
- Request first: 50 issues with pageInfo on the connection.
- Add --all to paginate through every page when needed.
- Show a prominent truncation footer pointing at --all and at
`linear issue query --milestone X --json` for full programmatic
access.
- Document the default cap in --help.
Closes#222
PR #216 adds --content/--content-file plus priority/label/member/icon/color
to `linear project create`, with happy-path snapshot tests and a
mutual-exclusion unit test. This adds the missing failure-path coverage that
both blind-planning passes called for:
- invalid --priority is rejected with a ValidationError before any network call
- an unknown --label surfaces a NotFoundError
- an unknown --member surfaces a NotFoundError
These use a stubbed Deno.exit and capture stderr (mirroring the validation
tests in issue-query.test.ts), and run against a mock Linear server so they
never touch the real API. No product code changes — the contributor's feature
is correct as written; this only locks in the error behavior.
## Why
Linear projects have two text fields: a short description and a longer
project overview. The CLI only supported the short description, so
projects created from the terminal still needed a manual edit in Linear
to add goals, plans, specs, or launch notes.
This PR lets users create a project with its overview already filled in,
either from inline markdown or a markdown file. That makes `linear
project create` more useful for scripted project setup, templates, and
project specs kept in a repo.
It also exposes a few existing Linear create fields so users can set
priority, labels, members, icon, and color when creating the project
instead of doing a follow-up edit.
## What changed
- `linear project create` now accepts `--content` for inline project
overview markdown.
- `--content-file` reads the project overview from a markdown file.
- `--content` and `--content-file` are mutually exclusive.
- Project create can now set priority, labels, members, icon, and color.
- The command passes these values through `ProjectCreateInput` using
Linear field names.
## Checks
- `deno task codegen`
- `deno task check`
- `deno lint`
- `deno task test`
PR #234 makes attachment uploads private by default and adds a --public
opt-in that errors (rather than silently downgrades) for non-image types.
Two gaps remained in `issue comment add`, both flagged independently while
blind-planning the fix:
- The public/type check only ran inside uploadFile, per file, at upload
time. With `--public` and multiple attachments, an earlier valid image
was uploaded *publicly* before a later non-image threw — a partial, and
unwanted-public, upload. Pre-flight resolveMakePublic() for every
attachment in the existing existence-validation loop so a mixed batch
fails before anything is uploaded.
- `--public` with no `--attach` was a silent no-op. Per the repo's
"explicit invalid input should error" convention, reject it.
Adds command-level tests for both validation paths (they short-circuit
before any network call, so no upload mock is needed).
Image attachments uploaded via `issue attach` and `issue comment add
--attach` were sent with makePublic auto-detected to true for raster
images, producing a public.linear.app URL readable by anyone,
unauthenticated, with no way to opt out. This silently published
screenshots of internal data from private workspaces.
Default all uploads to private (uploads.linear.app), matching the Linear
web app. Add a --public flag to both commands to opt into a public URL,
which is only valid for raster images; requesting it for other types is
now an error rather than a silent downgrade. Print a warning whenever an
upload lands on a public URL.
Also document the attachment commands and their privacy behaviour in the
README (previously undocumented) and regenerate the skill reference.
Fixes#233
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a 'B' column (with ⊘) to 'linear issue mine' and 'linear issue query'
that flags issues with at least one active blocker — a blocked-by relation
whose blocker is not in a completed or canceled workflow state. The
inverseRelations connection is also surfaced in --json output.
Document view's rendered/raw output now downloads inline images and
Linear-upload links to the same /tmp cache used by issue view, so terminal
renderers and downstream tools see local file paths instead of remote URLs
that require auth.
Image helpers (extractImageInfo, extractLinearLinkInfo, replaceImageUrls,
getUrlHash, getLinearUploadHost, downloadMarkdownImages) move from
src/commands/issue/issue-view.ts to src/utils/markdown-images.ts so both
commands share one implementation. downloadIssueImages becomes
downloadMarkdownImages, which takes an array of markdown sources rather
than an issue-specific (description, comments) tuple.
Adds --no-download to document view (mirroring issue view) and reorders
the command so the download step runs after the --json early return but
before --raw, matching issue view's behavior where piped output also gets
local paths.
Also adds remark-gfm to the parse/stringify pipeline used by
replaceImageUrls so GFM constructs (task lists, tables, strikethrough)
survive the URL rewrite. Without it, remark-stringify would re-escape
`- [ ] todo` as `* \[ ] todo` whenever an image is rewritten, mangling
documents and issue descriptions that lean on GFM syntax.
The skill docs check was failing because `Deno.consoleSize()` returns
different values depending on the runner's pseudo-terminal dimensions
(CI is wide, local terminals vary). Since the docs are for LLM
consumption and not correctness, dropping the `git diff` check and just
verifying generation doesn't crash.
Co-authored-by: Alex Broekhof <alex@quilt.com>
Co-authored-by: Peter Schilling <code@schpet.com>
Linear's comments connection returns newest-first and the GraphQL schema
doesn't expose a direction argument, so sort root comments ascending
client-side to match the order shown in Linear's UI.
Introduce 'issue mine' for personal work queue and 'issue query' for
structured retrieval with optional full-text search via --search.
Keep 'issue list' as a separate backwards-compatible command.
Remove standalone 'issue search' registration in favor of query --search.
query supports multi-team filtering, --all-teams, --json output,
--search-comments, and verifies GraphQL variables in tests.
## Summary
- include resolved-thread metadata and derived `threadId` in `linear
issue view --json`
- hide resolved threads by default in human-readable `issue view`, with
`--show-resolved-threads` to reveal them
- show root thread ids in rendered output and use OSC-8 hyperlinks for
them when terminal hyperlinks are enabled
## Testing
- deno check src/main.ts
- deno lint
- deno task test
- manual QA against CLI-team issues for default view,
`--show-resolved-threads`, JSON output, no-comments JSON, open-only
threads, OSC-8 behavior, and reply creation from printed thread ids
Co-authored-by: Peter Schilling <code@schpet.com>
## Summary
- Add **assignee** and **priority** fields to the `issue view` command's
metadata line
- Priority uses the existing `getPriorityDisplay` function (same visual
format as `issue list`)
- Assignee shows `@displayName` or `Unassigned` when null
- Both GraphQL queries (`GetIssueDetailsWithComments` and
`GetIssueDetails`) updated with `assignee { name displayName }` and
`priority`
## Motivation
These are critical fields for triaging issues. Previously, `issue view`
showed project, milestone, and cycle but not who owns the issue or how
urgent it is.
## Example output
```
# ENG-123: Fix authentication bug
**Priority:** ▄▆█ | **Assignee:** @Jane Smith | **Project:** Platform Infrastructure Q1
```
## Test plan
- [x] Updated all 10 issue-view snapshot tests with mock data covering:
unassigned/assigned, all priority levels (0-4)
- [x] `deno check src/main.ts` passes
- [x] `deno lint` passes
- [x] All issue-view tests pass (`deno test --allow-all --filter "Issue
View"`)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
Adds `-l, --label <label>` flag to `issue list` for filtering issues by
label name. The flag is repeatable — when multiple labels are specified,
only issues matching **all** labels are returned.
- Uses `eqIgnoreCase` for case-insensitive label name matching
- Single label: `filter.labels = { some: { name: { eqIgnoreCase: "Bug" }
} }`
- Multiple labels: `filter.labels = { and: [{ some: { name: {
eqIgnoreCase: "Bug" } } }, ...] }`
### Usage
```bash
# Single label
linear issue list --label Bug
# Multiple labels (AND logic)
linear issue list --label Bug --label "High Priority"
# Combined with other filters
linear issue list --label Bug --state started --cycle active
```
## Test plan
- [x] Added snapshot test for `issue list --label Bug` with mock server
- [x] Updated help text snapshot with new `--label` flag
- [x] `deno fmt` clean
- [x] `deno lint` clean
- [x] All tests pass, existing tests unaffected
---------
Co-authored-by: Peter Schilling <code@schpet.com>
Co-authored-by: Mihai Chiorean <mihai-chiorean@users.noreply.github.com>
## Summary
Adds `--json` / `-j` flag to three commands that were missing structured
output support:
- **`issue list --json`** — outputs issues as a JSON array with `id`,
`identifier`, `title`, `priority`, `estimate`, `state`, `labels`,
`assignee`, and `updatedAt`
- **`issue create --json`** — outputs the created issue's `id`,
`identifier`, `url`, and `team` as JSON (non-interactive path only)
- **`cycle list --json`** — outputs cycles as a JSON array with `id`,
`number`, `name`, `startsAt`, `endsAt`, `completedAt`, `isActive`,
`isFuture`, `isPast`, and `status`
When `--json` is set, the spinner is suppressed and empty results output
`[]` instead of human-readable messages.
This is particularly useful for AI agents and automation that need to
parse CLI output programmatically. The `linear api` raw GraphQL command
works as a workaround today, but first-class `--json` support on
list/create commands is much more ergonomic.
Related: #127 (requests `--json` on project commands — this PR covers
issue and cycle commands using the same pattern)
## Test plan
- [x] Added snapshot test for `issue list --json` with mock server
- [x] Added snapshot test for `issue create --json` with mock server
- [x] Added snapshot test for `cycle list --json` with mock server
- [x] Updated help text snapshots for all three commands
- [x] `deno fmt` clean
- [x] `deno lint` clean
- [x] All new tests pass, existing tests unaffected
Filter issues by project label name, showing issues from all projects
that have a given label. Uses Linear's native GraphQL project label
filtering rather than a two-step query.
A few practical improvements based on real usage friction:
- **Prerequisites**: Added `bunx linear` as a zero-install fallback for
when `linear` isn't on PATH
- **Discovering Options**: Added a note about commands with non-obvious
required flags — specifically that `issue list` requires `--sort` (valid
values: `manual`, `priority`) and `--team`, and that `--no-pager` is
only supported on `issue list`
Show the issue state (e.g., Todo, In Progress, Done) in the metadata
line of `linear issue view`, positioned before Project/Milestone/Cycle.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Joseph