Menu
Quickly create or update a Jira issue without breaking flow
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | create-jira-issue |
| description | Quickly create or update a Jira issue without breaking flow |
| argument-hint | [feature description, bug report, or improvement idea] |
User is mid-development and thought of a bug/feature/improvement. Capture it fast so they can keep working.
IMPORTANT: Use the user's natural language, inferred from their first input or the Jira project context. If you are unsure, ask them which language they prefer.
Create a complete Jira issue with:
Set the appropriate priority and type. If it's a sub-task or part of an epic, link it correctly.
Ask questions to fill gaps – be concise, respect the user's time. They're mid-flow and want to capture this quickly. Usually need:
Keep questions brief. One message with 2-3 targeted questions beats multiple back-and-forths.
Search for context only when helpful:
Skip what's obvious - If it's a straightforward bug, don't search web. If type/priority is clear from description, don't ask.
Split if complex - If the issue is large or too complex, break it into multiple smaller, focused issues. Create each one separately.
Draft the issue - Produce a clear, concise issue description with all relevant details. Important: always include a Definition of Done section with checkboxes. Definition of Done section does NOT contain a list of implementation steps. It contains all acceptance criteria that must be met for the issue to be considered complete.
Create the issue in Jira - Share the draft with the user for confirmation before creating. Important: always confirm the draft with the user before creating the issue. Use the Atlassian Jira CLI (acli) to create the issue in the correct project with all the details.
NEVER CODE! Just research and write the plan.
Title: [Clear, concise title summarizing the issue]
Summary:
- [Detailed description of the issue, current vs desired behavior, any relevant context or steps to reproduce]
Definition of Done:
- [ ] [Acceptance criterion 1]
- [ ] [Acceptance criterion 2]
- [ ] [Acceptance criterion 3]
- [ ] [Acceptance criterion 4]
- [ ] [Acceptance criterion 5]
Create and update a structured Design Review / Software Requirements Specification (DR/SRS). Use whenever a user asks for a Design Review, DR, SRS, solution design, technical requirements document, architecture review, or to turn an accepted RFC into the operational design. Write Markdown first, preserve stable IDs, expose gaps without inventing decisions, invoke uc-engraver when detailed Use Cases are requested, and hand confirmed Confluence publication to the confluence-librarian skill.
Project approved DR/SRS and Use Case contracts into a reviewable Jira backlog. Use whenever a user asks to create, decompose, refine, synchronize, or update Jira Epics, User Stories, or technical Tasks from a PRD, DR/SRS, Use Case, JTBD, acceptance check, RFC, or requirements document. Propose multiple cohesive Epics that fit a few sprints, write actor-facing Stories sized for one two-week sprint, separate enabling work into Tasks, preserve source traceability, and require explicit confirmation before Jira mutations.
Create and update structured Use Case child documents for a parent Design Review / Software Requirements Specification (DR/SRS). Use whenever a user asks to define, write, refine, synchronize, or publish a Use Case, UC, scenario, acceptance checks, or detailed behavior from a PRD, DR/SRS, JTBD, Service Blueprint, Figma, RFC, contract, or task intake. Preserve stable UC/AC IDs, reuse actor names exactly from the linked PRD, expose gaps without inventing behavior, update and verify the parent DR/SRS catalog, and hand confirmed Confluence publication to confluence-librarian.
Publish and update prepared pages and document artifacts in Confluence without losing structure or traceability. Use whenever a user asks to publish, create, update, translate, or synchronize Markdown, HTML, or another readable document to Confluence, including hierarchical child pages under a parent catalog. Require explicit confirmation before irreversible publication and preserve headings, tables, links, statuses, IDs, and intentional gaps.
Write and update a structured Product Requirements Document (PRD) from gathered product material. Use when a product manager wants to turn discovery notes, meeting summaries, strategy input, or a rough product document into a Confluence-compatible PRD covering needs, actors, JTBD, goals, metrics, guardrails, dependencies, constraints, feasibility red flags, design discovery, open questions, and support readiness. Preserve stable English IDs, manage explicit draft-to-review readiness, and offer optional Confluence publication only after writing.
Build or extend backend tests for Node.js/TypeScript services with real runtimes, Testcontainers dependencies, optional .env.test cloud services, and integration and/or record-replay coverage. Use for integration tests, live contracts, freeze-before-refactor, VCR/golden-master, cassette record/verify, Azure Functions harnesses, replacing mock-heavy tests, or adding scenarios to an existing backend-test harness. Always use when choosing between integration and record-replay.