Create Jira Task

Jira Task Creator

Workflow

1. Determine type — Task or Bug. If user says "bug" → Bug. Otherwise → Task.
2. Gather info — Ask for description if not provided. Ask clarifying questions if requirements are ambiguous (see rules below).
3. Show preview — Display the formatted task in chat as markdown.
4. Get confirmation — Wait for explicit "ok" from user.
5. Create in Jira — Use Jira MCP tools. Cloud ID: 9e57008d-3b99-45ed-92da-1cdc13da4ea7. Project: SCRUM (My software team). Issue type: Task or Bug.

Project

All tasks and bugs are created in project SCRUM (My software team). Don't ask for project.

Writing Rules

• Informational style (Zinsser): no filler, no fluff. Every sentence carries meaning.
• No drama: don't add "critical", "important", "urgent" unless the user explicitly said so.
• English B2: simple, clear English for non-native speakers. Short sentences. Active voice.
• Ask if unclear: if requirements are ambiguous — ask, don't guess.

Task Template

Summary (Jira title)

Short, descriptive. Format: [Feature Area] Brief description

Description (Jira body)

Use this exact structure in the description field (markdown format — Jira API converts it automatically):

## Customer Problem

[1-3 sentences. What problem does the customer face? No adjectives, just facts.]

## Solution

[If design link provided, put it first as a link]

[Describe what needs to be built. Bullet points for discrete items. Keep it dry and factual.]

## Acceptance Criteria

| # | Criteria |
|---|----------|
| AC1 | [Criterion from developer perspective] |
| AC2 | [Criterion from developer perspective] |
| AC3 | [...] |

---

Bug Template

Summary (Jira title)

Short, descriptive. Format: [Feature Area] Brief description of the bug

Description (Jira body)

Use this exact structure in the description field (markdown format):

## Problem

[Describe what's wrong. What the user sees, what's unexpected. Include links to examples (playground, production) if available. Facts only, no guesses.]

## Acceptance Criteria

| # | Criteria |
|---|----------|
| AC1 | [What should be true after the fix] |
| AC2 | [What should be true after the fix] |

Bug Rules

• Project: SCRUM
• Issue type: Bug
• Don't add Solution — that's the developer's job
• If there's a link to an example (playground, production) — always include in Problem
• AC: what should be true after the fix, not how to fix

Bug Preview Format

**Summary:** [title]
**Project:** SCRUM
**Type:** Bug

---

## Problem
[text]

## Acceptance Criteria
| # | Criteria |
|---|----------|
| AC1 | ... |
| AC2 | ... |

After preview, ask: "Create bug in Jira?" and wait for confirmation.

---

Acceptance Criteria Rules

• Always a table with columns: # (format AC1, AC2...) and Criteria
• Write from developer perspective: what the developer must verify
• Each criterion = one testable statement
• No vague criteria like "works correctly" — be specific

Preview Format

When showing the preview in chat, render it as readable markdown:

**Summary:** [title]
**Project:** SCRUM
**Type:** Task

---

## Customer Problem
[text]

## Solution
[text]

## Acceptance Criteria
| # | Criteria |
|---|----------|
| AC1 | ... |
| AC2 | ... |

After preview, ask: "Create task in Jira?" and wait for confirmation.

Jira Description Formatting

When creating the issue via API, pass description as markdown — the Jira MCP tool converts it to ADF automatically:

• ## for headings
• **text** for bold
• [text](url) for links
• - item for bullet lists
• Standard markdown table syntax for tables

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: temnov-tpm
• Source: temnov-tpm/claude
• License: MIT

Install and usage instructions live in the source repository linked above.