create-feature

Create Feature

Create a new Azure DevOps Feature. Two modes:

Mode	Trigger	Behavior
Draft	--draft flag	Title only — benefit hypothesis and acceptance criteria get placeholder text. No questions beyond the title.
Full	no --draft	Short SAFe interview: name, type, benefit hypothesis, acceptance criteria, priority, optional Epic link.

References

When you need to explain the SAFe feature anatomy, judge Business vs Enabler, or help the user phrase a measurable benefit hypothesis or testable acceptance criteria, consult:

• references/feature-template.md — the canonical Feature anatomy, field mapping, quality checklist, and capability-splitting patterns.
• references/feature-samples.md — worked examples (rendered as the work item this skill builds), useful to show the user when they're unsure how to phrase a field.

Arguments

Argument	Required	Notes
--draft	No	Quick placeholder feature
title text	No	Pre-fills the feature name; still prompted if missing

---

Phase 1: Parse Arguments

1. Check $ARGUMENTS for --draft. Set draft_mode = true if found.
2. Strip --draft; remaining text is title_hint (may be empty).

---

Phase 2: Tenant Resolution

Reuse feedback-target.json (shared with jx-pm:feedback) for consistency.

Resolve the tenant by running the bundled resolver — do NOT search the filesystem, sibling repos, or parent folders for a config file. The tenant is always repo-local.

1. From the working-directory root, run: bash "${CLAUDE_PLUGIN_ROOT}/skills/create-feature/scripts/resolve-tenant.sh" and read its JSON stdout. The script resolves the tenant in a strict order with no cross-project reads:
   • feedback-target.json in the working-directory root → use organization, project, areaPath.
   • else git remote get-url origin parsed for dev.azure.com/{org}/{project}/_git/{repo} → use that organization/project; areaPath defaults to project (confirm with the user).
   • else the script exits 2 with {"status":"ASK_USER",...}.
2. Resolved (exit 0) → use the returned organization / project / areaPath. If source is git-remote*, confirm the derived values (and ask for areaPath) before proceeding.
3. ASK_USER (exit 2) → ask the user once for:
   • Organization (e.g., myorg)
   • Project (e.g., MyProject)
   • Area Path (e.g., MyProject\TeamArea) Then write feedback-target.json in the working-directory root with these three fields. NEVER read another project's feedback-target.json to fill these in.
4. Validate: call mcp__azure-devops__core_list_projects with projectNameFilter = project.
   • 1 match → proceed
   • 0 matches → halt: "Project '{project}' not found. Check feedback-target.json or MCP connection."
   • Error → halt: "MCP connection error. Verify Azure DevOps MCP server is running."

---

Phase 3a: Draft Mode

Only runs when draft_mode = true.

1. If title_hint is empty, ask: "Feature name? (short phrase, e.g., 'Real-time audit log export')"
2. Build the work item (fields map to the reference names in Phase 4):
   • Title (System.Title): title_hint
   • Description (System.Description, format Html):

     <p><em>DRAFT — Benefit hypothesis and acceptance criteria to be defined.</em></p>
     <h3>Benefit Hypothesis</h3>
     <p>[What measurable value does this deliver to users or the business?]</p>
     <h3>Acceptance Criteria</h3>
     <ul><li>[To be defined]</li></ul>
     

   • Priority (Microsoft.VSTS.Common.Priority): 3 (Medium)
   • Tags (System.Tags): draft
   • Leave Microsoft.VSTS.Common.ValueArea at its ADO default (Business) — draft mode doesn't ask for type.
3. Show preview and require typed confirmation: ask the user to type {organization}/{project} to confirm (any other input cancels).
4. On confirmation → Phase 4.

---

Phase 3b: Full Mode

Runs when draft_mode = false.

Step 1: Interview

Ask all questions in one message. If title_hint is already provided, show it at the top and skip asking for the name.

Phrase the questions like this:

Here's what I need to create a well-formed feature. Answer all that apply:

1. Feature name (short phrase that names the functionality — NOT "As a user I want…") Example: "Real-time audit log export"

2. Feature type — Business or Enabler?

• Business: delivers value directly to users or customers
• Enabler: infrastructure, architecture, or technical exploration

