Create Tickets Skill
Generate engineering tickets from PRDs, feature specs, or task lists. Supports direct creation via Linear MCP or formatted text output.
REQUIRED: every generated ticket must follow the
/catalyst-dev:gherkin-ticketstandard. Outcome-first title (<actor> should <outcome> [so that <benefit>], no internal-mechanism jargon, component as a label not a title prefix) + a body that opens with a plain-English use case followed by tiered Gherkin acceptance criteria. The legacy[Component] Action:title format below is superseded — see the updated Title Format and Ticket Body sections.
Quick Start
- Point me to the source: PRD, feature spec, meeting action items, or describe the work
- I break it down into well-structured tickets with acceptance criteria
- Each ticket gets an effort estimate, dependencies, and component label
- If Linear MCP is connected, I create tickets directly; otherwise, I generate copy-paste text
- I provide a dependency summary and sprint assignment suggestion
Example: "Create tickets from thoughts/shared/pm/prds/checkout-redesign.md targeting a March 15 launch"
Output: Tickets created in Linear, or saved to thoughts/shared/pm/analyses/[feature]-tickets.md
Time: 15-30 minutes depending on PRD complexity
When to Use This Skill
- Breaking down PRDs into implementation tickets
- Converting feature specs into actionable tasks
- Batch ticket creation from roadmap items
- Generating ticket text for manual entry
Prerequisites
Optional but Recommended:
- Linear MCP configured (for direct ticket creation)
Fallback:
- Generates formatted ticket text for manual copy-paste
Workflow
Step 1: Gather Context
Ask the PM:
- Source document: PRD, feature spec, or task list?
- Target system: Linear, or text output?
- Project/Team: Which project/team should receive tickets?
- Ticket type: Story, Task, Bug, Epic?
- Priority level: High, Medium, Low?
Step 2: Analyze Source Material
Read the source document and identify:
- User-facing features (frontend work)
- API/Backend work (backend work)
- Data migrations (data engineering)
- Infrastructure changes (DevOps)
- Testing requirements (QA)
- Documentation needs (docs)
Step 3: Create Ticket Structure
For each ticket, generate:
Title Format (per /catalyst-dev:gherkin-ticket — outcome-first, no [Component] prefix):
<actor> should <outcome> [when <condition>] [so that <benefit>]
The actor is whoever benefits (a user, an operator, the API, the scheduler). The component goes in a Linear label, not the title. Examples:
Users should be able to save and reload their preferences so settings persist across sessionsThe preferences API should reject an unknown user with a 404 rather than a 500Operators should see a preference-selection screen so they can configure defaults without code
Ticket Body (use case first, then tiered Gherkin, then technical detail):
[Short plain-English use case — who benefits and why — so a reader who didn't write it gets oriented.]
```gherkin
Scenario: <one specific behavior>
Given <minimum starting state>
When <the single action>
Then <observable outcome>
```
(Tier A = features/bugs full scenarios; Tier B = bugs, `Then` states correct behavior + `# CURRENTLY:`;
Tier C = pure chores, Context/Motivation/Outcome prose instead of a vacuous scenario.)
## Technical notes
[API contracts, data schemas, edge cases — preserved, but BELOW the use case]
## Dependencies
<!-- Documentation only. A real prerequisite MUST also be set as a formal Linear
blocked_by LINK (see Bulk Creation step 5) — Catalyst does not infer
dependencies from this prose (CTL-838). -->
- Blocked by: [Other ticket]
- Blocks: [Other ticket]
## Testing Requirements
- [ ] Unit tests
- [ ] Integration tests
- [ ] Manual QA steps
## Resources
- Design: [design link]
- API Spec: [Swagger/OpenAPI]
- Related PRD: [Link]
Step 4: Create or Output Tickets
If Linear MCP available:
Use Linear MCP to create issues directly
Set project, team, priority, labels
Link parent issues and sub-issues
Add components and labels
Fallback - Text Output:
Generate formatted ticket text
Number tickets sequentially
Provide copy-paste instructions
Bulk Creation
When creating 5+ tickets:
- Create Epic first (if applicable)
- Group by component (Frontend, Backend, Data, etc.)
- Order by dependency (foundation tickets first)
- Add estimates (if PM provides sizing)
- Link tickets as formal Linear blockers —
linearis issues update <ticket> --blocked-by <prereq>for each TRUE prerequisite (see/catalyst-dev:linearis). Set realblocked_byLINKS; do NOT rely on naming the dependency in the description. Catalyst does not infer dependencies from prose (CTL-838) — a "Blocked by: X" line in the body is documentation only and is never turned into a blocker. Link only genuine must-finish-first work; never link across teams for auto-sequencing (the daemon only works its own team, so a cross-team blocker deadlocks).
Effort Estimation Framework
For each ticket, include an effort estimate using T-shirt sizing:
| Size | Time | Description | Example |
|---|---|---|---|
| XS | <2 hours | Config change, copy update, simple fix | Update error message text |
| S | Half day | Single-file change, straightforward logic | Add input validation to a form |
| M | 1-2 days | Multi-file change, moderate complexity | Build a new API endpoint with tests |
| L | 3-5 days | Cross-component work, integration needed | Build complete CRUD feature with UI |
| XL | 1-2 weeks | Large scope, multiple systems involved | New authentication system |
Estimation rules:
- If the PM provides estimates, use them. If not, suggest one based on typical complexity for the work type.
- Always flag XL tickets as candidates for splitting. Suggest how to break them down: "This XL ticket could be split into [DB migration (M)] + [API layer (M)] + [Frontend (L)]."
- Include estimate in the ticket metadata, not buried in the body.
- When in doubt, round up. Underestimates erode trust; overestimates create buffer.
Alternative: Story Points
Some teams prefer story points over T-shirt sizes. If the team uses story points:
| Points | Complexity | Roughly Equivalent To |
|---|---|---|
| 1 | Trivial change, well-understood | XS (few hours) |
| 2 | Small change, minimal unknowns | S (half day - 1 day) |
| 3 | Medium change, some unknowns | M (1-2 days) |
| 5 | Significant change, moderate unknowns | L (3-5 days) |
| 8 | Large change, many unknowns | XL (1-2 weeks) |
| 13 | Very large, high uncertainty | Split this ticket |
Which to use: Ask the PM or check existing tickets in the project management tool. Default to T-shirt sizes if unknown -- they're more intuitive for non-engineers.
Ticket format with estimate:
=== TICKET 1 ===
Title: [API] Add CRUD endpoints for user preferences
Estimate: M (1-2 days)
...
Sprint/Milestone Assignment
If the PM has a target launch date, work backwards from the deadline to suggest sprint assignments.
Sprint grouping logic:
Sprint 1 (Foundation & Blockers):
- Database migrations
- API contracts and core endpoints
- Infrastructure/DevOps setup
- Tickets that block everything else
Sprint 2 (Core Functionality):
- Frontend components
- Business logic implementation
- Integration between frontend and backend
- Core user flow working end-to-end
Sprint 3 (Polish & Edge Cases):
- Error handling and edge cases
- Performance optimization
- Accessibility fixes
- Documentation and help content
- QA and testing tickets
Capacity check:
- Assume 6-8 productive hours per developer per day
- Assume 80% utilization (meetings, reviews, context-switching)
- Sum ticket estimates per sprint and compare to available developer-days
- If estimated effort exceeds sprint capacity, flag: "Sprint 2 is overloaded by ~3 days. Consider moving [ticket X] to Sprint 3 or adding capacity."
Handling Early-Stage or Partial PRDs
When the PRD is at Team Kickoff or Planning Review stage (requirements are still fuzzy):
Adjust ticket creation:
- Create "Spike" tickets for areas with high uncertainty: "[Spike] Investigate feasibility of [unclear requirement] -- Timebox: 2 days"
- Mark fuzzy requirements with a [TBD] tag: "Acceptance criteria TBD pending design review"
- Use wider T-shirt size ranges: "M-L (1-5 days) -- depends on API complexity once spike is complete"
- Add a "Requirements Checkpoint" ticket: "Review updated PRD with engineering before starting implementation"
What NOT to do:
- Don't create detailed acceptance criteria for fuzzy requirements (they'll change)
- Don't estimate with false precision (don't say "3 days" when you mean "1-2 weeks, maybe")
- Don't skip the tickets entirely -- even fuzzy work needs tracking
Flag it: Start the ticket breakdown with: "Note: PRD is at [Stage] stage. Some tickets have [TBD] acceptance criteria that will be refined as requirements solidify."
Dependency Mapping
Identify and mark dependencies between tickets. Use explicit notation in each ticket:
## Dependencies
- **Blocked by:** TICKET-3 (DB schema must exist before API can be built)
- **Blocks:** TICKET-7 (Frontend needs this API to integrate)
After generating all tickets, provide a dependency summary:
## Dependency Summary
TICKET-1 [DB Schema] --> TICKET-3 [API Endpoints] --> TICKET-5 [Frontend Integration]
TICKET-2 [Auth Setup] --> TICKET-4 [Protected Routes] --> TICKET-5 [Frontend Integration]
TICKET-5 [Frontend Integration] --> TICKET-6 [E2E Tests]
Critical path: TICKET-1 --> TICKET-3 --> TICKET-5 --> TICKET-6
Estimated critical path duration: 7-10 days
Independent tickets (can be done in parallel):
- TICKET-7 [Documentation] -- no blockers
- TICKET-8 [Analytics instrumentation] -- no blockers
Dependency rules:
- Every ticket should state its dependencies (even if "None")
- Circular dependencies are a red flag -- restructure the tickets
- If a ticket has 3+ blockers, consider whether it should be split
Ticket Quality Checklist
Before creating tickets, verify:
- ✅ Title is clear and specific
- ✅ Acceptance criteria are testable
- ✅ Technical context is sufficient for engineers
- ✅ Dependencies are identified
- ✅ Edge cases are documented
- ✅ Testing requirements are clear
- ✅ Links to designs/specs included
Common Ticket Patterns
Feature Work
Epic: User Preferences System
├── [DB] Create user_preferences table
├── [API] Add CRUD endpoints for preferences
├── [Frontend] Build preferences UI
└── [QA] Test preferences end-to-end
Bug Fixes
Title: [Component] Fix: Description of bug
Body:
- Current behavior: [What's broken]
- Expected behavior: [What should happen]
- Repro steps: [How to reproduce]
- Root cause: [If known]
Infrastructure
Title: [DevOps] Setup: Description
Body:
- Current state: [What exists]
- Desired state: [What we need]
- Migration plan: [How to get there]
- Rollback plan: [How to revert if needed]
Integration Examples
Linear MCP
# Create parent issue (epic-level)
epic = mcp__claude_ai_Linear__create_issue({
"title": "User Preferences System",
"description": "[Epic description]",
"teamId": "team_id",
"priority": 1
})
# Create child issues
for ticket in tickets:
mcp__claude_ai_Linear__create_issue({
"title": ticket.title,
"description": ticket.body,
"teamId": "team_id",
"parentId": epic.id,
"priority": ticket.priority,
"labelIds": ticket.labels
})
Pro Tips
- One ticket, one thing: Avoid "also do X" tickets
- Size appropriately: 1-3 days ideal, split if larger
- Clear acceptance criteria: Engineers know when done
- Link liberally: PRDs, designs, related tickets
- Front-load context: Engineers shouldn't hunt for info
- Call out edge cases: "What happens if X?"
- Include examples: API requests, UI states, data samples
Output Format (Text Fallback)
=== TICKET 1 ===
Title: [Component] Action: Description
Project: [Project Name]
Type: Story
Priority: Medium
[Full ticket body]
=== TICKET 2 ===
...
Common Mistakes to Avoid
❌ Mechanism/vague titles: "Fix preferences" / "[API] Fix preferences endpoint" ✅ Outcome titles: "The preferences API should return 404 (not 500) when the user doesn't exist"
❌ No acceptance criteria ✅ Clear checklist of outcomes
❌ Missing dependencies ✅ "Blocked by PROJ-123, Blocks PROJ-125"
❌ No technical context ✅ API contracts, data schemas, edge cases documented
❌ Orphan tickets (no epic/parent) ✅ Linked to parent epic or PRD
Questions to Ask Before Creating
- Scope clarity: Is this ticket too big/small?
- Dependencies clear: What must happen first?
- Edge cases documented: What could go wrong?
- Testing defined: How will we verify this works?
- Rollback plan: Can we undo if needed?
Remember: Great tickets save engineering hours. Invest time upfront to create clear, actionable work items.
Context Routing Strategy
When the PM uses /create-tickets, I automatically:
1. Extract Source Material Understanding
Source: PRDs in thoughts/shared/pm/prds/, or uploaded documents
- What I look for: Acceptance criteria, technical requirements, design context
- How I use it: Generate detailed tickets with full context
- Example: "PRD says 'mobile-first', I'll note that in every ticket's technical notes"
2. Query Project Management MCPs
Source: Linear MCP (if connected)
- What I look for: Existing projects, issue structure, team assignments
- How I use it: Auto-link issues to correct parent, assign to right teams
- Example: "Project 'Voice Feature' exists, I'll link all issues to it automatically"
3. Check Dependencies Across Roadmap
Source: thoughts/shared/pm/prds/, related PRDs
- What I look for: What else is being built that might block this
- How I use it: Surface dependency tickets
- Example: "Notification system ships next sprint, Voice Feature depends on it"
4. Extract Acceptance Criteria from Success Metrics
Source: PRDs, /feature-metrics or /impact-sizing outputs
- What I look for: Testable success criteria
- How I use it: Convert metrics into ticket acceptance criteria
- Example: "Success metric 'adoption >60%' → AC: Feature instrumented to track adoption"
5. Route to Task/Ticket System
Routing logic:
- Linear MCP connected: Create issues directly in Linear via
mcp__claude_ai_Linear__create_issue - Not connected: Generate formatted ticket text for manual entry
- Complex dependencies: Suggest ticket structure first before creation
Output Quality Self-Check
Before delivering tickets, verify:
- Every ticket has an outcome-first title -- per
/catalyst-dev:gherkin-ticket(<actor> should <outcome>), no[Component]prefix, no internal-mechanism jargon, no vague titles like "Fix stuff" - Every ticket body opens with a use case + tiered Gherkin -- plain-English context first, then
Given/When/Thenacceptance criteria - Every ticket has testable acceptance criteria -- At least 2-3 checkboxes that define "done"
- Every ticket has an effort estimate -- T-shirt size (XS/S/M/L/XL) assigned to each
- XL tickets flagged for splitting -- Any ticket estimated at 1-2 weeks has a suggested breakdown
- Dependencies mapped -- "Blocked by" and "Blocks" noted; dependency summary provided at the end
- Sprint/milestone assignment suggested -- If launch date provided, tickets grouped into Sprint 1/2/3
- Capacity checked -- If sprint assignments given, total effort compared to available developer-days
- Critical path identified -- Longest dependency chain highlighted with duration estimate
- PRD requirements fully covered -- Every PRD acceptance criterion maps to at least one ticket
- No orphan tickets -- All tickets linked to parent epic or PRD
- Technical context sufficient -- Engineers should not need to ask "what exactly do you want?" after reading the ticket
If any check fails, fix it before delivering. Bad tickets slow engineering down more than no tickets at all.