Writes ready-to-build Jira stories with user-story summaries, Given/When/Then acceptance criteria, subtasks, and story-point guidance, checked against INVEST and a Definition of Ready. Use when someone asks "write a Jira ticket for this", "turn these meeting notes into a story", "are these acceptance criteria testable", "should I split this story", or "how many points is this". Do NOT use for configuring Linear teams, cycles, labels, or triage workflows - use linear-workflow instead. For deciding what fits in the sprint, use sprint-planning.
Click to play with sound.
---
name: Jira Ticket Writer
description: Writes ready-to-build Jira stories with user-story summaries, Given/When/Then acceptance criteria, subtasks, and story-point guidance, checked against INVEST and a Definition of Ready. Use when someone asks "write a Jira ticket for this", "turn these meeting notes into a story", "are these acceptance criteria testable", "should I split this story", or "how many points is this". Do NOT use for configuring Linear teams, cycles, labels, or triage workflows - use linear-workflow instead. For deciding what fits in the sprint, use sprint-planning.
---
# Jira Ticket Writer
A good ticket is understandable by someone who was not in the conversation. The costly failure mode is the "fix the thing" ticket: it looks fine the day it is written, then a week later nobody can build it, estimate it, or verify it, and the sprint absorbs a re-discovery meeting that the ticket was supposed to replace. This skill produces stories that are ready to estimate and build on first read.
## Operating procedure
Follow the steps in order: the summary shapes the acceptance criteria, the criteria expose the edge cases, and the edge cases decide whether the story needs splitting. Estimating before the criteria exist produces numbers nobody can defend.
### Step 1: Gather inputs
Collect these before drafting. Where the requester does not know, record the best guess and label it a guess.
1. Who the user is (a real role - "billing admin", not "user").
2. The problem and why now - the source conversation, incident, or request to link.
3. The desired behavior in one sentence.
4. Known edge cases: empty states, error paths, permission boundaries.
5. Links to designs, API contracts, or prior decisions, if any exist.
6. What is explicitly NOT included, if the requester has said so.
### Step 2: Draft the summary as a user story… install to load the full skill