@enrichlayer/el-linear 1.2.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Enrich Layer
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,219 @@
+<p align="center">
+  <img src="public/logo-256.png" alt="el-linear logo" width="160" height="160" />
+</p>
+
+<h1 align="center">el-linear</h1>
+
+A pragmatic CLI for [Linear.app](https://linear.app) — deterministic team /
+label / member resolution, structured issue validation, configurable term
+enforcement, and a GraphQL escape hatch for everything that isn't a
+first-class command.
+
+> **Note on naming.** This package was briefly published as
+> `@enrichlayer/linctl` with binary `linctl`, but reverted to
+> `@enrichlayer/el-linear` (binary `el-linear`) because of an npm name
+> collision with [dorkitude/linctl](https://github.com/dorkitude/linctl). See
+> [CHANGELOG.md](./CHANGELOG.md) for the migration recipe.
+
+## Install
+
+```bash
+pnpm add -g @enrichlayer/el-linear
+# or
+npm install -g @enrichlayer/el-linear
+```
+
+Requires Node.js ≥ 22.
+
+## Quickstart
+
+```bash
+# Run the interactive setup wizard. Only the API token is required;
+# every other step is skippable and revisitable later.
+el-linear init
+
+# Sanity-check
+el-linear teams list
+
+# Create your first issue
+el-linear issues create "Investigate flaky deploy" \
+  --team ENG --assignee alice --project "Reliability" \
+  --description "..."
+```
+
+`el-linear init` walks you through the API token, default team, member
+aliases, and other defaults. Each step is also a stand-alone sub-command
+(`el-linear init token`, `el-linear init aliases --import users.csv`, etc.) so
+you can revisit individual sections later. Skip is the default at every
+prompt — running the wizard twice with no input is a no-op.
+
+If you'd rather skip the wizard entirely, the configuration schema is
+fully documented in [docs/configuration.md](./docs/configuration.md) so
+any LLM or script can write `~/.config/el-linear/config.json` directly.
+
+Output is JSON by default. Pipe through `jq` for ad-hoc queries, or use
+the built-in `--jq` / `--fields` / `--raw` flags.
+
+## Why el-linear
+
+The Linear API + SDK are excellent. el-linear adds the layer above them that
+every team ends up writing themselves:
+
+| Concern | What el-linear gives you |
+|---------|----------------------|
+| **Name resolution** | Map team keys, member aliases, and label names to UUIDs from one config file. No fuzzy matching, no API roundtrips per call. |
+| **Issue hygiene** | Required labels, required assignee, required project, type-label-to-verb conventions — all configurable. Warn or hard-fail. |
+| **Term enforcement** | Catch misspellings of brand and project names in issue titles and descriptions ("EnrichLayer" → "Enrich Layer"). |
+| **Status defaults** | "No project? → Triage. Has assignee+project? → Todo." Per-workspace, configurable. |
+| **Auto-link & relate** | When you write `EMW-258` in a description, el-linear wraps it as a markdown link **and** creates the corresponding sidebar relation. Prose like "blocked by EMW-258" infers the relation type. |
+| **`--claude` flag** | Tag issues delegated to [Claude Code](https://claude.ai/code) for autonomous work. The label is plain config; the flag is muscle memory. |
+| **GraphQL escape hatch** | Anything not covered by built-in commands: `el-linear graphql '{ viewer { id } }'`. Schema introspection included. |
+| **Bundled Claude skill** | The published tarball includes a `claude-skills/linear-operations/` directory you can symlink into your project's `.claude/skills/`. |
+
+## Authentication
+
+The API token is resolved in this order:
+
+1. `--api-token <token>` flag.
+2. `LINEAR_API_TOKEN` environment variable.
+3. `~/.config/el-linear/token` file (recommended for human use).
+4. `~/.linear_api_token` file (legacy, still honored).
+
+el-linear never logs the token.
+
+## Configuration
+
+el-linear reads `~/.config/el-linear/config.json` on startup. All keys are
+optional; defaults work for casual use.
+
+```json
+{
+  "defaultTeam": "ENG",
+  "defaultLabels": ["claude"],
+  "members": {
+    "aliases": { "alice": "Alice Anderson" },
+    "uuids": { "Alice Anderson": "<uuid-from-linear>" }
+  },
+  "teams": { "ENG": "<uuid-from-linear>" },
+  "labels": {
+    "workspace": { "claude": "<uuid-from-linear>" },
+    "teams": { "ENG": { "feature": "<uuid-from-linear>" } }
+  },
+  "statusDefaults": {
+    "noProject": "Triage",
+    "withAssigneeAndProject": "Todo"
+  },
+  "terms": [
+    { "canonical": "Enrich Layer", "reject": ["EnrichLayer", "enrichlayer"] }
+  ]
+}
+```
+
+A full reference with every key documented lives in [config.example.json](./config.example.json).
+
+UUIDs come from the Linear UI (URL bars, settings pages) or via el-linear
+itself: `el-linear teams list --raw | jq '.[] | {key, id}'`, etc.
+
+## Term enforcement (with brand-promotion examples)
+
+The `terms` rules let you keep a list of canonical names and the misspellings
+to reject. el-linear warns (or in `--strict` mode, throws) when an issue title
+or description contains a rejected form.
+
+```json
+{
+  "terms": [
+    { "canonical": "Enrich Layer", "reject": ["EnrichLayer", "enrichlayer", "Enrichlayer"] },
+    { "canonical": "Linear",       "reject": ["linear.app", "Linear App"] },
+    { "canonical": "GitHub",       "reject": ["Github", "GitHUB"] }
+  ]
+}
+```
+
+```bash
+$ el-linear issues create "Add EnrichLayer auth flow" --team ENG --description "..." --strict
+Term enforcement failed:
+  - Found "EnrichLayer" — use "Enrich Layer" instead (1 occurrence)
+```
+
+URLs and file paths are exempt — `enrichlayer.com` and `path/to/enrichlayer`
+are allowed even though `enrichlayer` is rejected.
+
+If you don't define any rules, term enforcement is a no-op.
+
+## The `--claude` delegation pattern
+
+`el-linear issues create` accepts `--claude`, which applies the workspace label
+configured at `config.labels.workspace.claude`. The label is the contract:
+it tells [Claude Code](https://claude.ai/code) "this issue is delegated to
+you for autonomous execution."
+
+```bash
+el-linear issues create "Migrate auth middleware to new session store" \
+  --team ENG --assignee alice --project "Auth Refactor" \
+  --description "..." --claude
+```
+
+Claude finds delegated work with `el-linear issues search "claude" --status "Todo"`.
+
+## Commands at a glance
+
+```bash
+el-linear usage                  # full reference for all commands
+el-linear <command> --help       # detailed help for one command
+```
+
+| Group | Common commands |
+|-------|-----------------|
+| Issues | `issues {list, search, create, read, update, delete, history, related, link-references}` |
+| Comments | `comments {list, create, update}` |
+| Labels | `labels {list, create, retire, restore}` |
+| Projects | `projects {list, add-team, remove-team}` |
+| Cycles | `cycles {list, read}` |
+| Documents | `documents {list, read, create, update, delete}` |
+| Releases | `releases {list, read, create, pipelines}` |
+| Files | `embeds {upload, download}`, `attachments {list, create, delete}` |
+| Search | `search <query>` (semantic, cross-resource) |
+| Escape hatch | `graphql [query]` (with `--introspect`) |
+| Config | `config show`, `users list`, `teams list`, `templates list` |
+
+All `list` subcommands support `-l, --limit <n>`. All commands accept the
+top-level filters: `--raw`, `--jq <expr>`, `--fields <list>`.
+
+## Use with Claude Code
+
+el-linear ships a Claude Code skill at `claude-skills/linear-operations/SKILL.md`.
+After installing the package, symlink it into your project:
+
+```bash
+PKG=$(npm root -g)/@enrichlayer/el-linear
+ln -s "$PKG/claude-skills/linear-operations" .claude/skills/linear-operations
+```
+
+The skill teaches Claude Code el-linear's syntax, the duplicate/related issue
+check, the label taxonomy, the auto-link flow, and the `--claude` delegation
+pattern.
+
+## Development
+
+```bash
+git clone https://github.com/enrichlayer/el-linear.git
+cd el-linear
+pnpm install
+
+pnpm test                # vitest
+pnpm exec tsc --noEmit   # typecheck
+pnpm exec biome check src/
+pnpm run build
+node dist/main.js --version
+```
+
+See [CONTRIBUTING.md](./CONTRIBUTING.md) for the full guide.
+
+## Built by
+
+[Enrich Layer](https://enrichlayer.com) — data enrichment APIs.
+
+## License
+
+[MIT](./LICENSE).

package/claude-skills/linear-operations/SKILL.md

@@ -0,0 +1,315 @@
+---
+name: linear-operations
+description: "MUST be invoked before any el-linear CLI call. Covers el-linear syntax, label taxonomy, duplicate checking, issue creation conventions, and project management. Triggers on: \"create issue\", \"update issue\", \"search issues\", \"Linear\", \"el-linear\", \"label\", \"assign\". NOT for branch creation or full development workflows."
+allowed-tools: Bash(el-linear:*), Bash(which:*), AskUserQuestion, Read
+---
+
+# Linear Operations Skill
+
+All Linear operations should go through the **`el-linear` CLI**. For command syntax, run `el-linear usage` (all commands) or `el-linear <command> --help`.
+
+This skill covers **mandatory processes and non-obvious rules** — everything the CLI help doesn't tell you.
+
+> **Team-specific overrides.** Many teams keep their own issue-creation guide, label taxonomy, or member alias map. If your project has a `CLAUDE.md` or sibling skill that supplements this one, treat its rules as authoritative on top of these defaults.
+
+---
+
+## Intent-Driven Issue Writing
+
+Every issue should communicate **why** the work matters and **what** success looks like. This creates a track record of reasoning and gives the assignee room to find better solutions.
+
+### Principles
+
+1. **Lead with intent.** Start with why this work matters. The "Why we need this" section should explain real motivation (business problem, user pain, strategic context) — not restate the title.
+2. **Describe outcomes.** "Done when" criteria describe what success looks like. The assignee may find a more elegant path than the one you'd prescribe.
+3. **Respect expertise.** Provide context the assignee might lack (what a tool is, links to docs, business reasoning). Specific instructions are fine when you have relevant domain knowledge — but always pair them with the intent so the assignee understands the goal behind them.
+
+### Example
+
+```markdown
+## Set up a self-hosted CRM
+
+The team needs a CRM to replace fragmented contact tracking
+(spreadsheets + Linear + memory). Should be production-ready:
+reliable, backed up, accessible.
+
+## Why we need this
+As we scale outbound, we need customer relationships, pipeline,
+and outreach tracked in one place.
+
+## Done when
+- Team can access the CRM UI and create/edit contacts.
+- Data survives a server restart.
+- Accessible via a subdomain with TLS.
+```
+
+---
+
+## Duplicate & Related Issues Check (MANDATORY)
+
+**Search before creating. No exceptions.**
+
+```bash
+el-linear issues search "keywords from proposed title" 2>&1
+```
+
+1. Extract 2–3 key terms from the proposed title (skip generic words).
+2. Review results — classify each match:
+   - Same component + same problem = **duplicate** → comment on existing issue, don't create.
+   - Same component + different problem = **related** → create new issue with `--related-to`.
+   - Same domain but different component = **related** → create new issue with `--related-to`.
+   - Unrelated = proceed without linking.
+3. If a potential duplicate is found: show the user the existing issue(s), ask whether to comment, mark duplicate, or proceed.
+4. If related issues are found, **always create the relation** when creating the new issue:
+
+   ```bash
+   el-linear issues create "Title" --team ENG --related-to "ENG-456,ENG-789" ... 2>&1
+   ```
+
+### Viewing existing relations
+
+```bash
+el-linear issues related ENG-123 2>&1
+```
+
+Returns all relations (related, blocks, blockedBy, duplicate) with direction, state, and assignee. Use this before creating follow-up work to understand the context around an issue.
+
+### Auto-linking issue references on create/update
+
+`el-linear issues create`, `el-linear issues update`, `el-linear comments create`, and `el-linear comments update` run the same auto-linking flow on text being written:
+
+1. **Wrap as markdown links.** Bare identifiers (`ENG-100`, `DESIGN-22`) are rewritten to `[ENG-100](https://linear.app/<workspace>/issue/ENG-100/)`. Skipped inside fenced code blocks, inline backticks, existing markdown links, angle-bracket autolinks, and bare URLs.
+2. **Validate first.** Identifiers that don't resolve in the workspace (e.g. ISO codes like `ISO-1424`) are left as plain text — no link, no relation.
+3. **Create sidebar relations** on the parent issue. Default is `related`. Prose keywords upgrade the type:
+   - `blocked by X` / `depends on X` / `waiting on X` → `blocks` (X→source)
+   - `blocks X` / `prerequisite for X` → `blocks` (source→X)
+   - `duplicates X` / `duplicate of X` → `duplicate` (source→X)
+   - `duplicated by X` → `duplicate` (X→source)
+
+The output includes an `autoLinked` field with `linked`, `skipped`, and `failed` arrays.
+
+- A reference is **skipped** when any relation already exists.
+- A reference is **failed** when the identifier doesn't resolve.
+- Pass `--no-auto-link` on `create`/`update` to opt out of both wrapping and sidebar relation creation.
+
+To backfill an existing issue:
+
+```bash
+el-linear issues link-references ENG-123                      # description only
+el-linear issues link-references ENG-123 --include-comments   # description + comments
+el-linear issues link-references ENG-123 --dry-run            # preview
+```
+
+---
+
+## Pre-Work Check (Existing Issues)
+
+When starting work on an existing issue (`el-linear issues read ENG-123`):
+
+- [ ] **Assignee set** — if missing, ask user and update: `el-linear issues update ENG-123 --assignee <name>`.
+- [ ] **Project set** — if missing, ask user and update: `el-linear issues update ENG-123 --project "<name>"`.
+- [ ] **Status appropriate** — move to "In Progress" or your team's equivalent.
+
+Don't start implementation work on an unassigned issue. The assignee is the person accountable.
+
+---
+
+## Pre-Creation Validation Checklist
+
+Complete ALL items before creating any issue:
+
+- [ ] **Duplicate & related check** — searched for existing issues, linked related ones (above).
+- [ ] **Team** — ask user if unclear (`el-linear teams list`).
+- [ ] **Assignee** — ask user if unclear (`el-linear users list --active`).
+- [ ] **Project** — always ask user, never guess (`el-linear projects list`).
+- [ ] **Labels** — exactly 1 type label + 1–2 domain labels (see Label Taxonomy below).
+- [ ] **Title** — action verb matching the type label (see Title Verb Convention), sentence case, specific scope.
+- [ ] **Description** — 2–4 sentences with context and intent, formatted with **bold** and `inline code`.
+- [ ] **"Why we need this"** — genuine motivation, not a restatement of the title.
+
+If any field is missing, **STOP and use AskUserQuestion**.
+
+---
+
+## The `--claude` Delegation Pattern
+
+`el-linear issues create` accepts a `--claude` flag that applies the workspace-level "claude" label (configured at `config.labels.workspace.claude`). This is the canonical signal that an issue is **delegated to Claude Code** for autonomous execution.
+
+```bash
+el-linear issues create "Migrate auth middleware to new session store" \
+  --team ENG --assignee alice --project "Auth Refactor" \
+  --description "..." --claude 2>&1
+```
+
+When you see `--claude` in usage:
+
+- **As a writer**: use it to mark issues you want Claude to pick up. The label is the contract; combine it with a clear "Done when" so Claude knows what success looks like.
+- **As Claude**: if you find an issue with the `claude` label, you should treat it as in-scope work for autonomous progress. Search with `el-linear issues search "claude" --status "Todo"`.
+- **As a reviewer**: an issue's `claude` label tells you to weigh whether the description has enough acceptance criteria, since the assignee can't ask follow-up questions in a back-and-forth.
+
+The label is plain config — set it to anything you want, or skip it entirely. The flag is just sugar for `--labels claude`.
+
+---
+
+## User @Mentions
+
+Reference team members by name in comments. el-linear resolves both explicit `@name` tokens and bare capitalized references to proper Linear mentions.
+
+```bash
+el-linear comments create ENG-123 --body "cc @alice — Bob can you review?" 2>&1
+# Both "@alice" and "Bob" become Linear mentions.
+```
+
+- **Explicit `@name`** — always resolved. Config alias → display name → name (partial, case-insensitive) → API fallback.
+- **Bare capitalized names** — auto-converted by default when they match a configured member. Config-only — no API fallback — so false positives are bounded to your team. Skipped inside inline code, code blocks, and link text. Self-references are skipped.
+- **Opt out** per-invocation with `--no-auto-mention`.
+
+Works in comments only (not descriptions).
+
+---
+
+## CLI Syntax Rules
+
+Run `el-linear usage` for the full command reference. Non-obvious rules:
+
+- **Always append `2>&1`** to capture errors.
+- **Labels are comma-separated** — `--labels "feature,backend"` (not repeated flags).
+- **Singular/plural interchangeable** — `issues`/`issue`, `labels`/`label`, etc.
+- **Subcommand aliases** — `read`/`view`/`get`/`show`, `update`/`edit`/`set`.
+- **`--jq` for GraphQL filtering** — never pipe through `jq` directly (zsh escaping breaks `!=`).
+- **`--raw` flag** strips the `{ data, meta }` wrapper — emits just the array.
+
+### Output format
+
+| Command type | Shape |
+|--------------|-------|
+| List | `{ "data": [...], "meta": { "count": N } }` |
+| Single resource | Flat object |
+| Error | `{ "error": "message" }` |
+
+---
+
+## Error Handling
+
+1. **Check for `"error"` key** before accessing fields like `identifier`.
+2. **Do NOT retry** failed commands — report the error.
+3. Common errors and fixes:
+   - "Label not found" → check `el-linear labels list --team X`.
+   - "Label is a group label" → use a child label, not the parent.
+   - "Project may not be associated with this issue's team" → fix with `el-linear projects add-team`.
+   - "User not found" → check `el-linear users list --active`.
+
+---
+
+## Label Taxonomy
+
+### Type Labels (Required: exactly 1)
+
+The default el-linear validation expects one of these:
+
+| Label | When |
+|-------|------|
+| `feature` | New functionality. |
+| `bug` | Broken behavior. |
+| `refactor` | Improving code without changing behavior. |
+| `chore` | Maintenance, dependencies, tooling. |
+| `spike` | Research or investigation. |
+
+Customize the set per-config: `validation.typeLabels: ["feature", "bug", ...]`. Domain labels (`frontend`, `backend`, etc.) are not enforced — define your own.
+
+### Title Verb Convention
+
+Title must start with a verb that matches the type label:
+
+- `bug` → Fix, Resolve, Patch, Handle, Address, Correct
+- `feature` → Add, Build, Create, Implement, Enable, Ship, Launch, Design, Wire, Integrate
+- `chore` → Update, Remove, Clean, Migrate, Deploy, Rotate, Configure, Document, Review, Publish, Standardize, Upgrade
+- `spike` → Research, Investigate, Explore, Evaluate, Audit, Benchmark
+- `refactor` → Refactor, Restructure, Extract, Decouple, Simplify
+
+### Rules
+
+- **Create missing labels liberally** — `el-linear labels create "my-label" --team ENG`.
+- **`--claude` flag** adds the workspace-level "claude" label automatically.
+- Ask the user to confirm labels if you're unsure about domain.
+
+---
+
+## Term Enforcement (`config.terms`)
+
+el-linear can flag misspellings of brand or project names in titles and descriptions. Configure rules in `~/.config/el-linear/config.json`:
+
+```json
+{
+  "terms": [
+    { "canonical": "Enrich Layer", "reject": ["EnrichLayer", "enrichlayer"] },
+    { "canonical": "Linear", "reject": ["linear.app", "Linear App"] },
+    { "canonical": "GitHub", "reject": ["Github", "github"] }
+  ]
+}
+```
+
+When el-linear finds a rejected token in an issue title or description, it warns (or in `--strict` mode, throws). The check tolerates URLs and file paths — `enrichlayer.com` is allowed even though `enrichlayer` is rejected.
+
+If you don't configure any rules, term enforcement is a no-op.
+
+---
+
+## Project Management Gotchas
+
+### Content vs Description
+
+Linear projects have two text fields — **both must be populated**:
+
+- `description` — short summary (max 255 chars), shown in lists.
+- `content` — full markdown body, shown in main panel.
+
+If you only set one, the other shows blank.
+
+### Cross-Team Projects
+
+Creating an issue on team X with a project from team Y → "Project not in same team" error. Fix:
+
+```bash
+el-linear projects add-team "Project Name" ENG 2>&1
+```
+
+**Never use raw `projectUpdate` with `teamIds`** — it replaces the entire team list. Always use `projects add-team` / `remove-team`.
+
+### Discovery Before Creation
+
+Always check if a project exists before creating: `el-linear projects list --limit 50`.
+
+---
+
+## Git/GitLab/GitHub Integration
+
+If your Linear workspace is connected to a code host, status transitions happen automatically:
+
+- Creating a PR/MR → linked issue moves to "In Review".
+- Merging a PR/MR → linked issue moves to "Done".
+
+No manual status updates needed after PR/MR events.
+
+### Intermediate Deliverable Rule
+
+**Any PR/MR whose branch contains an issue ID will auto-close that issue on merge.** This is dangerous for multi-phase issues where a PR delivers only part of the work.
+
+**Rule:** if the PR doesn't complete ALL acceptance criteria of the parent issue, create a sub-issue and branch from that. The parent stays open.
+
+```text
+Parent: ENG-100 "Review API design"          ← stays open
+  └─ Sub: ENG-101 "Write API design doc"     ← branch: feature/ENG-101-write-api-design-doc
+                                                PR merges → only ENG-101 closes
+```
+
+---
+
+## Checklist Progress Tracking
+
+When working on an issue with a checklist, check off items as you complete them.
+
+1. Read the issue: `el-linear issues read ENG-123`.
+2. Update the description with checked items: `el-linear issues update ENG-123 --description "..."`.
+3. Preserve the rest of the description — only change `- [ ]` to `- [x]`.
+4. If all items are done, update the status accordingly.

package/claude-skills/linear-operations/evals/evals.json

@@ -0,0 +1,46 @@
+{
+	"skill_name": "linear-operations",
+	"evals": [
+		{
+			"id": 1,
+			"prompt": "Create a Linear issue for fixing the login bug on the staging environment",
+			"expected_output": "The skill searches for duplicate issues first, selects appropriate labels from the taxonomy, creates an issue with a description containing 'Why we need this' section, and uses el-linear create command",
+			"expectations": [
+				"Searches for existing issues to avoid duplicates before creating",
+				"Selects labels from the known label taxonomy (e.g., bug)",
+				"Description includes a 'Why we need this' section",
+				"Uses el-linear CLI to create the issue, not raw curl"
+			]
+		},
+		{
+			"id": 2,
+			"prompt": "Search Linear for auth-related issues",
+			"expected_output": "The skill uses el-linear search to find issues matching auth keywords",
+			"expectations": [
+				"Uses el-linear search command with appropriate query",
+				"Does not attempt to use curl against api.linear.app",
+				"Returns formatted results with issue IDs and titles"
+			]
+		},
+		{
+			"id": 3,
+			"prompt": "Update DEV-123 to In Progress",
+			"expected_output": "The skill uses el-linear update to change the issue status",
+			"expectations": [
+				"Uses el-linear update command with the issue identifier DEV-123",
+				"Sets the status to In Progress",
+				"Does not create a new issue"
+			]
+		},
+		{
+			"id": 4,
+			"prompt": "Create a git branch for DEV-456",
+			"expected_output": "This should NOT trigger linear-operations. Branch creation from Linear issues is handled by git-branch-from-linear skill.",
+			"expectations": [
+				"Does NOT trigger linear-operations skill",
+				"Routes to git-branch-from-linear instead",
+				"No el-linear create or update commands are issued"
+			]
+		}
+	]
+}

package/dist/commands/attachments.d.ts

@@ -0,0 +1,2 @@
+import type { Command } from "commander";
+export declare function setupAttachmentsCommands(program: Command): void;

package/dist/commands/attachments.js

@@ -0,0 +1,57 @@
+import { getApiToken } from "../utils/auth.js";
+import { FileService } from "../utils/file-service.js";
+import { createGraphQLAttachmentsService } from "../utils/graphql-attachments-service.js";
+import { createLinearService } from "../utils/linear-service.js";
+import { handleAsyncCommand, outputSuccess } from "../utils/output.js";
+export function setupAttachmentsCommands(program) {
+    const attachments = program
+        .command("attachments")
+        .description("Manage file attachments on issues.");
+    attachments.action(() => attachments.help());
+    attachments
+        .command("create <issueId>")
+        .description("Upload a file and attach it to an issue.")
+        .requiredOption("--file <path>", "path to file to upload")
+        .option("--title <title>", "attachment title (defaults to filename)")
+        .action(handleAsyncCommand(async (issueId, options, command) => {
+        const rootOpts = command.parent.parent.opts();
+        const apiToken = getApiToken(rootOpts);
+        const linearService = createLinearService(rootOpts);
+        const resolvedIssueId = await linearService.resolveIssueId(issueId);
+        const fileService = new FileService(apiToken);
+        const uploadResult = await fileService.uploadFile(options.file);
+        if (!uploadResult.success) {
+            throw new Error(uploadResult.error);
+        }
+        const attachmentsService = createGraphQLAttachmentsService(rootOpts);
+        const attachment = await attachmentsService.createAttachment({
+            issueId: resolvedIssueId,
+            url: uploadResult.assetUrl,
+            title: options.title || uploadResult.filename,
+        });
+        outputSuccess(attachment);
+    }));
+    attachments
+        .command("list <issueId>")
+        .description("List attachments on an issue.")
+        .option("-l, --limit <number>", "maximum number of attachments", "50")
+        .action(handleAsyncCommand(async (issueId, options, command) => {
+        const rootOpts = command.parent.parent.opts();
+        const linearService = createLinearService(rootOpts);
+        const resolvedIssueId = await linearService.resolveIssueId(issueId);
+        const attachmentsService = createGraphQLAttachmentsService(rootOpts);
+        const allAttachments = await attachmentsService.listAttachments(resolvedIssueId);
+        const limit = Number.parseInt(options.limit, 10);
+        const data = allAttachments.slice(0, limit);
+        outputSuccess({ data, meta: { count: data.length } });
+    }));
+    attachments
+        .command("delete <attachmentId>")
+        .description("Delete an attachment.")
+        .action(handleAsyncCommand(async (attachmentId, _options, command) => {
+        const rootOpts = command.parent.parent.opts();
+        const attachmentsService = createGraphQLAttachmentsService(rootOpts);
+        await attachmentsService.deleteAttachment(attachmentId);
+        outputSuccess({ success: true, message: "Attachment deleted" });
+    }));
+}

package/dist/commands/batch.d.ts

@@ -0,0 +1,2 @@
+import type { Command } from "commander";
+export declare function setupBatchCommands(program: Command): void;