← Back to catalog

▸jira-task-creator

redickowii☍ owners: @redickowii
METADATA
namejira-task-creator
descriptionCreates a well-structured Jira issue from a free-form description. Turns a one-line ask or a messy note into a proper task — title, type, the standard description template, labels, component, epic link — then creates it via the jira-cli skill. Use when the user says "создай задачу", "заведи тикет", "new jira task", or pastes raw requirements to file. Works with any Jira project.
licenseMIT
tags
jiraproductivity
owners
redickowii
metadata{"author":"redickowii","version":"1.0"}
SKILL.MD

Jira Task Creator

Turn a free-form request into a structured Jira issue and create it. Pairs with jira-task-formatter (same template) — this skill creates, the formatter cleans existing tasks. Both reuse the jira-cli skill for Jira access.

##Trigger

User invokes /jira-task-creator, or asks to create / «создать», «завести» a task and gives a description. Works with any project — the project key comes from the user, the active jira-cli config, or is asked.

##Workflow

###1. Gather inputs

From the user's message extract: project key (or default project), summary, issue type, target epic/parent, labels, component, priority, assignee. Ask only for what is missing and required to create — never block on optional fields.

Minimum to create: project, issue type, summary. Everything else can be filled or left empty.

###2. Draft the structured description

Build the body with the same template as jira-task-formatter (Бизнес цель, Техническое описание, API for handler tasks, Out of scope/Риски, Нефункциональные требования, Критерии приёмки, DoD, Как тестировать).

  • Reuse the user's wording; do not invent business logic or acceptance criteria. Unknown fields → {TODO: <что нужно>}.
  • Classify handler vs non-handler (route/METHOD/payload present → handler → include API block; else omit).
  • Body markup follows the deployment: Jira Server/DC → wiki markup; Jira Cloud → Markdown (see the jira-task-formatter skill, "Markup" section).

###3. Confirm before creating

Show the assembled fields + rendered description, then ask:

Создать задачу в проекте <PROJECT> с этим описанием? (да / нет)

Print a "⚠ Пробелы" list of every {TODO} so the user can fill them first. Default answer is no — never create without an explicit yes.

###4. Create via jira-cli

On yes, write the body to a temp file (Windows: avoid stdin) and run:

code
jira issue create -p<PROJECT> -t<TYPE> -s"<summary>" --no-input \
  -b "$(cat <tempfile>)" \
  [-y<priority>] [-l<label>]... [-C<component>] [-P<EPIC-KEY>] [-a<assignee>]

Feed < /dev/null to stop jira-cli hanging on a prompt.

###5. Verify and report

Capture the returned key. Re-fetch to confirm it exists and the description took:

jira issue view <NEW-KEY> --raw

jira-cli sometimes reports success while a field stayed empty — if the description is blank, follow up with jira issue edit <NEW-KEY> -b .... Delete the temp file. Report the key + URL to the user.

##Rules

  • Caveman-mode does NOT apply to the generated task body — write it in normal, full prose (Russian by default).
  • Never invent acceptance criteria, API contracts, or business goals — gaps stay as {TODO} and surface in the "⚠ Пробелы" list.
  • Never create without explicit confirmation; default is no.
  • Quoted JSON, error codes, URLs from the source stay byte-exact.
  • For batch creation, confirm and create one issue at a time; report each key.