メニュー
Common steps for creating a new Azure DevOps work item in the FundGuard project, including iteration assignment, parent linking, and triage. Called by create-task, create-bug, and request-environment-access skills — not invoked directly by the user.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-work-item |
| description | Common steps for creating a new Azure DevOps work item in the FundGuard project, including iteration assignment, parent linking, and triage. Called by create-task, create-bug, and request-environment-access skills — not invoked directly by the user. |
| disable-model-invocation | true |
Common steps for creating a new Azure DevOps work item in the FundGuard project.
This file is a shared skill. It is referenced by the create-task, create-bug, and request-environment-access skills, which supply the work item type, crafted title, and type-specific fields.
| Input | Description |
|---|---|
| workItemType | The ADO work item type (Task, Bug, etc.) |
| title | A crafted title for the work item |
| typeFields | Any type-specific fields (e.g. repro steps for bugs) |
| commonFieldOverrides | (optional) Field/value pairs that override the defaults in the common fields table (e.g. System.AssignedTo, System.AreaPath). Omit to use the defaults. |
| skipTriage | (optional, default false) When true, skip the triage step. Use for work items assigned to other teams. |
Use get_user_team_context to look up the authenticated user's identity and team context (including iterations). The resolved identity is used for assignment by default and is always available to callers that need the display name (e.g. for titles).
If no identities are found, fall back to search_workitems for project FundGuard, fetch one of the returned work items, and extract the System.AssignedTo value.
If commonFieldOverrides supplies System.AssignedTo, that value is used for assignment instead of the resolved identity.
Constraint: NEVER assign work items to the current iteration. Always use the iteration immediately following the current one.
get_user_team_context (called in step 1) returns the current iteration per team. It does not return a list of all future iterations.
To find the next iteration:
get_user_team_context response, find the current iteration for the "FundGuard" team (or the team matching the target area path). Note its finishDate and iteration name pattern.<month>-<letter>-<year> (e.g. 7-A-26, 7-B-26, 7-C-26). Each month has three two-week sprints (A, B, C). Compute the next iteration name by advancing the letter (A->B, B->C) or rolling to the next month (C -> next month's A).FundGuard\\<next iteration name> (e.g. FundGuard\\7-B-26).search_workitems with a WIQL query: SELECT [System.Id] FROM WorkItems WHERE [System.IterationPath] UNDER 'FundGuard' AND [System.ChangedDate] > @Today - 30 ORDER BY [System.IterationPath] DESC to discover recent iteration paths.Use the next iteration's path for the work item. Do NOT use the current iteration's path.
Every work item must have a parent User Story -- orphan items are not allowed.
search_workitems with types: ["User Story"], states: ["Active"], areaPath matching the target area, and iterationPath matching the next iteration resolved in step 2.iterationPath filter (same area path, states ["Active", "New"]).areaPath: "FundGuard" and states: ["Active"].A parent story must be selected before proceeding. Do not allow the user to skip this step.
Store the selected parent story ID for use after creation.
The create_work_item tool defaults to markdown format for rich-text fields. Do not pass format: "html" -- the default is correct.
Each piece of information belongs in exactly one field -- the field designated for it by the calling skill. Don't duplicate content across fields (e.g. don't copy repro steps into description on a Bug, or put task details outside description on a Task).
Apply the objective-communication skill when composing titles and descriptions. Read and apply the external-communications skill for the approval presentation.
Before creating, show the user the full work item that will be created: title, type, all fields (common and type-specific), assigned to, iteration, and parent User Story. Confirm the iteration is not the current sprint -- it should be the one after it. Ask for confirmation. If the user requests changes, revise and re-present.
Call create_work_item with:
"Task", "Bug")commonFieldOverrides)"FundGuard\\Platform\\Web\\CInfra" (overridable via commonFieldOverrides)[{ "name": "Custom.BusinessPriority", "value": "<priority>" }]"create-<type>-<timestamp>") to prevent duplicates on retryMerge fields in this order: common defaults, then type-specific fields from the calling skill, then commonFieldOverrides. Later values win.
If creation fails due to a parent hierarchy conflict, inform the user and ask them to select a different parent story. Retry until it succeeds.
Default to 4: Technical -- the user is a Software Architect and most work items are technical bugs and tasks with no direct product-facing effect.
Use a higher priority only when the work item clearly has direct business or product impact:
| Value | When to use |
|---|---|
1: Critical | Critical production bugs: data loss, security breach, or complete service outage affecting customers |
2: Important | Major customer-facing feature broken or significant business risk |
3: Standard | Moderate product-facing impact or user-visible degradation |
4: Technical | Default. Internal improvements, technical debt, non-customer-facing bugs, refactoring, tooling |
Skip this step when any of the following are true:
skipTriage is true.System.AssignedTo (after applying commonFieldOverrides) differs from the current user resolved in step 1 — triaging is the assignee's responsibility.Otherwise, follow the triage-transition skill, passing the newly created work item's ID.
Print the created work item's ID, title, type, state, assigned to, iteration, and a direct link to the work item in Azure DevOps.
Follow the continuous-improvement skill.
Deeply gather context from an Azure DevOps work item by following its relations, linked PRs, hyperlinks, and comments. Use whenever a command needs the full picture behind a work item -- planning features, reviewing PRs, triaging, or estimating.
Mechanical estimate-and-transition of an Azure DevOps work item to the Triaged state. Called programmatically by skills that create or triage work items -- not invoked directly by the user. For user-initiated triage, use the triage skill instead.
Transitions an Azure DevOps work item to the Active state. Use when starting work on a work item, given an explicit ID or one inferred from the current feature branch.
Marks an Azure DevOps work item as Blocked and links it to its predecessor blocker. Use when a work item cannot proceed until another work item is completed.
Investigates bugs to find root cause, designs a TDD-based fix plan, and implements after approval. Use when given a bug ticket or description of defective behaviour that needs investigation and fixing in the codebase.
Follows up on a previous /review-pr or /review-plan review to check whether findings were addressed. Use in the same conversation as a preceding review invocation.