--- name: impl-feature-plan user-invocable: true argument-hint: "" description: > Execute a feature implementation rollup produced by plan-feature: read the Feature, reconcile child User Stories against the existing rollup, and delegate ready stories to impl-story-plan one at a time in rollup order. Triggers on: "implement the feature", "run feature plan", "execute feature plan", /jx-pm:impl-feature-plan Do not trigger for: generating the feature rollup (use jx-pm:plan-feature), planning a single story (use jx-pm:plan-story), implementing a single story directly (use jx-pm:impl-story-plan), or PRD generation. --- # Implement Feature Plan Execute an ADO feature's implementation rollup end-to-end. Fetch the Feature, reconcile its child User Stories against the existing rollup written by `jx-pm:plan-feature`, and delegate ready stories one at a time to `jx-pm:impl-story-plan`. **Design intent:** This executor is feature-rollup first. It consumes the feature-level implementation rollup produced by `jx-pm:plan-feature`, uses live ADO story state to reconcile that rollup, and delegates any actual implementation work to `jx-pm:impl-story-plan`. It must never implement code directly at the feature level. ## Arguments | Argument | Required | Default | Notes | |----------|----------|---------|-------| | `work_item_id` | Yes | - | ADO Feature work item ID (integer). Prompt if missing. | --- ## Phase 1: Validate Tenant Reuse the fail-closed org/project confirmation pattern from `jx-pm:plan-feature`. 1. Run the tenant resolver: ```bash bash "${CLAUDE_PLUGIN_ROOT}/skills/create-feature/scripts/resolve-tenant.sh" ``` 2. Parse JSON stdout for `organization`, `project`, `areaPath`. 3. On exit 2 (`ASK_USER`): prompt for organization, project, and area path; do not proceed until all are confirmed. 4. Validate the connected project exists: ``` mcp__azure-devops__core_list_projects projectNameFilter= ``` 5. Require explicit user confirmation: ``` ADO target: {organization}/{project} Area Path: {areaPath} Type "{organization}/{project}" to confirm, or "abort" to exit: ``` 6. **HALT** if the project is missing, the user does not confirm exactly, or org/project cannot be confirmed. 7. Tenant propagation is safety-critical. Delegation to `impl-story-plan` must not proceed unless the parent-confirmed tenant context can be propagated safely: - If this run wrote `feedback-target.json` on the `ASK_USER` path, re-read it before every sub-skill invocation and assert `organization` and `project` still match. - If this run did not write the file, require each delegated invocation to resolve from the same working-directory root and match the already confirmed tenant. - **HALT** on tenant drift, missing propagation, or any sub-skill resolver divergence. Pass `project=` on every ADO read/comment call. Exception: `wit_update_work_item` accepts only `id` and `updates` - do not pass `project` to it. --- ## Phase 2: Fetch Feature 1. Fetch the work item: ``` mcp__azure-devops__wit_get_work_item id= project= ``` 2. Assert `System.WorkItemType` = `Feature`. **HALT** if not. 3. Capture `System.State` as ``. 4. Assert `System.State` is not `Closed`, `Done`, or `Resolved`. **HALT** if already complete. 5. Capture: | Field | ADO Reference Name | |-------|--------------------| | Title | `System.Title` | | Acceptance Criteria | `Microsoft.VSTS.Common.AcceptanceCriteria` | | State | `System.State` | | Parent ID | `System.Parent` | | Area Path | `System.AreaPath` | | Iteration Path | `System.IterationPath` | 6. Use this feature metadata as the live execution anchor for the rest of the run. 7. Use `` in the final execution ledger and comment. --- ## Phase 3: Fetch Feature Rollup The feature rollup is a prerequisite artifact produced by `jx-pm:plan-feature`. `impl-feature-plan` consumes it; it does not synthesize a replacement. 1. List the Feature comments: ``` mcp__azure-devops__wit_list_work_item_comments workItemId= project= ``` 2. Find the newest comment headed `## Feature Implementation Plan:`. 3. Treat the ADO comment as authoritative. If it includes a pointer line to `scratchpad/*_feature_plan.md`, use the scratchpad file only as a local optimization for higher-fidelity parsing. 4. If no authoritative rollup comment exists, optionally look for a matching `scratchpad/*_feature_plan.md` only to help diagnose drift - not to override ADO truth. 5. **HALT** if no valid feature rollup can be found: > "No feature implementation rollup found on Feature #{id}. Run `/jx-pm:plan-feature {id}` > first, then retry `/jx-pm:impl-feature-plan`." 6. Parse the rollup for ordered story sequence, coverage assumptions, shared dependencies, and consolidated test expectations. Preserve rollup order as the default execution order. --- ## Phase 4: Fetch Child Stories 1. Fetch the feature with relations expanded: ``` mcp__azure-devops__wit_get_work_item id= expand=relations project= ``` 2. Filter child relations (`System.LinkTypes.Hierarchy-Forward`). 3. Batch-fetch all children and filter to `System.WorkItemType` = `User Story`. 4. Capture live story metadata including title, state, parent, and stack rank. 5. Preserve the feature-rollup sequence first. Use live stack rank and story metadata only for reconciliation when the rollup and live hierarchy disagree. 6. **HALT** if the feature has no child User Stories. --- ## Phase 5: Build Execution Queue Classify every story referenced by the rollup or live child-story inventory into exactly one of: - `ready` - has a valid story implementation plan, is not already `Closed` or `Done`, and has no blocking prerequisite gaps. - `already-complete` - story state is already `Closed` or `Done`. - `missing-story-plan` - no valid `## Implementation Plan:` comment from `jx-pm:plan-story`. - `blocked` - tenant mismatch, parent/child drift, unresolved dependency, or other runtime stop. - `excluded-by-coverage-gap` - the feature rollup references a story that is missing live, or live children exist that the rollup never covered and therefore lack authoritative ordering. Queue rules: 1. Rollup order wins for stories present in the rollup. 2. Live-only stories must not be auto-inserted into execution. Classify them as `excluded-by-coverage-gap` and direct the user back to `jx-pm:plan-feature`. 3. Only `ready` stories are eligible for delegation. 4. If no stories are `ready`, **HALT** with a precise explanation. --- ## Phase 6: Confirm Execution Before any sub-skill invocation: 1. Show the ordered queue grouped by classification. 2. Include the reason each non-ready story was excluded. 3. Ask for explicit user confirmation: > "Proceed with `jx-pm:impl-story-plan` for the ready stories in this order? (yes/no)" 4. Do not invoke any story skill until the user confirms `yes`. 5. After confirmation and before the first delegated story run, transition the parent Feature to `Active`: - If `` is already `Active`, skip the patch and record `skipped (already Active)`. - Otherwise call: ``` mcp__azure-devops__wit_update_work_item id= updates=[{"path": "/fields/System.State", "value": "Active"}] ``` - Do not pass `project` to `wit_update_work_item`. - On patch failure, **HALT** and surface the error text. --- ## Phase 7: Delegate Story Execution 1. Invoke `jx-pm:impl-story-plan` one story at a time in rollup order. 2. Before every invocation: - Re-fetch the Feature and **HALT** if it is now `Closed`, `Done`, or `Resolved`. - Revalidate tenant parity against the parent-confirmed context. - Reconfirm the target story is still `ready`. 3. Delegate implementation only through the sub-skill. `impl-feature-plan` must never edit source files, create worktrees, or run tests directly. 4. `impl-feature-plan` may update only the parent Feature state for the guarded `Active` and `Resolved` transitions in this spec. Story state ownership remains exclusively with `jx-pm:impl-story-plan`. 5. If any delegated run reports tenant-resolution divergence, unsafe propagation, or a blocking prerequisite issue, stop further execution and surface the blocker immediately. --- ## Phase 8: Collect Results After each delegated story run, record: - Story ID and title - Outcome (`implemented`, `blocked`, `skipped`, `already-complete`) - Tests reported by `impl-story-plan` - Any blockers or manual follow-up notes - `` - Active transition status (`moved`, `skipped (already Active)`, `failed`, `not attempted`) - Resolved transition status (`moved`, `blocked`, `not attempted`) Maintain a feature-level execution ledger in rollup order so the user can see which stories finished and where execution stopped. --- ## Phase 9: Post Feature Summary 1. Before posting the execution summary comment, mark the Feature `Resolved` only if every delegated `ready` story completed successfully: - Call: ``` mcp__azure-devops__wit_update_work_item id= updates=[{"path": "/fields/System.State", "value": "Resolved"}] ``` - Do not pass `project` to `wit_update_work_item`. - Do this only after the execution ledger is complete and no delegated story outcome is `blocked`, ambiguous, or stopped early. - If execution was partial, blocked, ambiguous, or halted early, do not resolve the Feature and record the blocker reason. - On patch failure, **HALT** and surface the error text. 2. Build a Feature comment headed: ``` ## Feature Implementation Execution: ``` 3. Summarize ``, Active transition status, Resolved transition status, completed, blocked, skipped, already-complete, and excluded stories. 4. Include a short test summary sourced from the delegated story runs and blocker text when final resolution did not happen. 5. Post the execution summary back to the Feature: ``` mcp__azure-devops__wit_add_work_item_comment workItemId= project= comment= ``` 6. Do **not** auto-close the Feature. 7. Do **not** mutate story state directly from `impl-feature-plan`. --- ## Mandatory Contracts - `jx-pm:plan-feature` is the prerequisite producer of the feature rollup. - `jx-pm:impl-story-plan` is the runtime executor for each story. - This skill is an orchestrator, not a planner and not a code-implementer. - ADO rollup comments are authoritative; scratchpad files are only an optimization. - Missing feature rollup, closed/done feature state, missing story prerequisites, tenant drift, and unsafe sub-skill delegation are hard HALT conditions. - Parent Feature state transitions are limited to `Active` at confirmed execution start and `Resolved` after full successful delegated completion; never auto-close to `Closed`. - If coverage gaps appear between the rollup and live child-story inventory, stop and direct the user to refresh the rollup with `/jx-pm:plan-feature` before resuming execution.