feat(plan-feature): add parent issue linking step

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)

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 <issue1> --outward <issue2> --link-type <type>`
 - `jira.get_priorities()` → `python3 scripts/jira-client.py get_priorities`
 - `jira.get_versions(project)` → `python3 scripts/jira-client.py get_versions <project-key> --unreleased-only`
+- `jira.edit_issue(id, parent)` → `python3 scripts/jira-client.py update_issue <id> --fields-json '{"parent": {"key": "<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 <id> --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(<parent-key>)
+   ```
+
+   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(<feature-key>, fields={"parent": {"key": "<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.