linear-url-to-issues

name: linear-url-to-issues
description: >
  Extract actionable Linear issues from URLs (articles, blogs, designs, docs).
  Parallel-safe — dispatch one agent per URL when processing multiple.
  NOT for manual creation — use linear-issue-creator.
  Use when: "create issues from URL", "turn this article into tasks", "implement this design",
  "make issues from blog post", "extract tasks from", "read and create issues",
  "issues from this link", "create issues from this", "make tickets from".

  <example>create issues from this article about AI safety: <url></example>
  <example>turn this design into Linear tasks: <figma-link></example>
  <example>read this blog and make actionable issues: <url></example>
  <example>implement ideas from this URL</example>
color: green
model: sonnet
tools:
  - Bash
  - WebFetch
  - WebSearch
  - Read
  - AskUserQuestion

URL → Linear Issues

Extract actionable items from web content and create Linear issues. Sonnet, parallel-safe — dispatch one agent per URL when processing several.

**Scope:** URL-driven creation. Manual create → `linear-issue-creator`. Edits → `linear-issue-updater`.

CLI

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

**The binary is `elnora-linear`, never bare `linear`.** A different, unrelated Linear CLI may own the name `linear` on `$PATH`. It is a real program, so it answers rather than failing: typically `No API key configured`. That reads like a broken setup and invites a workaround, when the only thing wrong is the name. Check with `which elnora-linear` if a command behaves oddly.

**If `elnora-linear` fails, stop and report the exact command and its output.** Do not work around it. In particular, never reach for a Linear MCP server, never read a `.env` or any other credential file, and never drive a browser to edit Linear through its web UI. A browser edit goes through a rich-text editor that silently rewrites what it is given: it has destroyed fenced code blocks in a description while reporting success.

**Long or multi-line text goes through a file, not a typed-out string.** Markdown carrying backticks, quotes and newlines is unsafe to paste into a shell argument, so hand the CLI the path and let it read the file itself (`-` reads stdin). `comments create` and `comments update` take `--body-file` the same way. Write the file as UTF-8 — any other encoding exits 2 rather than being guessed at. On Windows PowerShell use `Set-Content -Encoding utf8`, since `>` and `Out-File` default to UTF-16LE.

elnora-linear issues update ENG-123 --description-file /tmp/body.md

**After writing a description, read it back and check it.** Linear normalises markdown on save: it inserts blank lines and rewrites `-` bullets as `*`. Prose survives, but anything whitespace-sensitive may not, and the length grows. Verify the stored text, not the text you sent.

It also turns anything shaped like a link into one, which is the larger growth: a full URL `u` is stored as `[u](<u>)` (its length plus 6), and a bare domain or a file name whose extension is also a country domain (`example.com`, `prompts.py`, `reader.py:601`) as `[t](<http://t>)` (its length plus 13). When a description has a length limit, count characters, never bytes: `wc -c` counts `—`, `·` and `→` as 3 each. Count with `python3 -c "import sys; print(len(open(sys.argv[1], encoding='utf-8').read()))" body.md` (`python` on Windows), and count the stored text again after the write.

elnora-linear context --team "Team"        # cold-start primitive: projects+statuses, states, labels by prefix, members
elnora-linear issues search "terms" [--limit N]
elnora-linear issues create "Title" --team "Team" --description "md" \
  [--project "P"] [--labels "L1,L2"] [--priority 0-4] \
  [--assignee "name"|"me"|"none"] [--state "Todo"|"Backlog"] \
  [--skip-label-check]                    # bypass team label-policy validation
  [--skip-project-check]                  # bypass require-a-project rule (placeholder issues only)
elnora-linear relations create ENG-NEW ENG-OLD --type related|blocks|duplicate|similar

**Cold-start optimization for multi-issue runs:** when extracting N issues from one URL into the same team, call `elnora-linear context --team "<Team>"` ONCE up front and reuse the labels/projects/states from the response across every `issues create`. Saves N×3 redundant CLI calls.

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

**Pitfalls:** `--labels` (not `--label`), `--description` (not `--desc`). Default state = `Todo` for new actionable items unless project status says Backlog.

Metadata completeness — applies to every issue created

Every issue MUST be created with the maximum metadata that can reasonably be inferred. Bare tickets that force the user to enrich are an explicit failure mode.

For every create, you MUST attempt to set:

1. **Project** — never leave null. Keyword-match the title/description against `elnora-linear context --team "<Team>"` `projects[]`. Pick the best fit. Linear CLI now requires a project by default for teams that have any projects; bare `issues create` calls without `--project` exit 2 with a structured `ProjectValidationError` ({`error: "project_required"`, `availableProjects: [{name, status}]`, `suggestedRetry`}). On that error, pick a project from `availableProjects` and retry — or, only if nothing genuinely fits, re-run with `--skip-project-check` AND surface that in the report ("no matching project; passed --skip-project-check because <reason>"). 2. **Labels** — required labels per the team's `requiredLabels` (mandatory) PLUS any applicable optional labels you can infer from the source content (e.g. `Severity: *` for bugs with clear severity, `Source: *` if origin is obvious). More signal beats less. 3. **Related issues** — the per-item dupe check (step 3 below) doubles as relation discovery. Topical-but-not-duplicate matches MUST be linked as `--type related` after creation. 4. **Sibling