| name | jira-story-creator |
| description | Use this skill when the user wants to plan and create engineering-ready stories directly in Jira. Trigger on: 'create jira stories', 'push stories to jira', 'write stories for this epic', 'create stories under [epic key]', 'make jira tickets for this feature', or any combination of story/ticket creation intent with a Jira destination. Also trigger when the user shares a feature brief, PRD, or Jira epic and asks to 'break it down into tickets', 'generate stories', or 'create the backlog'. Do NOT trigger for story generation to documents — use user-story-writer for .docx or .md output. |
| argument-hint | [feature description, PRD text, or Jira epic key/URL] |
Jira Story Creator
Overview
This skill takes any planning input and creates fully structured, engineering-ready stories directly in Jira via the Atlassian MCP. It runs in 4 phases: context gathering, story generation, review, and Jira creation.
Phase 1: Context Gathering
Accept any of the following as input — alone or in combination:
- Free-text feature description or brief
- Pasted PRD or BRD content
- A Jira epic key (e.g.,
DLRUSER-123) or URL
- A combination of the above
If a Jira epic key or URL is provided:
- Extract the epic key from the URL if needed (format:
PROJECT-123)
- Call
getJiraIssue with the epic key to fetch the epic title, description, and any existing context
- Use this as the primary source of truth for what to build
Ask only for what is clearly missing. You need at minimum:
- What the feature or product is
- Who the users/personas are (needed for "As a [user]..." story format)
- What core actions the user should be able to perform
If the user says "just go" or "proceed with what you have", mark any inferences as [Assumption: ...] and continue. Every assumption made in this phase must be carried forward and displayed in the Phase 3 review summary.
Jira project inference (follow this order strictly):
- If an epic key is provided, extract the project from its prefix (e.g.,
DLRUSER-123 → project DLRUSER)
- If input is free-text only, ask the user to explicitly confirm the target Jira project key before Phase 4 — never infer silently
- After the first story is created, if it lands in the wrong project, flag this immediately and ask whether to continue or abort
Phase 2: Story Generation
Draft all stories using the field template below. For each story:
- Write one story per distinct user action or behaviour
- Do not combine multiple behaviours into a single story
- Be specific — "As a dealer, I want to filter my inventory by make and model" not "As a user, I want to filter"
- Mark any inference not provided by the user as
[Assumption: ...]
- Mark any section you cannot complete due to missing context as
[Needs input from engineering]
- Omit sections that genuinely do not apply — do not leave blank headings
Story Format
Use this structure for every story:
[PREFIX-NNN] Story title
Story: As a [specific persona], I want [specific action], so that [clear benefit].
Description
[2–3 sentences: what this story delivers, why it matters, what system/flow it belongs to]
Acceptance Criteria
- Given [precondition], When [action], Then [outcome].
- Given [precondition], When [action], Then [outcome].
Test Cases
- [Happy path: normal use, expected result]
- [Edge case: boundary or unusual input]
- [Failure case: what happens when something goes wrong]
Engineering Approach
[Suggested technical implementation. Mark as [Assumption] if speculative. Skip if no context is available.]
Functional Requirements
- [What the system must do — specific and testable]
- [Another requirement]
Non-Functional Requirements
- [Performance, accessibility, security, or compatibility constraints — only where relevant]
Data Requirements
- [New fields, schema changes, API dependencies — omit if none]
Instrumentation
- [Google Analytics events, tracking calls — only for user-facing interactions. Format:
event_name on trigger. Omit if not applicable.]
Engineering Instructions
- [Step-by-step dev guidance — specific enough to act on]
- [Next step]
Rollout Considerations
- [Feature flags, phased rollout, story dependencies, migration concerns — omit if none]
Story ID Convention
Use a short prefix derived from the feature or epic name:
DLRUSER epic → prefix DUDLRINV epic → prefix DI- Free-text feature → derive a 2–3 letter prefix from the feature name, confirm with user
Number sequentially: DU-001, DU-002, etc.
Phase 3: Review Gate
Present a numbered summary list of all stories — title and one-line description only. Follow it with a consolidated list of all [Assumption: ...] tags made in Phases 1 and 2.
Example format:
Stories to create (8 total):
1. DU-001 — Filter inventory by make/model: Dealer can narrow their stock list using dropdowns
2. DU-002 — Save filter preferences: System remembers the dealer's last-used filters
...
Assumptions made:
- [Assumption: Engineering will use the existing filter component from the search page]
- [Assumption: GA event name follows the existing `dealer_action_` prefix convention]
What would you like to do?
a) Approve all and create in Jira
b) Revise specific stories (tell me which ones and what to change)
c) Skip certain stories (tell me which ones)
d) Just create them (skip this review)
If the user chooses to revise specific stories:
- Ask them to specify which stories and what to change
- Regenerate only those stories (loop back through Phase 2 for just those stories)
- Re-present the full updated summary list
- Repeat until the user approves
If the user says "just create them" or equivalent:
- Proceed directly to Phase 4 without further confirmation
Phase 4: Jira Creation
Duplicate Check
Before creating any stories, if a target epic is provided, run a duplicate check:
searchJiraIssuesUsingJql: project = [PROJECT] AND "Epic Link" = [EPIC_KEY] ORDER BY created DESC
If stories with identical or very similar titles exist, list them and ask the user whether to proceed.
Epic Handling
If an epic was provided: link stories to it using the method below.
If no epic exists and the user wants one:
- Create the epic first:
createJiraIssue with issuetype: Epic, summary: [Epic title], project: [PROJECT]
- Note the returned epic key, then link all stories to it
If no epic exists and the user wants stories unlinked: proceed without a parent.
Creating Each Story
For each approved story, call createJiraIssue with these fields:
summary: [story title]
issuetype: { name: "Story" }
project: { key: "[PROJECT]" }
description: [ADF-formatted content — see Jira Field Template section]
parent: { key: "[EPIC_KEY]" } ← attempt this first
Epic link fallback: If parent fails (Classic project), retry with:
customfield_10014: "[EPIC_KEY]"
Note which method succeeded for the rest of the batch.
After each story is created, output:
✓ [ISSUE_KEY] — [Story title]
If creation fails, output:
✗ [Story title] — [error message] (skipped, will retry at end)
Continue with remaining stories.
End Summary
After all stories are attempted:
Created X of Y stories:
✓ DLRUSER-456 — Filter inventory by make/model
✓ DLRUSER-457 — Save filter preferences
✗ DU-003 — Export filtered list (failed: [reason]) ← retry? y/n
Offer retry for any failed stories.
Jira Field Template
All story content is packed into the description field using Atlassian Document Format (ADF). Structure each story description as a series of H2 headings with content beneath each.
| Section | Jira Field | Required? |
|---|
| Story title | summary | Always |
| Issue type | issuetype: Story | Always |
| Project | project.key | Always |
| Epic link | parent.key or customfield_10014 | If epic exists |
| Description | H2 in description (ADF) | Always |
| Acceptance Criteria | H2 in description (ADF) | Always |
| Test Cases | H2 in description (ADF) | Always |
| Engineering Approach | H2 in description (ADF) | If context available |
| Functional Requirements | H2 in description (ADF) | Always |
| Non-Functional Requirements | H2 in description (ADF) | If relevant |
| Data Requirements | H2 in description (ADF) | If relevant |
| Instrumentation | H2 in description (ADF) | User-facing interactions only |
| Engineering Instructions | H2 in description (ADF) | Always |
| Rollout Considerations | H2 in description (ADF) | If relevant |
Omit sections marked "If relevant" when they genuinely don't apply. Mark sections marked "If context available" as [Needs input from engineering] rather than omitting them entirely.
Error Handling
| Scenario | Response |
|---|
| Missing persona or core user actions | Ask before proceeding. If user says "just go", mark as [Assumption] |
Epic key not found (getJiraIssue returns 404) | Surface error clearly, offer: create new epic / proceed unlinked / provide different key |
| Jira creation fails for a story | Log the failure with reason, skip, continue, offer retry in end summary |
| Session interrupted mid-creation | On resumption, show which stories were created (with keys) and which are pending |
| User skips review gate | Proceed directly to Phase 4, output full creation summary at end |
| Duplicate stories detected | List matching story keys and titles, ask whether to proceed before creating |
| Wrong project inferred | Flag after first creation, ask whether to continue or abort batch |
