enhancing clarity in research assessment and problem description sections.

some files rename

.cursor/commands/gen_jira_task.md

@@ -0,0 +1,64 @@
+# 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