Boards Work Item Summary
Summarize a single Azure Boards work item—with parent links, related items, and comments—in one agent pass when triaging backlog or standups.
Overview
boards-work-item-summary is an agent skill for the Build phase that summarizes one Azure DevOps work item by ID, including linked items, parent hierarchy, and comments via MCP.
Install
npx skills add https://github.com/microsoft/azure-devops-skills --skill boards-work-item-summaryWhat is this skill?
- Requires one work item ID—uses the user’s ID or prompts once, then stops without calling MCP if still missing
- Fetches full work item with expand=all, then batches linked and parent IDs via wit_get_work_items_batch_by_ids
- Pulls comment threads with wit_list_work_item_comments for narrative context on the ticket
- Uses Azure DevOps MCP Server tools only—no portal copy-paste
- Includes parent work items from System.Parent or Hierarchy-Reverse relations in the summary set
- 3 MCP tools: wit_get_work_item, wit_list_work_item_comments, wit_get_work_items_batch_by_ids
Adoption & trust: 34 installs on skills.sh; 23 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a ticket ID in chat but need parent context, linked bugs, and comment history without opening Azure DevOps in the browser.
Who is it for?
Indie builders and tiny teams on Azure Boards who triage or explain a specific work item from Claude Code, Cursor, or Codex with MCP wired to their org.
Skip if: Bulk board exports, creating or editing work items, or workflows where no work item ID is available and you refuse to provide one after the single prompt.
When should I use this skill?
User names a work item ID or asks to summarize a specific Azure DevOps Boards ticket.
What do I get? / Deliverables
After the skill runs, you get a consolidated narrative of one work item’s fields, relations, and comments suitable for triage or handoff to implementation.
- Structured summary of one work item including fields, linked items, parent, and comments
Recommended Skills
Journey fit
Work-item triage and hierarchy context sit in the build phase under project management, where solo builders track what ships next. Azure DevOps Boards is backlog and delivery tracking; pm is the canonical shelf for work-item reads, not frontend implementation.
How it compares
Task-focused MCP skill for one WIT summary—not a full Azure DevOps PM replacement or a generic markdown note taker.
Common Questions / FAQ
Who is boards-work-item-summary for?
Solo and indie developers using Azure DevOps Boards who want their agent to read one work item end-to-end—links, parent, and comments—during build or support triage.
When should I use boards-work-item-summary?
Use it in Build (pm) when scoping a task from a ticket ID, before coding from a User Story, or during Operate (support) when you need comment history on a production bug—always with a specific work item ID.
Is boards-work-item-summary safe to install?
It invokes Azure DevOps MCP tools against your configured org; review the Security Audits panel on this page and limit MCP credentials to least-privilege DevOps access.
SKILL.md
READMESKILL.md - Boards Work Item Summary
# Get work item This skill always works with **one specific work item ID**. - If the user **provides an ID** (for example: "for 115770" or "work item 115770"), use that ID directly. - If the user **does not provide an ID**, prompt the user once to provide the work item ID. - If the ID is **still not provided after prompting**, stop and return a clear message stating that a work item ID is required and do not call any tools. # Tools Use Azure DevOps MCP Server tools for all interactions with Azure DevOps. - `wit_get_work_item`: Get a work item from Azure DevOps by its ID. - `wit_list_work_item_comments`: Get the list of comments for a work item by its ID. - `wit_get_work_items_batch_by_ids`: Get work item details in batch by their IDs. Use this tool to get the details of linked work items, using the links returned from `wit_get_work_item`. # Steps 1. Call `wit_get_work_item` with `expand=all` for the requested ID so that you retrieve fields, relations, and links in a single call. 2. If the work item has a parent (for example, `System.Parent` or a `System.LinkTypes.Hierarchy-Reverse` relation), include the parent ID in the set of linked IDs to summarize. You do **not** need a separate `wit_get_work_item` call for the parent; instead, rely on `wit_get_work_items_batch_by_ids` in the next step. 3. From the work item `relations` array, collect all linked work item IDs (parent, child, related, and any others). Call `wit_get_work_items_batch_by_ids` once with that list of IDs to get the details of all linked work items. 4. Call `wit_list_work_item_comments` once to get the comments for the original work item. # Display results When displaying the results: - Show the following fields for the main work item: **Id**, **Title**, **State**, **Assigned To** (just the display name, not the email), **Work Item Type**, **Created Date** formatted as `MM/DD/YYYY`, **Priority**, and **Tags**. - Provide a **Links** table. For each linked work item, display: - **Id** as a clickable hyperlink in this exact format: `[{ID}](https://dev.azure.com/{organization}/{project}/_workitems/edit/{ID})` - **Link type** (for example: Parent, Child, Related, or the underlying relation name) - **Work item type** - **Title** - **State** Group and order the rows in this sequence: **Parent links first**, then **Child links**, then **Related links**, then any **other link types**. - If there are pull requests linked to the work item (for example, via artifact links or specific PR relations), list them in a separate **Pull Requests** table with at least the PR ID, title, status, and a clickable link to the PR. - Provide a short, plain-language **summary** of the work item’s description, system information, and repro steps (if those fields exist). Focus on the key intent, scope, and any critical technical or repro details. - For **comments**: - If there are one or more comments, state the **total number of comments** and give a brief overview of the main themes or decisions mentioned. - If there are **no comments**, explicitly state that there are no comments for this work item.