impl-feature-plan

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 "${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=<project>
   

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=<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=<work_item_id>  project=<project>
   

2. Assert System.WorkItemType = Feature. HALT if not.
3. Capture System.State as <initial_feature_state>.
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 <initial_feature_state> 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=<work_item_id>  project=<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=<work_item_id>  expand=relations  project=<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 <initial_feature_state> is already Active, skip the patch and record skipped (already Active).
   • Otherwise call:

     mcp__azure-devops__wit_update_work_item  id=<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
• <initial_feature_state>
• 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=<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 <initial_feature_state>, 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=<work_item_id>  project=<project>  comment=<summary>
   

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.