Use this skill to manage the full lifecycle of DevOps Center work items — list, create, update, commit changes, perform status transitions, and create pull requests. Update fields like subject, description, and status. Commit and push code changes to work item branches. Create pull requests for work

DevOps Center Work Item Management Manages the complete work item lifecycle in DevOps Center — from creation through status transitions to promotion readiness. Provides headless CLI driven operations for autonomous release workflows. Scope In scope : List work items, create new work items, commit changes to work item branches, update work item fields (subject, description, status), transition work item status (New → In Progress → Ready to Promote), create pull requests for work item branches Out of scope : Promotion/deployment, conflict detection, pipeline or project management (separate skills) Required Inputs Gather or infer before proceeding: Operation type : list, create, update, commit, or create review For list : project ID (required) — obtain via sf devops project list json if not provided For create : project ID (required), subject (required), description (optional) For commit : work item name or ID (required), commit message, and either the files to commit (git path) or the components to commit (API path). Optional: dev org alias — the org that holds the changes. When provided, try the DevOps Center commit API first (see step 5); otherwise use git For update : work item name (e.g., WI 000001) or work item ID (required), fields to update (subject, description, status) For create review : work item name (e.g., WI 000001) or work item ID (required) Defaults unless specified: Output format: json for headless consumption Work item identifier: prefer work item name (WI 000001) over work item id when both are available (names are human readable) If the user provides a clear request ("list work items for Project Alpha", "create work item to fix login bug", "move WI 12345 to In Progress", "create PR for WI 12345"), proceed immediately without unnecessary questions. Workflow Operations use sf devops work item CLI commands with json output; the API commit path also uses sf api request rest and sf data query . Phase 1 — Identify Operation 1. Determine the operation type from user intent: Keywords like "list", "show", "find" → list operation Keywords like "create", "new", "add" → create operation Keywords like "commit", "push", "save changes", "git commit" → commit operation Keywords like "update", "change", "modify", "edit", "move", "transition", "advance", "mark as" → update operation Keywords like "create PR", "pull request", "code review", "review", "open PR" → create review operation Phase 2 — Execute Operation 2. Verify org authentication before any operation: If no default org is set or authentication has expired, instruct the user to run: Verify the authenticated org has DevOps Center enabled by attempting to list projects If the user wants to target a specific org, use target org <alias on all subsequent commands For the API commit path, run sf org display target org <alias json for both the dev org and the hub org 3. List work items — when the user wants to see existing work items: project id is required — if the user provides a project name instead of ID, first run sf devops project list json to resolve the name to an ID Verify the command returns status 0 (success) Parse the JSON output: the work items are in the .result[] array Each work item has: name (e.g., WI 000001), subject , branch , environment , status , description Present in a readable format showing work item name, subject, status, branch, and environment If .result[] is an empty array, confirm "No work items found in project <project name ." If the user requested filtering by status (e.g., "show work items in Ready to Promote status"), run: Then present the matching work items 4. Create a work item — when the user wants to create a new work item: project id is required (obtain from user or via sf devops project list json ) subject is required (user facing title) description is optional (defaults to blank if omitted) Capture the returned work item name (e.g., WI 000001), branch name, and environment from JSON output for future operations Idempotent: if the user attempts to create a duplicate (same subject + project), check via list first and return the existing work item 5. Execute commit operation — when operation type is commit. Choose the path first: API path — only when the user gave a dev org alias AND the changes are already deployed in that dev org (if unsure, ask: deploy with sf project deploy start , or use git). Dev org alias: commitChanges , DevopsRequestInfo . Hub alias: sf devops and WorkItemComponentList . DevOps Center retrieves the named components from the dev org and commits them as DevOps Center <noreply@salesforce.com . Git path — everything else. If the changes exist only in the dev org, run sf project retrieve start target org <dev org first. API path (commands, body, error codes and polling in references/commit api.md ): 1. Preflight GET /connect/devops/doceConnectionType on the dev org; a failed call (non zero exit or error body) or isCore not true means use the git path. 2. sf devops project list → project id, then sf devops work item list project id <id target org <hub → work item id and name. Status must be New, In Progress, In Review or Ready to Promote. 3. POST /connect/devops/commitChanges on the dev org ; the body is the inner object (no commitChanges wrapper). 4. A failed call, or status: "ERROR" with reqId = CODE:message : surface it and stop. 5. If the POST status is SUCCESS (accepted only), poll DevopsRequestInfo WHERE RequestToken = '<reqId ' on the dev org every 10 seconds until Status is SUCCESS or ERROR (report Message / ErrorDetails ), 12 minute deadline. Past it the request is stuck; report it and do not retry automatically. 6. Confirm a new WorkItemComponentList exists on the hub before creating a review. Git path: If the work item is New, first set it to In Progress (step 6); the hub ignores pushes made while it is New Use the work item's branch field as the branch Standard git workflow: The hub registers the push asynchronously; re check it before creating a PR 6. Update work item — when the user wants to change subject, description, or status: Work item identifier is required: use work item name <WI 000001 (preferred) or work item id <id If the user provides a work item by subject instead of name, resolve it to a name first: Then pass the returned name (e.g., WI 000001) to the update command At least one of subject , description , or status must be provided Valid status values: "In Progress" or "Ready to Promote" (exact strings with spaces) Only include flags for fields being updated (omit unchanged fields) Verify the command returns status 0 (success) Parse the JSON response: .result.name , .result.subject , .result.status contain the updated values For status transitions specifically : after the command completes, explicitly confirm the new status by checking .result.status in the response. If the status field is absent from the update response, re query the work item via list to verify the status persisted 7. Create pull request — when the user wants to create a PR for code review: Work item identifier is required: use work item name <WI 000001 (preferred) or work item id <id If the user provides a work item by subject instead of name, resolve it to a name first: Then pass the returned name (e.g., WI 000001) to the review create command Creates PR via DevOps Center API using VCS credentials stored in the org No local VCS authentication required — DevOps Center handles GitHub/Bitbucket auth Works with GitHub and Bitbucket Verify the command returns status 0 (success) Parse the JSON response: .result.pullRequestUrl contains the PR URL, .result.status contains the PR status (typically "open" for newly created PRs), .result.number contains the PR number If the command fails with a VCS credentials error, instruct the user to configure VCS credentials in the DevOps Center org (Setup → DevOps Center → VCS Credentials) If the command fails with "PR already exists" error, report that a PR already exists for this work item (idempotent operation) Phase 3 — Verify and Report 8. Verify operation success : For list : confirm the CLI returned status 0, parse the JSON .result[] array, and verify it contains work items (or is empty if no matches). If the user specified a project by name, confirm the resolved project ID matches. For create : verify the CLI returned status 0 and the JSON output contains .result.name (work item ID like WI 000001), .result.branch (branch name), and .result.environment fields. For commit (git path) : verify each git command returned exit code 0. If git push succeeds, the commit is saved to the work item branch; the hub registers it asynchronously. For commit (API path) : verify the POST status , then DevopsRequestInfo.Status , are SUCCESS , and that a new WorkItemComponentList with a CommitReference exists on the hub. A new list with an empty CommitReference means nothing new was committed; report that, not a clean success. For update (general fields) : verify the CLI returned status 0 and compare the returned JSON fields against the user's requested changes. If updating subject, confirm .result.subject matches the new value. For update (status transition) : verify the CLI returned status 0, then explicitly confirm the status transition by checking .result.status in the JSON response matches the target status (e.g., "Ready to Promote"). If the response doesn't include the status field, re run sf devops work item list filtered to this work item and verify the status persisted. For create review : verify the CLI returned status 0 and the JSON output contains .result.pullRequestUrl (the PR URL) and .result.status (should be "open" or equivalent). If VCS credentials are missing, the CLI returns an error — surface this to the user. 9. Report results : List : present work items in a readable format showing work item name, subject, status, branch, and environment. If filtering by status was requested, show only matching work items. Create : return the work item name (e.g., WI 000001), branch name, environment, and confirm "Work item created successfully." Commit : git path — confirm which files were staged, the commit SHA (from git output), and "Changes committed and pushed to branch <branch name ." API path — confirm the reqId , components committed and hub CommitReference (author is DevOps Center) Update (general) : confirm which fields changed with before/after values (e.g., "Subject updated from 'X' to 'Y'"). Status transition : explicitly state the transition with old → new status (e.g., "Status updated: In Progress → Ready to Promote"). Create review : return the PR URL and confirm "Pull request created successfully. Status: open. URL: <url " Rules / Constraints Constraint Rationale All sf devops commands must use json flag Structured output is required for headless consumption; human readable output is unreliable for parsing Work item identifier required for commit, update, and create review Use work item name (preferred) or work item id ; obtain from list or prior create Project ID required for list and create All work items belong to a project; use sf devops project list json if not provided At least one update field required Update command fails if no subject , description , or status flag is provided Status values must be exact strings "In

dx-devops-work-item-manage