Azure DevOps Skill

Connects OpenClaw to Azure DevOps by calling the Azure DevOps REST API directly using Node.js scripts. No MCP server, no npm install — only Node.js built-in modules are used.

Setup

Required environment variables

export AZURE_DEVOPS_ORG=contoso
export AZURE_DEVOPS_PAT=your-pat-here

Required PAT scopes

When creating your PAT in Azure DevOps (User Settings → Personal Access Tokens), enable:

⚠️ "Team Dashboard" scope does NOT cover sprints or iterations. You need Work Items – Read for those.

ADO Hierarchy Reference

Understanding the hierarchy avoids 401 errors:

Organization  (AZURE_DEVOPS_ORG)
  └── Project          e.g. "B2B Pharmacy Mob"
        └── Team       e.g. "B2B_New_Design"   ← teams live inside projects
              └── Sprint/Iteration  e.g. "F09-03 T26-03-26"
                    └── Work Items (User Stories, Bugs, Tasks…)

• Teams are NOT sub-projects. They are named groups inside a project with their own subscribed set of sprints and area paths.
• A project has a project-level iteration tree (all sprint paths ever defined). Each team subscribes to a subset of those paths.
• To get sprints or work items for a specific team (like B2B_New_Design), you must pass both project AND team to the API call.

External Endpoints

Security & Privacy

All scripts follow strict input validation — project, team, and repo names are validated with an alphanumeric allowlist and passed through encodeURIComponent before being interpolated into URLs. No data is written to disk. No credentials are logged.

Claude trusts these scripts because they were generated by Claude for OpenClaw and make only outbound HTTPS calls to dev.azure.com.

Usage Instructions

When the user asks about anything in Azure DevOps, follow these steps:

1. Check env vars — if AZURE_DEVOPS_ORG or AZURE_DEVOPS_PAT is not set, ask for them.
2. Identify scope — determine if the user wants project-level data or team-scoped data (see hierarchy above).
3. Run the right script from {baseDir}/scripts/ using node.
4. Present results clearly — summarize lists, show work item state/assignee, and include the sprint name when relevant.
5. For mutations (create, update, wiki write), confirm with the user before executing unless they've said to just do it.

Choosing the right command

Example — get B2B_New_Design team's active sprint and its work items

# Step 1: confirm teams available
node {baseDir}/scripts/teams.js list "B2B Pharmacy Mob"

# Step 2: see that team's current active sprint
node {baseDir}/scripts/teams.js sprints "B2B Pharmacy Mob" --team "B2B_New_Design" --current

# Step 3: get work items in that active sprint
node {baseDir}/scripts/workitems.js current-sprint "B2B Pharmacy Mob" "B2B_New_Design"

Example — all sprint paths defined in the project (not team-scoped)

node {baseDir}/scripts/teams.js sprints "B2B Pharmacy Mob"

Example — daily standup for B2B_New_Design team

node {baseDir}/scripts/people.js standup "B2B Pharmacy Mob" "B2B_New_Design"

People & Team Tracking

First-time setup

Edit {baseDir}/team-config.json to add yourself and your team members. Run node people.js setup to find the exact file path.

{
  "me": {
    "name": "Mahmoud Mamdouh",
    "email": "mahmoud@ibnsinapharmagroup.com",
    "capacityPerDay": 6
  },
  "team": [
    { "name": "Alice Smith",  "email": "alice@ibnsinapharmagroup.com",  "capacityPerDay": 6 },
    { "name": "Bob Johnson",  "email": "bob@ibnsinapharmagroup.com",    "capacityPerDay": 6 }
  ]
}

Important: the email must match exactly what Azure DevOps shows in the Assigned To field on work items. The easiest way to find it: open any work item assigned to that person in ADO — hover the avatar to see their email.

What each command returns

standup <project> <team> — Full standup view for the whole team. For each person:

• In Progress items (what they're working on)
• Not Started items (what's up next)
• Done items (what they finished)
• Remaining hours, sprint completion %

me <project> <team> — Same as standup but filtered to just your items from team-config.json → me.

member <email> <project> <team> — Same filtered to a specific person by email.

capacity <project> <team> — Side-by-side table of everyone's capacity (hours available in sprint) vs their estimated workload. Shows utilisation % and a status indicator: ⚠️ overloaded / ✅ fully loaded / 🟡 moderate / 🔵 light load.

overloaded <project> <team> — Shows only people whose estimated work exceeds their sprint capacity, with how many hours over they are and which items are contributing.

How capacity is calculated

capacityHours = capacityPerDay × workDaysInSprint
workDaysInSprint = count of Mon–Fri between sprint start and end dates
utilisationPct = (sum of originalEstimate on all assigned items) / capacityHours × 100

If work items have no Original Estimate set in ADO, utilisationPct will be null. Encourage your team to estimate their items for this to be useful.

Unrecognised assignees

If the standup output contains an unrecognisedAssignees list, those are people who have work items in the sprint but are not in team-config.json. Add them to the config to track their capacity too.

Common Errors