diff --git a/docs/constraints.md b/docs/constraints.md index 92f0a1ce2..f8fe5fbdf 100644 --- a/docs/constraints.md +++ b/docs/constraints.md @@ -91,6 +91,7 @@ existing instruction in a SKILL.md or CLAUDE.md file. | 1.79 | `plan-feature` MUST create Epics between Feature and Tasks when a level-1 issue type is discovered in Step 2.5. | `plan-feature/SKILL.md` — Step 6, sub-step 6a.0 | | 1.80 | `plan-feature` MUST fall back to Feature → Task hierarchy when no level-1 type exists, without error or user prompting. | `plan-feature/SKILL.md` — Step 6, graceful degradation | | 1.81 | `plan-feature` Epic grouping strategy MUST be configurable via interactive prompt or CLAUDE.md Hierarchy Configuration. | `plan-feature/SKILL.md` — Step 5 | +| 1.82 | `plan-feature` parent issue linking MUST validate that the parent issue's `hierarchyLevel` is higher than the Feature's `hierarchyLevel` before setting the link. | `plan-feature/SKILL.md` — Step 1.5 | ### Prior Art — Cross-phase integrity (§1.33–1.35) @@ -171,7 +172,7 @@ existing instruction in a SKILL.md or CLAUDE.md file. Each constraint above references its source. The full source files are: -- `plugins/sdlc-workflow/skills/plan-feature/SKILL.md` — Guardrails (§1.1–1.3), Step 1 Priority/fixVersion extraction (§1.74, §1.76), Step 2.5 Discover Project Issue Types (§1.62–1.64), Step 4.5 Determine Workflow Mode (§1.27), Step 5 Epic grouping (§1.79, §1.81), Step 5 Convention-aware task enrichment (§4.11, §4.13), Step 5 Target Branch assignment (§4.12), Step 5 Bookend task generation (§3.4), Step 6 sub-step 6a.0 Epic creation (§1.79), Step 6 graceful degradation (§1.80), Step 6 Priority/fixVersion inheritance (§1.74, §1.75, §1.76), Step 6a Digest posting (§1.33), Task Description Template (§4.1–4.10) +- `plugins/sdlc-workflow/skills/plan-feature/SKILL.md` — Guardrails (§1.1–1.3), Step 1 Priority/fixVersion extraction (§1.74, §1.76), Step 1.5 Parent linking (§1.82), Step 2.5 Discover Project Issue Types (§1.62–1.64), Step 4.5 Determine Workflow Mode (§1.27), Step 5 Epic grouping (§1.79, §1.81), Step 5 Convention-aware task enrichment (§4.11, §4.13), Step 5 Target Branch assignment (§4.12), Step 5 Bookend task generation (§3.4), Step 6 sub-step 6a.0 Epic creation (§1.79), Step 6 graceful degradation (§1.80), Step 6 Priority/fixVersion inheritance (§1.74, §1.75, §1.76), Step 6a Digest posting (§1.33), Task Description Template (§4.1–4.10) - `plugins/sdlc-workflow/skills/implement-task/SKILL.md` — Important Rules (§1.4–1.6, §5.1–5.3), Step 1 (§1.6), Step 1.5 Digest verification (§1.34, §1.35), Step 4/6/9 (§5.4), Step 5 (§1.15, §3.1, §3.4), Step 7 (§5.9–5.13), Step 9 (§2.1–2.3, §5.6–5.8), Step 10 (§3.2, §3.3) - `plugins/sdlc-workflow/shared/task-description-template.md` — Rules (§4.12) - `plugins/sdlc-workflow/shared/description-digest-protocol.md` — Digest format and verification procedure (§1.33, §1.34, §1.35) diff --git a/plugins/sdlc-workflow/skills/plan-feature/SKILL.md b/plugins/sdlc-workflow/skills/plan-feature/SKILL.md index 11727d5f2..0bf4a5fb0 100644 --- a/plugins/sdlc-workflow/skills/plan-feature/SKILL.md +++ b/plugins/sdlc-workflow/skills/plan-feature/SKILL.md @@ -84,7 +84,7 @@ If any of these sections are missing or incomplete, inform the user: ## Step 0.5 – JIRA Access Initialization -Before attempting any JIRA operations (Steps 1, 2.5, 4, 6), determine the access method. +Before attempting any JIRA operations (Steps 1, 1.5, 2.5, 4, 6), determine the access method. **For every JIRA operation:** 1. **Attempt MCP first** (preferred method) @@ -114,6 +114,7 @@ Before attempting any JIRA operations (Steps 1, 2.5, 4, 6), determine the access - `jira.create_issue_link(...)` → `python3 scripts/jira-client.py create_link --inward --outward --link-type ` - `jira.get_priorities()` → `python3 scripts/jira-client.py get_priorities` - `jira.get_versions(project)` → `python3 scripts/jira-client.py get_versions --unreleased-only` +- `jira.edit_issue(id, parent)` → `python3 scripts/jira-client.py update_issue --fields-json '{"parent": {"key": ""}}'` Refer to `shared/jira-rest-fallback.md` for complete implementation details. @@ -153,6 +154,49 @@ Extract: **On MCP failure, if REST API chosen (Step 0.5):** use `get_issue --fields "*all"` — the response includes `fields.priority` and `fields.fixVersions` in the same structure. +## Step 1.5 – Link Feature to Parent Issue + +After fetching the Feature issue in Step 1, optionally link it to a parent issue +in the Jira hierarchy (e.g., an Outcome at hierarchy level 3+). This enables teams +to maintain the full Outcome → Feature → Epic → Task hierarchy. + +1. **Check existing parent**: inspect the Feature issue response from Step 1 for a + `parent` field. If the Feature already has a parent set, display the current + parent (key and summary) and ask the user whether to keep or change it. If the + user wants to keep it, skip to Step 2. + +2. **Prompt the user**: display an interactive prompt: + + ``` + Link this Feature to a parent issue? Enter the parent issue key (e.g., TC-100) or press Enter to skip: + ``` + +3. **If user provides a key**: validate it by fetching the issue: + + ``` + jira.get_issue() + ``` + + Verify that: + - The issue exists. + - Its issue type's `hierarchyLevel` is strictly higher than the Feature's + `hierarchyLevel`. Use the type-to-role mapping from Step 2.5 if already + available, or inspect the parent issue type's `hierarchyLevel` field directly + from the fetched issue response (`fields.issuetype.hierarchyLevel`). The + parent should be at level 3+ (e.g., Outcome), not at the same level as + the Feature (level 2) or lower (Epic level 1, Task level 0). + + If validation fails, inform the user of the hierarchy mismatch and ask again. + +4. **Set the parent link**: update the Feature issue: + + ``` + jira.edit_issue(, fields={"parent": {"key": ""}}) + ``` + +5. **If user skips (presses Enter)**: proceed without linking — this step is + entirely optional. + ## Step 2 – Inspect Figma Design If a Figma URL was provided as an argument, use it directly.