# Generate Jira Task and Git Branch from Spec
Create a Jira ticket from a specification and set up git branch for development.

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

 - epic <Epic-Id> (required for Jira task creation): create Jira task under parent epic
  Example: /gen_jira_task_and_branch @_docs/iterative/feature_specs/spec.md epic AZ-112

 - update <Task-Id> (required for Jira task update): update existing Jira task
  Example: /gen_jira_task_and_branch @_docs/iterative/feature_specs/spec.md update AZ-151

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

## Parsing Rules

### Title
Use the first header 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.

### Estimation
Extract complexity points from spec header and add to Jira task.

### 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
- Do NOT create a simple checklist; keep the full Gherkin syntax 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)

## Steps (Agent)

1. **Check current branch**
   - Verify user is on `dev` branch
   - If not on `dev`, notify user: "Please switch to the dev branch before proceeding"
   - Stop execution if not on dev

2. Parse **Title**, **Description**, **AC**, **Tech**, **Estimation** per **Parsing Rules**.

3. **Create** or **Update** the Jira Task with the field mapping above.
   - If creating a new Task with Epic provided, add the parent relation
   - Do NOT modify the parent Epic work item.

4. **Create git branch**
   ```bash
   git stash
   git checkout -b {taskId}-{taskNameSlug}
   git stash pop
   ```
   - {taskId} is Jira task Id (lowercase), e.g., `az-122`
   - {taskNameSlug} is kebab-case slug from task title, e.g., `progressive-search-system`
   - Full branch name example: `az-122-progressive-search-system`

5. Rename spec.md and corresponding building block:
  - Rename to `_docs/iterative/feature_specs/{taskId}-{taskNameSlug}.md`
  - Rename to `_docs/iterative/building_blocks/{taskId}-{taskNameSlug}.md`

## Guardrails
- No source code edits; only Jira task, file moves, and git branch.
- If Jira creation/update fails, do not create branch or move files.
- If AC/Tech fields are absent in Jira, append to Description.
- **CRITICAL**: Extract the FULL Gherkin scenarios with all steps - do NOT create simple checklist items.
- Do not edit parent Epic.
- Always check for dev branch before proceeding.