jira-ticket-creator
starsforks
How to install jira-ticket-creator?
girijashankarj/cursor-handbook/jira-ticket-creator
$npx -y skills add girijashankarj/cursor-handbook --skill jira-ticket-creatorGenerate well-structured JIRA tickets (stories, bugs, tasks, epics) with acceptance criteria, estimates, and labels. Use when the user asks to create a JIRA ticket, write a story, or document a bug report.
SKILL.md
| 1 | # Skill: JIRA Ticket Creator |
| 2 | |
| 3 | Generate structured JIRA-compatible tickets from requirements, bug reports, or feature requests. |
| 4 | |
| 5 | ## Trigger |
| 6 | When the user asks to create a JIRA ticket, write a user story, document a bug, or break down work into trackable items. |
| 7 | |
| 8 | ## Prerequisites |
| 9 | - [ ] Clear understanding of the request (feature, bug, task, or epic) |
| 10 | - [ ] Project key or naming convention known (ask if not provided) |
| 11 | |
| 12 | ## Steps |
| 13 | |
| 14 | ### Step 1: Identify Ticket Type |
| 15 | |
| 16 | | Type | When to Use | |
| 17 | |------|-------------| |
| 18 | | **Epic** | Large feature spanning multiple sprints | |
| 19 | | **Story** | User-facing functionality deliverable in one sprint | |
| 20 | | **Task** | Technical work not directly user-facing | |
| 21 | | **Bug** | Defect in existing functionality | |
| 22 | | **Sub-task** | Breakdown of a Story or Task | |
| 23 | | **Spike** | Research or investigation with time-box | |
| 24 | |
| 25 | ### Step 2: Gather Context |
| 26 | - [ ] What problem does this solve? (the **why**) |
| 27 | - [ ] Who is affected? (user persona or system) |
| 28 | - [ ] What is the desired outcome? |
| 29 | - [ ] What is the current behavior? (for bugs) |
| 30 | - [ ] Priority: Critical / High / Medium / Low |
| 31 | - [ ] Affected components or services |
| 32 | |
| 33 | ### Step 3: Write Title |
| 34 | - [ ] Format: `[Type] Concise action-oriented description` |
| 35 | - [ ] Use imperative mood for stories/tasks: "Add...", "Implement...", "Fix..." |
| 36 | - [ ] Keep under 80 characters |
| 37 | - [ ] Be specific — avoid vague titles like "Update backend" |
| 38 | |
| 39 | ### Step 4: Write Description |
| 40 | |
| 41 | #### For Stories |
| 42 | ```markdown |
| 43 | ## User Story |
| 44 | As a [persona], I want to [action] so that [benefit]. |
| 45 | |
| 46 | ## Context |
| 47 | Background information, links to designs, related tickets. |
| 48 | |
| 49 | ## Acceptance Criteria |
| 50 | - [ ] Given [precondition], when [action], then [expected result] |
| 51 | - [ ] Given [precondition], when [action], then [expected result] |
| 52 | - [ ] Edge case: [scenario] → [expected behavior] |
| 53 | |
| 54 | ## Technical Notes |
| 55 | - Affected services: [list] |
| 56 | - Database changes: Yes/No |
| 57 | - API changes: Yes/No |
| 58 | - Feature flag: [flag name] (if applicable) |
| 59 | |
| 60 | ## Out of Scope |
| 61 | - [Explicitly list what this ticket does NOT cover] |
| 62 | ``` |
| 63 | |
| 64 | #### For Bugs |
| 65 | ```markdown |
| 66 | ## Bug Summary |
| 67 | One sentence describing the defect. |
| 68 | |
| 69 | ## Steps to Reproduce |
| 70 | 1. Navigate to [page/endpoint] |
| 71 | 2. Perform [action] |
| 72 | 3. Observe [incorrect behavior] |
| 73 | |
| 74 | ## Expected Behavior |
| 75 | What should happen. |
| 76 | |
| 77 | ## Actual Behavior |
| 78 | What actually happens (include error messages, status codes). |
| 79 | |
| 80 | ## Environment |
| 81 | - Environment: [dev/staging/production] |
| 82 | - Browser/Client: [if applicable] |
| 83 | - Version/Commit: [if known] |
| 84 | |
| 85 | ## Impact |
| 86 | - Severity: [Critical/High/Medium/Low] |
| 87 | - Users affected: [count or scope] |
| 88 | - Workaround available: Yes/No |
| 89 | |
| 90 | ## Logs / Screenshots |
| 91 | [Attach or paste relevant logs — redact PII] |
| 92 | ``` |
| 93 | |
| 94 | #### For Tasks |
| 95 | ```markdown |
| 96 | ## Objective |
| 97 | What needs to be accomplished. |
| 98 | |
| 99 | ## Requirements |
| 100 | - [ ] Requirement 1 |
| 101 | - [ ] Requirement 2 |
| 102 | |
| 103 | ## Approach |
| 104 | Suggested technical approach (optional). |
| 105 | |
| 106 | ## Done Criteria |
| 107 | - [ ] Implementation complete |
| 108 | - [ ] Tests added (≥{{CONFIG.testing.coverageMinimum}}% coverage) |
| 109 | - [ ] Documentation updated |
| 110 | - [ ] Code reviewed |
| 111 | ``` |
| 112 | |
| 113 | #### For Epics |
| 114 | ```markdown |
| 115 | ## Vision |
| 116 | High-level goal and business value. |
| 117 | |
| 118 | ## Scope |
| 119 | What's included in this epic. |
| 120 | |
| 121 | ## Stories |
| 122 | - [ ] Story 1: [title] |
| 123 | - [ ] Story 2: [title] |
| 124 | - [ ] Story 3: [title] |
| 125 | |
| 126 | ## Success Metrics |
| 127 | - [Metric 1]: [target] |
| 128 | - [Metric 2]: [target] |
| 129 | |
| 130 | ## Timeline |
| 131 | - Start: [date] |
| 132 | - Target completion: [date] |
| 133 | ``` |
| 134 | |
| 135 | ### Step 5: Add Metadata |
| 136 | - [ ] **Priority:** Critical / High / Medium / Low |
| 137 | - [ ] **Labels:** `backend`, `frontend`, `infrastructure`, `security`, `tech-debt`, `breaking-change` |
| 138 | - [ ] **Components:** Affected service or module names |
| 139 | - [ ] **Story Points / Estimate:** Use team's scale (Fibonacci: 1, 2, 3, 5, 8, 13) |
| 140 | - [ ] **Sprint:** Current or backlog |
| 141 | - [ ] **Linked tickets:** Blocks, is blocked by, relates to |
| 142 | |
| 143 | ### Step 6: Estimate Complexity |
| 144 | |
| 145 | | Points | Meaning | |
| 146 | |--------|---------| |
| 147 | | 1 | Trivial — config change, typo fix | |
| 148 | | 2 | Small — single file, well-understood change | |
| 149 | | 3 | Medium — few files, some design decisions | |
| 150 | | 5 | Large — multiple files, integration work | |
| 151 | | 8 | Complex — cross-service, new patterns | |
| 152 | | 13 | Very complex — significant unknowns, suggest spike first | |
| 153 | |
| 154 | ### Step 7: Review & Output |
| 155 | - [ ] Verify no PII, secrets, or internal infrastructure names |
| 156 | - [ ] Verify acceptance criteria are testable and specific |
| 157 | - [ ] Verify title is clear and actionable |
| 158 | - [ ] Present the complete ticket in a copyable format |
| 159 | |
| 160 | ## Rules |
| 161 | - **ALWAYS** include acceptance criteria for stories |
| 162 | - **ALWAYS** include steps to reproduce for bugs |
| 163 | - **NEVER** include secrets, real credentials, or PII in ticket text |
| 164 | - **NEVER** use vague acceptance criteria ("it should work well") |
| 165 | - Acceptance criteria must be binary (pass/fail), not subjective |
| 166 | - One ticket = one deliverable; split if it exceeds 8 story points |
| 167 | |
| 168 | ## Completion |
| 169 | Ready-to-paste JI |
People who liked this also viewed
6 picksType
- paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026
- subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026
- dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026
- browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 2026
- wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 2026
- wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 2026
