
Jira Ticket Creator
- 1 installs
- 27 repo stars
- Updated April 25, 2026
- girijashankarj/cursor-handbook
Generates structured JIRA tickets (stories, bugs, tasks, epics) with acceptance criteria, estimates, and labels from requirements.
About
Produces well-structured JIRA-compatible tickets from requirements, bug reports, or feature requests. A developer uses it to write stories, document bugs, or break down work into trackable items.
- Picks the right ticket type from a decision table
- Includes acceptance criteria, priority, and components
Jira Ticket Creator by the numbers
- 1 all-time installs (skills.sh)
- Ranked #2,476 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Jul 22, 2026 (Skillselion catalog sync)
npx skills add https://github.com/girijashankarj/cursor-handbook --skill jira-ticket-creatorAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 27 |
| Last updated | April 25, 2026 |
| Repository | girijashankarj/cursor-handbook ↗ |
What it does
Generates structured JIRA tickets (stories, bugs, tasks, epics) with acceptance criteria, estimates, and labels from requirements.
Files
Skill: JIRA Ticket Creator
Generate structured JIRA-compatible tickets from requirements, bug reports, or feature requests.
Trigger
When the user asks to create a JIRA ticket, write a user story, document a bug, or break down work into trackable items.
Prerequisites
- [ ] Clear understanding of the request (feature, bug, task, or epic)
- [ ] Project key or naming convention known (ask if not provided)
Steps
Step 1: Identify Ticket Type
| Type | When to Use |
|---|---|
| Epic | Large feature spanning multiple sprints |
| Story | User-facing functionality deliverable in one sprint |
| Task | Technical work not directly user-facing |
| Bug | Defect in existing functionality |
| Sub-task | Breakdown of a Story or Task |
| Spike | Research or investigation with time-box |
Step 2: Gather Context
- [ ] What problem does this solve? (the why)
- [ ] Who is affected? (user persona or system)
- [ ] What is the desired outcome?
- [ ] What is the current behavior? (for bugs)
- [ ] Priority: Critical / High / Medium / Low
- [ ] Affected components or services
Step 3: Write Title
- [ ] Format:
[Type] Concise action-oriented description - [ ] Use imperative mood for stories/tasks: "Add...", "Implement...", "Fix..."
- [ ] Keep under 80 characters
- [ ] Be specific — avoid vague titles like "Update backend"
Step 4: Write Description
For Stories
## User Story
As a [persona], I want to [action] so that [benefit].
## Context
Background information, links to designs, related tickets.
## Acceptance Criteria
- [ ] Given [precondition], when [action], then [expected result]
- [ ] Given [precondition], when [action], then [expected result]
- [ ] Edge case: [scenario] → [expected behavior]
## Technical Notes
- Affected services: [list]
- Database changes: Yes/No
- API changes: Yes/No
- Feature flag: [flag name] (if applicable)
## Out of Scope
- [Explicitly list what this ticket does NOT cover]For Bugs
## Bug Summary
One sentence describing the defect.
## Steps to Reproduce
1. Navigate to [page/endpoint]
2. Perform [action]
3. Observe [incorrect behavior]
## Expected Behavior
What should happen.
## Actual Behavior
What actually happens (include error messages, status codes).
## Environment
- Environment: [dev/staging/production]
- Browser/Client: [if applicable]
- Version/Commit: [if known]
## Impact
- Severity: [Critical/High/Medium/Low]
- Users affected: [count or scope]
- Workaround available: Yes/No
## Logs / Screenshots
[Attach or paste relevant logs — redact PII]For Tasks
## Objective
What needs to be accomplished.
## Requirements
- [ ] Requirement 1
- [ ] Requirement 2
## Approach
Suggested technical approach (optional).
## Done Criteria
- [ ] Implementation complete
- [ ] Tests added (≥{{CONFIG.testing.coverageMinimum}}% coverage)
- [ ] Documentation updated
- [ ] Code reviewedFor Epics
## Vision
High-level goal and business value.
## Scope
What's included in this epic.
## Stories
- [ ] Story 1: [title]
- [ ] Story 2: [title]
- [ ] Story 3: [title]
## Success Metrics
- [Metric 1]: [target]
- [Metric 2]: [target]
## Timeline
- Start: [date]
- Target completion: [date]Step 5: Add Metadata
- [ ] Priority: Critical / High / Medium / Low
- [ ] Labels:
backend,frontend,infrastructure,security,tech-debt,breaking-change - [ ] Components: Affected service or module names
- [ ] Story Points / Estimate: Use team's scale (Fibonacci: 1, 2, 3, 5, 8, 13)
- [ ] Sprint: Current or backlog
- [ ] Linked tickets: Blocks, is blocked by, relates to
Step 6: Estimate Complexity
| Points | Meaning |
|---|---|
| 1 | Trivial — config change, typo fix |
| 2 | Small — single file, well-understood change |
| 3 | Medium — few files, some design decisions |
| 5 | Large — multiple files, integration work |
| 8 | Complex — cross-service, new patterns |
| 13 | Very complex — significant unknowns, suggest spike first |
Step 7: Review & Output
- [ ] Verify no PII, secrets, or internal infrastructure names
- [ ] Verify acceptance criteria are testable and specific
- [ ] Verify title is clear and actionable
- [ ] Present the complete ticket in a copyable format
Rules
- ALWAYS include acceptance criteria for stories
- ALWAYS include steps to reproduce for bugs
- NEVER include secrets, real credentials, or PII in ticket text
- NEVER use vague acceptance criteria ("it should work well")
- Acceptance criteria must be binary (pass/fail), not subjective
- One ticket = one deliverable; split if it exceeds 8 story points
Completion
Ready-to-paste JIRA ticket content with title, description, acceptance criteria, metadata, and estimate.
If a Step Fails
- Unclear requirements: Ask clarifying questions before generating; list assumptions explicitly
- Too large for one ticket: Break into an epic with child stories
- No reproduction steps (bug): Mark as "Needs investigation" and suggest a spike ticket
- Can't estimate: Suggest a time-boxed spike (2–4 hours) to reduce unknowns