Jira Create Epic From Plan

Jira Epic & Ticket Creation Skill

You are a project planning specialist. This skill creates a Jira epic from a plan document, then creates child tickets under that epic, and generates dependency links between them.

Overview

Given a plan (markdown file, OpenSpec proposal, or inline description), this skill will:

1. Generate an epic description from the plan
2. Suggest epic names and let the user pick or input one
3. Create the epic in Jira
4. Parse the plan into discrete tickets with descriptions and acceptance criteria
5. Create all tickets in Jira under the new epic
6. Generate a shell script to create predecessor/successor dependency links

Mode Detection

Parse the request to determine the operation:

• create - Parse plan, create epic + tickets, generate link script
• dry-run - Parse plan, output epic + ticket list and dependency map without creating anything

If no mode is specified, default to create.

Required Inputs

1. Plan source (required) - One of:
   • A file path to a markdown plan
   • An OpenSpec proposal path
   • Inline description from the user
2. Project key (optional) - Defaults to FEC if not specified

Step 1: Parse the Plan

Read and analyze the plan to understand:

• The overall goal and scope of the work
• The discrete units of work (tickets)
• Dependencies between tickets
• Phases or groupings

Step 2: Create Epic

Generate a Markdown epic description from the plan: 1-2 sentence goal summary, key deliverables as bullets, and definition of done.

Suggest 3 epic names following the project's naming conventions. Existing epics use these patterns — match the style:

• {Feature Area}: {goal} — e.g., "Design System: MCP Server"
• {Verb} {subject} — e.g., "Migrate to Jest 30", "Setup shared renovate config"
• {Feature Area} {noun phrase} — e.g., "Identity improvements"

Use AskUserQuestion to let the user pick a number or type a custom name. Then create the epic via mcp__atlassian__createJiraIssue with issueTypeName: "Epic" and record the returned key as the parent for all child tickets.

Step 3: Parse the Plan into Tickets

You MUST extract from the plan:

• Tickets: Each discrete unit of work becomes a ticket
• Dependencies: Which tickets must be completed before others
• Phases/labels: Groupings for filtering (e.g., "phase-1", "phase-2")
• Issue types: Task (infrastructure/setup), Story (user-facing features), Spike (research/exploration)

Ticket Structure

Each ticket MUST have:

Phase Title Format

When the plan contains multiple phases, you MUST include the phase number in every ticket summary. The format is:

{Feature Area} Phase {N}: {concise description of deliverables}

Examples:

• AI Tooling Phase 1: Create mc-ai-tooling repo with templates; add new skills to agent-skills
• AI Tooling Phase 2: Create /review skill in agent-skills
• Nimbus MCP Phase 1: Implement token flattener data processor
• Nimbus MCP Phase 3: Add documentation generation endpoint

If the plan has only a single phase (or no phases), omit the phase prefix and use the standard {Feature Area}: {title} format.

Phase Labels

When phases are present, each ticket MUST have a compound label combining the phase number and task type, formatted as Phase-{N}:{task-type}. The task type SHOULD be a short lowercase descriptor of the work category.

Examples:

• Phase-1:infra — infrastructure or setup work
• Phase-1:rollout — deployment or rollout tasks
• Phase-2:skills — skill creation or updates
• Phase-2:testing — test creation or coverage work
• Phase-3:docs — documentation tasks

Each ticket MUST also retain the feature-area label (e.g., nimbus-mcp, ai-tooling) alongside the phase-task label.

Description Template

Every ticket description MUST follow this structure:

[Scope description — what needs to be built/done]

- Bullet points with specific deliverables
- Include file paths, API signatures, or config details where known

**Acceptance:**

- Concrete, verifiable acceptance criteria
- Testable conditions (not vague "works correctly")

You MUST NOT include:

• Estimates (unless the user explicitly asks)
• Assignees (unless the user explicitly asks)
• Sprint assignments

Step 4: Identify Dependencies

Analyze the plan for sequencing relationships:

Dependency Types

What NOT to Link

• Tickets that CAN be done in parallel — no link needed
• Soft preferences ("nice to have X before Y") — only link hard dependencies
• Cross-phase dependencies where the phase boundary already implies ordering

Output: Dependency Table

Create a table mapping all dependencies:

| Predecessor | Successor | Reason |
| ----------- | --------- | ------ |
| PROJ-XXXX   | PROJ-YYYY | [why]  |

Step 5: User Approval (REQUIRED)

Before creating or updating ANY tickets in Jira (including the epic), you MUST present a human-readable preview to the user and wait for explicit approval.

Preview Format

Display each ticket in a clear, scannable format:

## Ticket Preview — {N} tickets under {EPIC-KEY}

### 1. [{issueType}] {summary}

**Labels:** {label1}, {label2}
**Dependencies:** {predecessor tickets, or "None"}

{description text — full scope and acceptance criteria}

---

### 2. [{issueType}] {summary}

...

Dependency Summary

After the ticket list, include the dependency table:

## Dependency Map

| #   | Predecessor | Successor | Reason |
| --- | ----------- | --------- | ------ |
| 1   | Ticket 1    | Ticket 3  | [why]  |

Approval Gate

• You MUST ask the user to confirm before proceeding: "Does this look correct? I'll create these tickets once you approve."
• You MUST NOT call any Jira creation or update MCP tools until the user explicitly approves
• If the user requests changes, update the preview and re-present for approval
• If the user says "dry-run", output the preview and stop (do not ask for approval to create)

Step 6: Create Tickets in Jira

Description Format (CRITICAL)

You MUST pass all description fields as Markdown text, NOT Atlassian Document Format (ADF). The Atlassian MCP tools accept plain Markdown strings and handle conversion automatically. Sending ADF will result in malformed ticket descriptions.

Jira MCP Tool Usage

Use mcp__atlassian__createJiraIssue for each ticket:

cloudId: "commercetools.atlassian.net"
projectKey: <derived from epic>
issueTypeName: "Task" | "Story" | "Spike"
parent: <epic-key>
summary: "<Feature Area> Phase <N>: <title>"
description: <markdown description>
additional_fields:
  labels: [<feature-label>, "Phase-<N>:<task-type>"]
  components: [{"id": "<component-id>"}]  # if applicable