| name | linear-workspace |
| description | Linear issue management — routes work to specialized agents and slash commands. Use when: creating, updating, searching, bulk-editing, cleaning up, syncing Linear. TRIGGERS: "linear", "ticket", "issue", "create issue", "update issue", "search issues", "my issues", "bulk", "cleanup", "sync", "log bug", "file issue", "report bug", "new ticket", "add task", "open ticket", "open issue", "throw this in linear", "track this in linear", "capture as issue", "put on the backlog".
|
Linear Workspace
Router for Linear work. Dispatches to specialized agents or slash commands rather than running things inline.
Dispatch table
| Intent | Action |
|---|
| Create one issue from a description | Agent: linear-issue-creator |
| Create issues from a URL / article / design | Agent: linear-url-to-issues |
| Review one existing issue (clarity, completeness) | Agent: linear-issue-reviewer |
| Edit one existing issue (state, assignee, comment, close, …) | Agent: linear-issue-updater |
| Search / list issues | Slash command: /linear-search |
| List your own issues | Slash command: /linear-my-issues |
| Apply the same change to many issues | Slash command: /linear-bulk |
| Find + handle stale issues | Slash command: /linear-cleanup |
| Refresh reference data from Linear | Slash command: /linear-sync |
| Run the curator (collect signals from external sources) | Slash command: /linear-curator-run |
For parallel work (e.g. 5 issues from 5 URLs), dispatch multiple agents in a single message — that's why they exist.
First-run install
/plugin marketplace add Elnora-AI/elnora-linear then /plugin install linear-workspace@elnora-linear- Make sure the
elnora-linear CLI is on your PATH: npm install -g @elnora-ai/linear
- On your first Linear command, you'll be prompted for your Linear API key (get one at https://linear.app/settings/api). It's saved to
~/.config/elnora-linear/.env (mode 0600).
- Populate the reference files:
/linear-sync (runs elnora-linear sync all — fetches teams, projects, users, workflows in one batch).
Reference files
The plugin reads user-specific config from ~/.config/elnora-linear/ by default (override via LINEAR_REFERENCES_DIR):
teams.json, projects.json, users.json, workflows.json — populated by /linear-syncslack.json, repos.json, signal-sources.json, label-policy.json — populated manually (schemas in schemas/, examples in references/*.example.json)
Run elnora-linear sync verify to see which are populated vs placeholder.
Dispatch prompt — what to include
- The user's raw request, verbatim
- Suspected team (let the agent confirm via
elnora-linear teams list)
- Compliance flag (see below), if any
- Anything the user already specified (project, priority, assignee, due date)
- If a URL appears anywhere in the request → dispatch to
linear-url-to-issues, not linear-issue-creator
The agent handles searching for duplicates, label requirements, state matching, and asking the user about anything unclear.
Fast-path saves tokens
The creator agent has a fast path that skips the dupe scan, project-status check, and reference reads when the dispatch already specifies team + project + priority + assignee + a clear novel title (and no compliance keywords). When you have all five, write them out explicitly in the prompt — the agent will detect the fast path and complete in roughly one CLI call instead of three.
Compliance flag
If the request mentions any of: incident, breach, vulnerability, CVE, pentest, penetration test, onboarding, offboarding, access provision/revoke, audit, SOC 2, change request, risk assessment, vendor review, backup test, RCA, lessons learned, DPA, DSR / data subject request — say so in the dispatch prompt. The agent will load references/template-index.md and apply the matching template (SEC-*, CHG-*, ACC-*, AUD-*, RSK-*, OPS-*, SLA-*, RCA-*, LRN-*).
Model tiering — pass model: on the Agent dispatch
Match the model to task complexity. The agent frontmatter sets the default; override per-dispatch when the task is clearly easier or harder. Haiku < Sonnet < Opus on cost AND token usage — Opus uses more tokens than Sonnet for the same task, not fewer. It's a quality escalation, never a token-saving move.
| Task | Agent | Model | Why |
|---|
| Fast-path create (all fields explicit, no compliance) | linear-issue-creator | haiku | Mechanical CRUD, single CLI call |
| Full-path create (ambiguous routing, dupe scan, compliance template) | linear-issue-creator | sonnet | Branching + judgment |
| Single-field update (state, assignee, priority, label add) | linear-issue-updater | haiku | One CLI call, fixed flag |
| Cross-team move, full description rewrite | linear-issue-updater | sonnet | Validates required labels across teams |
| URL → issues extraction | linear-url-to-issues | sonnet | Real synthesis from unstructured content |
| Issue completeness review | linear-issue-reviewer | sonnet | Reads description + comments + acceptance criteria |
| Headless curator pass (scheduled) | linear-state-curator | haiku | Mechanical signal collection + tier dispatch |
| Interactive curator dry-run / triage | linear-state-curator | sonnet | Reading curator-report.jsonl + judgment calls on MEDIUM queue |
Don't reach for Opus by default. Sonnet handles every Linear task cleanly. Only escalate to Opus if Sonnet has actually failed on this task type (looped, produced wrong output, gave up). If the request mentions a compliance keyword, upgrade the creator to Sonnet automatically.
Dispatch prompt budget
When the user request is fully specified, keep the dispatch prompt short — the agent already knows the playbook. Pass through:
- The user's raw request, verbatim
- Team / project / priority / assignee if explicit
- Compliance flag if relevant
Don't re-format the description, don't restate the playbook, don't tell the agent how to structure its output. A 100-token dispatch prompt is fine; a 500-token one wastes tokens with no quality gain.
Cold-start primitive
For workflows that need team metadata up front (e.g. extracting N issues from a URL into one team), the parent should suggest the agent call elnora-linear context --team "<Team>" ONCE before iterating. The response contains projects with statuses, workflow states, the full label catalog grouped by prefix, the required-label policy, and active members — replacing four separate calls (teams get + projects list --team + states list --team + labels list --team) and eliminating every reference-file read.
The CLI is the source of truth for label policy: elnora-linear projects get and elnora-linear teams get both return requiredLabels and validStates directly. elnora-linear issues create rejects invalid label combinations with a structured error (missing, availableForPrefix, suggestedRetry) so the agent can self-correct in one retry without reading any reference file.
Safety guardrails
bulk and cleanup default to dry-run — they print what would change and require --yes to commitbulk requires at least one of --set-state or --add-comment — refuses no-op invocationscleanup defaults to comment action (least destructive); close / cancel are explicit opt-insexternal_command signal sources run user-configured commands with the user's privileges — only configure commands from sources you trust- Permanent deletes need an explicit
--yes at the CLI layer — a prompt-injected agent cannot bypass it
- Full guarantees and gated commands documented in SAFETY.md
Don't
- Don't read reference
.md files for label requirements — required-label policy is enforced server-side by the CLI
- Don't run the create/update workflow inline. The agent owns it.
- Don't pick a team without confirming via
elnora-linear teams list or references/teams.json
