Expand Jira Ticket

Purpose

Break down a Jira ticket into [DEV] and [QA] subtasks based on its description and acceptance criteria.

Instructions

Step 1: Get the Cloud ID

Call getAccessibleAtlassianResources to retrieve the Atlassian Cloud ID.

Step 2: Fetch the Parent Ticket

Call getJiraIssue with the ticket key provided by the user (e.g., "PROJ-42").

Extract from the response:

•Summary — what the ticket is about
•Description — the full description body
•Project key — for creating subtasks in the same project
•Issue key — to use as the parent when creating subtasks

If the ticket has no description or acceptance criteria, inform the user and stop. Suggest they add a description first or use /create-ticket to rewrite it.

Step 3: Verify Subtask Type Exists

Call getJiraProjectIssueTypesMetadata for the project to find the correct subtask issue type name. Look for a type with subtask: true (commonly named "Subtask" or "Sub-task"). Use the exact name from the project's configuration.

Step 4: Analyze and Plan Subtasks

Parse the ticket description to identify:

For DEV subtasks — break the implementation into discrete coding units:

•Look at the Summary and Technical Notes for implementation scope
•Each subtask should be a single, focused coding task one developer could pick up
•Think in terms of: data model changes, API endpoints, UI components, integration/wiring, configuration
•Order them logically (dependencies first)

For QA subtasks — map acceptance criteria to test tasks:

•Each Given/When/Then scenario in the acceptance criteria should become one QA subtask
•If the description doesn't use BDD format, derive testable scenarios from whatever description exists
•Include the test approach in each QA subtask description

Step 5: Create DEV Subtasks

For each DEV subtask, call createJiraIssue with:

•cloudId: from Step 1
•projectKey: same as parent ticket
•issueTypeName: the subtask type name from Step 3
•parent: the parent ticket key (e.g., "PROJ-42")
•summary: [DEV] <concise task description>
•description: formatted as:

markdown

## Task
[What to implement — 1-2 sentences]

## Details
- [Specific implementation detail]
- [Files or areas likely affected]
- [Any constraints or dependencies on other subtasks]

Step 6: Create QA Subtasks

For each QA subtask, call createJiraIssue with:

•cloudId: from Step 1
•projectKey: same as parent ticket
•issueTypeName: the subtask type name from Step 3
•parent: the parent ticket key (e.g., "PROJ-42")
•summary: [QA] <what to test>
•description: formatted as:

markdown

## Scenario
- **Given** [precondition from acceptance criteria]
- **When** [action]
- **Then** [expected outcome]

## Test Approach
- [How to verify — manual steps or automation strategy]
- [Edge cases to cover]
- [Test data requirements if any]

Step 7: Report Results

Display a summary of all created subtasks:

code

Expanded PROJ-42 into N subtasks:

DEV:
  PROJ-43 — [DEV] <summary>
  PROJ-44 — [DEV] <summary>
  PROJ-45 — [DEV] <summary>

QA:
  PROJ-46 — [QA] <summary>
  PROJ-47 — [QA] <summary>
  PROJ-48 — [QA] <summary>

Best Practices

•Keep DEV subtasks small enough for one developer to complete independently
•Every QA subtask should map to a testable scenario — if it can't be verified, rewrite it
•Don't create subtasks for trivial work (e.g., "[DEV] Create branch" or "[QA] Smoke test") — focus on meaningful units
•If the parent ticket is vague, create fewer, broader subtasks rather than guessing at specifics
•Aim for 2-5 DEV subtasks and 2-4 QA subtasks per ticket — more suggests the parent should be split into multiple tickets