# Generate Jira Task from Spec (via Jira MCP)
Create or update a *Jira ticket** from a specification feature_spec.md  

## 🔧 Inputs
 - feature_spec.md (required): path to the source spec file. 
  Example: `@_docs/03_feature_specs/spec-export-e2e.md`

 - epic <Epic-Id> (required for Jira task creation):  create Jira task under parent epic, for example:
  Example: /3.30_generate_jira_task @_docs/03_specs/spec-export-e2e.md epic AZ-112

 - update <Task-Id> (required for Jira task update): update existing Jira task, for example:
  Example: /3.30_generate_jira_task @_docs/03_specs/spec-export-e2e.md update AZ-151

## 🎯 Objective
1. Parse the spec to extract **Title**, **Description**, **Acceptance Criteria**, **Technical Details**.  
2. Create a Jira Task under Epic or Update existing Jira Task using **Jira MCP**

## 🧩 Parsing Rules

### 🏷️ Title
Use the first header (`#` or `##`) at the top of the spec.

### 📝 Description (Markdown ONLY — no AC/Tech here)
Build from:
- **Purpose & Outcomes → Intent** (bullets)
- **Purpose & Outcomes → Success Signals** (bullets)
- (Optional) one-paragraph summary from **Behavior Change → New Behavior**
> **Do not include** Acceptance Criteria or Technical Details in Description if those fields exist in Jira.

### ✅ Acceptance Criteria (Gherkin HTML)
From **"Acceptance Criteria (Gherkin)"**, extract the **full Gherkin scenarios** including:
- The `Feature:` line
- Each complete `Scenario:` block with all `Given`, `When`, `Then`, `And` steps
- Convert the entire Gherkin text to **HTML format** preserving structure (use `<pre>` and `<code>` tags or properly formatted HTML)
- Do NOT create a simple checklist; keep the full Gherkin syntax as it is essential for test traceability.

### ⚙️ Technical Details
Bullets composed of:
- **Inputs → Key constraints**
- **Scope → Included/Excluded** (condensed)
- **Interfaces & Contracts** (names only — UI actions, endpoint names, event names)
After creating the PBI, add a parent-child relation to link the Task under the Epic
**CRITICAL**: 
- Do NOT modify the parent Epic - only update the child Task

## 🔂 Steps (Agent)

1. Parse **Title**, **Description**, **AC**, **Tech** per **Parsing Rules**.
   - For AC: Extract the COMPLETE Gherkin syntax from the "Acceptance Criteria (Gherkin)" section (including Feature line, all Scenario blocks, and all Given/When/Then/And steps).
2. **Create** or **Update** the Task with the field mapping above.
   - If creating a new Task with a Epic provided, add the parent relation
   - Do NOT modify the parent Epic work item.
3. Raname spec.md and corresponding building 
  - Rename `_docs/03_specs/{taskId}-{taskNameSlug}.md`
  - Rename `_docs/03_building_blocks/{taskId}-{taskNameSlug}.md`
  {taskId} is Jira task Id which either was just created, either provided in update argument
  {taskNameSlug} is a kebab-case slug from the Jira Task title when update argument is provided, or derived from the spec title.

## 🛡️ Guardrails
- No source code edits; only one work item and (optional) one file move.
- If Jira creation/update fails, do not move the file.
- If AC/Tech fields are absent, append to Description; otherwise, keep Description clean.
- **CRITICAL**: Extract the FULL Gherkin scenarios with all steps (Given/When/Then/And) - do NOT create simple checklist items. The Gherkin syntax is required for proper test traceability in Jira
- Do not edit parent Epic