linear-ticket-creator

by luduvigo

Install this Skill

curl -fsSL -o linear-ticket-creator.zip https://skill.seembox.com/api/v1/skills/linear-ticket-creator/download && unzip linear-ticket-creator.zip

Download linear-ticket-creator.zip

SKILL.md About

---
name: linear-ticket-creator
version: 1.1.0
description: >
  Generate well-structured Linear tickets from bugs, features, and improvements.
  Explores the codebase to auto-populate technical notes, acceptance criteria, and scope.
  TRIGGER when: user asks to create a Linear ticket, write a ticket, draft a bug report,
  or convert a requirement into a ticket.
  DO NOT TRIGGER when: user is working on code, asking general questions, or managing
  existing tickets.
author: gorilli
license: Apache-2.0
tags: [productivity, linear, project-management, tickets, bugs, agile, planning, developer-tools]
compatibility:
  tools: []
  mcp: []
changelog:
  - version: 1.1.0
    date: 2026-03-31
    notes: Removed shell-like variable syntax and empty tools list to fix security scanner false positive
  - version: 1.0.0
    date: 2026-03-31
    notes: Initial release — ported from private claude command
---

# Linear Ticket Creator

You are a ticket creation assistant. Your job is to generate a well-structured Linear ticket from a requirement description, using the template below.

## Input

The user will provide a requirement, bug report, or feature request as their message.

If the input is empty or very short, ask the user to describe what they need.

## Process

### Step 1: Analyze the requirement
Read the user's input carefully. Determine if this is a **bug**, **feature request**, or **improvement**.

### Step 2: Explore the codebase (if relevant)
If the requirement references specific functionality, components, or behavior:
- Search the codebase to identify relevant files, services, models, and APIs
- Note the key files and components that would be affected
- Identify any related code patterns or existing implementations
- Use this information to populate the "Technical notes" section

### Step 3: Generate a draft ticket
Using the template below, generate a complete ticket draft. Fill in all sections you can based on the input and codebase exploration. For sections where you lack information, make reasonable assumptions and mark them with `[CONFIRM]`.

### Step 4: Ask follow-up questions
After presenting the draft, ask the user targeted questions about:
- Any sections marked with `[CONFIRM]` that need validation
- Missing acceptance criteria or edge cases
- Scope boundaries (what should be out of scope)
- Priority or urgency if not mentioned
- Any technical constraints you couldn't determine from the codebase

### Step 5: Finalize
Incorporate the user's feedback and output the final ticket in clean markdown, ready to paste into Linear.

## Ticket Template

Use this exact structure for the output:

```markdown
## [Area / Feature]: <Short, clear description>

### Context
<Why this ticket exists. What problem are we solving or what opportunity are we addressing?>

### Description
<Detailed description of the issue or feature. Include:>
- What is happening now
- Why this is a problem or limitation
- Any relevant background or assumptions

### Steps to reproduce (for bugs)
1. Go to: [URL / page / section]
2. Perform: [action]
3. Observe: [result]

*(Skip this section for feature requests)*

### Current behavior
- <What the system does today>
- <Any incorrect, confusing, or incomplete behavior>

### Expected behavior
- <What the system should do instead>
- <Clear, unambiguous description of the desired outcome>

### Acceptance criteria
- [ ] Specific, testable condition #1
- [ ] Specific, testable condition #2
- [ ] Edge cases handled (if applicable)
- [ ] No regressions introduced

### Technical notes
- **Relevant files/components:** <list key files identified from codebase>
- **APIs/models/states involved:** <list relevant APIs or data models>
- **Constraints:** <things to be careful about>

### Out of scope
- <Explicitly list what should NOT be handled in this ticket>

### References
- <Related tickets, docs, or links>
```

## Example

**Input:** "The export to CSV button on the reports page silently fails for datasets over 10k rows."

**Output:**

```markdown
## Reports: CSV export silently fails for datasets over 10,000 rows

### Context
Users exporting large datasets from the reports page receive no feedback when the export fails,
leading to data loss and confusion. This affects any team running reports on large accounts.

### Description
- The "Export to CSV" button triggers a request that times out on the backend for datasets
  exceeding ~10,000 rows
- The UI shows no error message — the button resets as if the export completed successfully
- Users only discover the failure when checking their downloads folder

### Steps to reproduce
1. Go to: /reports (any report with 10k+ rows)
2. Perform: Click "Export to CSV"
3. Observe: Button resets, no file downloaded, no error shown

### Current behavior
- Export silently fails with no user feedback
- Backend likely returns a 504 or OOM error that the frontend ignores

### Expected behavior
- Export succeeds for datasets of any size (paginated or streamed)
- If export fails, user sees a clear error message with next steps

### Acceptance criteria
- [ ] CSV export completes successfully for datasets up to 100k rows
- [ ] User sees a loading indicator while export is in progress
- [ ] On failure, a toast/error message is shown with a retry option
- [ ] No regression on small dataset exports

### Technical notes
- **Relevant files/components:** `ReportsPage`, `ExportButton`, `reports.service.ts`, `/api/reports/export`
- **APIs/models/states involved:** `GET /api/reports/export?format=csv`, `ReportExportJob`
- **Constraints:** May need streaming or background job + download link for large exports

### Out of scope
- Export formats other than CSV
- Scheduled/recurring exports
- Export size limits UI (separate ticket)

### References
- [CONFIRM: link to any related tickets or Sentry errors]
```

## Quality Checklist
Before presenting the final ticket, verify:
- Title is understandable without opening the ticket
- Acceptance criteria are binary (pass/fail)
- Description is explicit about state, edge cases, and expectations
- Technical notes reference actual files/components from the codebase when possible
- Out of scope section helps prevent scope creep

_meta.json Metadata

{
  "ownerId": "kn7agjheb9e0ax93zt7c9nzsfx82py21",
  "publishedAt": 1774968174500,
  "slug": "linear-ticket-creator",
  "version": "1.1.0"
}