🎁 Get the FREE AI Skills Starter Guide β€” Subscribe β†’
BytesAgainBytesAgain
BytesAgain β€Ί Skills β€Ί Linear Ticket Creator
πŸ¦€ ClawHub

Linear Ticket Creator

by @luduvigo

Generate well-structured Linear tickets from bugs, features, and improvements. Explores the codebase to auto-populate technical notes, acceptance criteria, a...

Versionv1.1.0
Downloads545
#clawhub
TERMINAL
clawhub install linear-ticket-creator

πŸ“– About This Skill

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:

    ## [Area / Feature]: 
    Context
    

    Description
    


  • 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
    

    • 

    • Expected behavior
    

    • 

    • Acceptance criteria
    

  • [ ] Specific, testable condition #1
    • 

  • [ ] Specific, testable condition #2
    • 

  • [ ] Edge cases handled (if applicable)
    • 

  • [ ] No regressions introduced
    • Technical notes
    

  • Relevant files/components: 
    • 

  • APIs/models/states involved: 
    • 

  • Constraints: 
    • Out of scope
    

    • References
    

    •

    Example

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

    Output:

    ## 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

    • πŸ’‘ Examples

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

    Output:

    ```markdown