3. Benefit hypothesis — what measurable benefit does this deliver? Example: "Reduce compliance-related support tickets by enabling customers to self-serve audit data."

4. Acceptance criteria — the conditions that prove this feature is done (one per line):

5. Priority — Critical / High / Medium (default) / Low

6. Parent Epic ID (optional) — ADO work item ID of the Epic this Feature belongs to

Step 2: Build the feature card

Map user answers to ADO fields. Feature type and Priority are native ADO fields — set them as fields, not as description text (see the Field Mapping in Phase 4).

User answer	ADO field	ADO value
Type: Business	Microsoft.VSTS.Common.ValueArea	Business
Type: Enabler	Microsoft.VSTS.Common.ValueArea	Architectural
Priority: Critical	Microsoft.VSTS.Common.Priority	1
Priority: High	Microsoft.VSTS.Common.Priority	2
Priority: Medium	Microsoft.VSTS.Common.Priority	3
Priority: Low	Microsoft.VSTS.Common.Priority	4

The Feature work item type has no separate acceptance-criteria field — for a Feature, the benefit hypothesis and acceptance criteria both live in System.Description. Build that HTML as the pure SAFe anatomy (type is captured by the native ValueArea field, so it isn't repeated here):

<h3>Benefit Hypothesis</h3>
<p>{benefit_hypothesis}</p>
<h3>Acceptance Criteria</h3>
<ul>
  <li>{criterion_1}</li>
  <li>{criterion_2}</li>
</ul>

Step 3: Preview

Show the full feature card before creating:

New Feature Project: {organization} / {project} Title: {feature_name} Type: {Business | Enabler} Area Path: {areaPath} Priority: {priority_label} Parent Epic: #{epic_id} (if provided)

Benefit Hypothesis: {benefit_hypothesis}

Acceptance Criteria:

• {criterion_1}
• {criterion_2}

Step 4: Confirmation

Ask the user to type {organization}/{project} to confirm. Any other input cancels.

---

Phase 4: Create Work Item

Field Mapping

wit_create_work_item takes a fields array of {name, value, format} objects keyed by ADO reference name (not display label). Build these fields:

Field reference name	Value	Notes
System.Title	{feature_name}	required
System.Description	{HTML from Phase 3}	set format: "Html" — this is an HTML field
System.AreaPath	{areaPath}	from feedback-target.json
Microsoft.VSTS.Common.Priority	{1–4}	from the priority map; draft → 3
Microsoft.VSTS.Common.ValueArea	Business or Architectural	full mode only; omit in draft (ADO defaults to Business)
System.Tags	draft	draft mode only — omit entirely in full mode

Steps

1. Call mcp__azure-devops__wit_create_work_item:

   • project: {project}
   • workItemType: Feature
   • fields: the array built above. Example for full mode (High priority, Business):

     [
       {"name": "System.Title", "value": "Bulk transaction history export"},
       {"name": "System.Description", "value": "<h3>Benefit Hypothesis</h3>...", "format": "Html"},
       {"name": "System.AreaPath", "value": "Jodex"},
       {"name": "Microsoft.VSTS.Common.Priority", "value": "2"},
       {"name": "Microsoft.VSTS.Common.ValueArea", "value": "Business"}
     ]
     

2. Capture {work_item_id} and {work_item_url} from the response.

3. If Epic ID provided (full mode): Call mcp__azure-devops__wit_work_items_link with updates: [{ id: {work_item_id}, linkToId: {epic_id}, type: "parent" }]. This makes the new Feature a child of the Epic. On failure: report the link error but do NOT roll back the Feature (it was created successfully).

---

Phase 5: Report

Feature created: ADO #{work_item_id}
Title: {feature_name}
URL: {work_item_url}
[If Epic linked]: Linked to Epic #{epic_id}
[If draft]: This is a draft — update the benefit hypothesis and acceptance criteria when ready.

Suggested next steps:

• Draft a PRD: /jx-pm:prd
• After PRD is ready, sync stories: /jx-pm:ado
• Review the feature for readiness in Azure DevOps and refine the benefit hypothesis / acceptance criteria as needed
• To create another feature: /jx-pm:create-feature