mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-23 01:16:37 +00:00
d5c036e6f7
some files rename
65 lines
3.4 KiB
Markdown
65 lines
3.4 KiB
Markdown
# 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
|