From jx-pm
Create a new Azure DevOps Feature work item following SAFe anatomy (feature name + benefit hypothesis + acceptance criteria). Use --draft for a quick placeholder; omit --draft and the skill walks you through a short guided interview. Triggers on: create a feature in ADO, create feature, new feature work item, quick feature draft, /jx-pm:create-feature. Do not trigger for: syncing a PRD to ADO (use jx-pm:ado), generating a PRD (use jx-pm:prd), creating user stories, refining or grooming existing features (use jx-pm:refine-feature).
How this skill is triggered — by the user, by Claude, or both
Slash command
/jx-pm:create-feature [--draft] [feature name or idea][--draft] [feature name or idea]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a new Azure DevOps Feature. Two modes:
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. |
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.| Argument | Required | Notes |
|---|---|---|
--draft | No | Quick placeholder feature |
| title text | No | Pre-fills the feature name; still prompted if missing |
$ARGUMENTS for --draft. Set draft_mode = true if found.--draft; remaining text is title_hint (may be empty).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.
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.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).2 with {"status":"ASK_USER",...}.organization / project / areaPath.
If source is git-remote*, confirm the derived values (and ask for areaPath) before proceeding.ASK_USER (exit 2) → ask the user once for:
myorg)MyProject)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.mcp__azure-devops__core_list_projects with projectNameFilter = project.
Only runs when draft_mode = true.
title_hint is empty, ask: "Feature name? (short phrase, e.g., 'Real-time audit log export')"System.Title): title_hintSystem.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>
Microsoft.VSTS.Common.Priority): 3 (Medium)System.Tags): draftMicrosoft.VSTS.Common.ValueArea at its ADO default (Business) — draft mode doesn't ask for type.{organization}/{project} to confirm (any other input cancels).Runs when draft_mode = false.
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
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>
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}
Ask the user to type {organization}/{project} to confirm. Any other input cancels.
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 |
Call mcp__azure-devops__wit_create_work_item:
project: {project}workItemType: Featurefields: 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"}
]
Capture {work_item_id} and {work_item_url} from the response.
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).
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:
/jx-pm:prd/jx-pm:ado/jx-pm:create-featureCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub jairosoft-com/jodex-plugins --plugin jx-pm