菜单
Fetch and normalize an Azure DevOps work item into a structured QA context. Wraps `az boards work-item show`.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | azure-devops-context |
| description | Fetch and normalize an Azure DevOps work item into a structured QA context. Wraps `az boards work-item show`. |
Use when the QA pipeline needs to read an Azure DevOps work item's title, description, acceptance criteria, and comments.
User provides an Azure DevOps work item URL or ID:
https://dev.azure.com/<org>/<project>/_workitems/edit/<id>ADO-12345az boards work-item show --id 12345AZURE_DEVOPS_ORG=my-org # fallback if not parsed from URL
AZURE_DEVOPS_PROJECT=my-proj # fallback if not parsed from URL
Or the user provides them inline. The Azure CLI (az) must be installed and logged in (az login).
Parse the work item ID and org/project from the URL or env, then:
az boards work-item show --id <id> --org https://dev.azure.com/<org> --project <project> --output json
Write normalized context to .alloy/tasks/<task-id>/qa/context.md:
# QA Context
## Source
- Azure DevOps Work Item: ADO-<id>
- URL: https://dev.azure.com/<org>/<project>/_workitems/edit/<id>
- Fetched: <timestamp>
## Work Item
- **Title:** <System.Title>
- **State:** <System.State>
- **Assigned To:** <System.AssignedTo>
- **Type:** <System.WorkItemType>
## Description
<System.Description rendered as markdown>
## Acceptance Criteria
<extracted from Description or custom field; if embedded as markdown list, preserve structure>
## Comments / Discussion
<most recent 5 comments, oldest first>
## Linked Artifacts (if any)
<list of related work items, PRs, or attachments with URLs>
If az boards work-item show fails (not logged in, wrong org, invalid ID):
az login or checking org/projectThis skill only reads Azure DevOps. It never modifies work items, creates comments, or changes state.
Use only when the user explicitly allows bounded unattended execution of an approved Alloy task.
Use when encountering a bug, regression, failing command, or unexpected behavior before attempting a fix.
Use before planning when requirements are ambiguous, large, user-visible, or likely to cause rework unless decisions are locked.
Use when implementing an approved Alloy plan. Maintains progress.md, enforces TDD/debug discipline, and stops on blocked gates.
Use when a task needs broad source understanding before planning or execution.
Use when turning context or a clear user request into an implementation-ready plan with acceptance criteria, files, commands, gates, risks, and handoff.