| name | create-ticket |
| description | Use when the user wants to create a Linear ticket, issue, user story, or task - interviews the user adaptively, formats as a user story with test plan, and creates it via Linear MCP after confirmation |
Create Linear Ticket
Overview
Interview the user to understand their request, then create a well-structured Linear ticket as a user story with acceptance criteria and a test plan. Tickets follow TDD: they're only Done when all tests pass.
Key principle: A ticket documents the what (the problem) and how to verify (the test plan), never the how to fix. Root cause analysis, code investigation, and solution design belong to the implementation phase when someone picks up the ticket. Code changes between ticket creation and implementation, so any fix proposed at creation time risks being stale or misleading. Do NOT explore the codebase, search for root causes, or propose solutions during ticket creation.
Process
Phase 1: Understand the Request
Start by asking what the user wants to build or fix. Use AskUserQuestion to gather information adaptively:
Always ask first:
- What's the problem or request? (open-ended, let them describe it)
Then adapt based on complexity:
For simple/clear requests, propose sensible defaults and move to confirmation.
For complex/ambiguous requests, follow up with:
- Who is affected? (user role for the story)
- What's the expected behavior vs current behavior?
- Any technical constraints or preferences?
- Priority: Urgent, High, Normal, or Low?
- Area labels: Bug, Feature, Improvement + component labels (Agent, Frontend, Tools)
Guidelines:
- Ask 1-3 questions at a time, not a wall of questions
- If the user gave a detailed description upfront, don't re-ask what they already told you
- Infer what you can (e.g., if they say "the button doesn't work", it's a Bug + Frontend)
- Default priority to Normal unless the user signals urgency
- Default team to "Nova-Development"
- Auto-assign to "me"
Phase 1.5: Complexity Check
Before drafting, assess whether the request is a single ticket or needs to be split. A good ticket should be completable in one focused effort.
Signs a ticket is too big:
- More than 5-6 acceptance criteria
- Touches multiple unrelated areas (e.g., "redesign the frontend and refactor the API")
- Contains multiple independent deliverables (e.g., "add search, filtering, and sorting")
- The user story has multiple distinct goals joined by "and"
If it's too big, propose splitting it. Present the breakdown to the user as a set of smaller tickets, each with its own user story. Ask which ones to create. Each sub-ticket should be independently valuable and testable - not just arbitrary slices.
If it's borderline, ask the user: "This could be one ticket or split into N. Preference?"
Phase 2: Draft the Ticket
Format the ticket as a user story with this structure:
## User Story
As a [role], I want [goal], so that [benefit].
## Context
[Brief problem description or background - what's happening now and why it needs to change]
## Acceptance Criteria
- [ ] [Specific, testable criterion 1]
- [ ] [Specific, testable criterion 2]
- [ ] [...]
## Test Plan
### Unit Tests
- [ ] [Test case 1: what to test and expected outcome]
- [ ] [Test case 2: ...]
### Integration Tests (if applicable)
- [ ] [Test case: ...]
### Manual Verification (if applicable)
- [ ] [Step to verify: ...]
## Definition of Done
- [ ] All acceptance criteria met
- [ ] All test cases implemented and passing
- [ ] Code reviewed
Writing guidelines:
- Acceptance criteria must be specific and testable - no vague "works correctly"
- Test cases should map to acceptance criteria, automated tests should be preferred
- Include edge cases in the test plan
- Keep it concise - no fluff
- Describe the observable problem and expected behavior - never propose root causes, code changes, or implementation approaches
- Test cases describe what to verify, not how to implement the fix
Phase 3: Confirm and Create
Present the full draft to the user in a formatted message. Ask for approval or changes.
On approval, create the issue using the Linear MCP tools:
- Team: "Nova-Development" (unless overridden)
- Assignee: "me" (unless overridden)
- Title: concise, imperative (e.g., "Fix task card drag-and-drop on mobile")
- Description: the full user story markdown from Phase 2
- Labels: inferred from the conversation (Bug/Feature/Improvement + component labels)
- Priority: as discussed (1=Urgent, 2=High, 3=Normal, 4=Low)
- State: "Backlog" (default)
On changes, revise and re-present.
When creating multiple tickets (from a split), create them all after approval. If there's a natural ordering, set up blocking relationships between them.
After creation, show the user the issue identifier(s) (e.g., NOV-123) so they can find them in Linear.
Label Reference
| Label | Use When |
|---|
| Bug | Something is broken or behaving incorrectly |
| Feature | Net-new functionality |
| Improvement | Enhancing existing functionality |
| Agent | Related to the AI agent system (backend/agent/) |
| Frontend | Related to the Next.js frontend |
| Tools | Related to MCP tools or LangChain tools |
Common Mistakes
- Investigating root causes or proposing fixes - this is the #1 mistake. Do NOT read source code, search for bugs, or suggest implementation approaches. That work belongs to whoever picks up the ticket.
- Writing vague acceptance criteria like "the feature works" - be specific
- Forgetting edge cases in the test plan
- Over-engineering the ticket for simple tasks - a one-line bug doesn't need 20 test cases
- Not inferring obvious labels from context (if they mention a UI issue, add Frontend)
- Creating a mega-ticket that covers multiple independent concerns - split it up
