New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Analyze Azdo Build

by DataDog in DataDog/dd-trace-dotnet

Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline.

OfficialApache-2.0Auto-check passedTesting & QA

Install Analyze Azdo Build

skills CLI
$ npx skills add DataDog/dd-trace-dotnet --skill analyze-azdo-build -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install DataDog/dd-trace-dotnet analyze-azdo-build --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/DataDog/dd-trace-dotnet.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/analyze-azdo-build .claude/skills/analyze-azdo-build && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
analyze-azdo-build
GitHub stars
573
Token cost
~3.5k tokens
SKILL.md length
1,357 words
Files
4 (incl. references)
Skills in repo
6
Repo updated
First seen
Licence
Apache-2.0

At a glance

Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline.

  • Works in 4 steps: Quick Initial Analysis → Deep Analysis (Only If Requested) → Quick Summary → …
  • Mentions a failing CI build
  • SKILL.md covers Prerequisites, Additional Resources, Task and Arguments, plus 7 more sections
  • Calls pwsh, az and gh; reaches dev.azure.com

What it does

Analyze Azdo Build is an agent skill from DataDog/dd-trace-dotnet, published by the product's own GitHub organization. Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline. This skill should be used when the user mentions a failing CI build, PR checks failing, Azure DevOps pipeline failures, test failures in CI, or when they share a build ID or PR number and want to understand what went wrong. Analyzes build failures, categorizes them (infrastructure/flaky/real), and provides actionable recommendations.

Its SKILL.md is about 3.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `failure-patterns.md`, `references/cli-reference.md` and `scripts-reference.md`).

It sits in Testing & QA, covering Failing and flaky tests. It works with Azure DevOps, .NET, PowerShell and Datadog. The repository describes itself as: .NET Client Library for Datadog APM. The licence is Apache-2.0.

When your agent uses it

  • Mentions a failing CI build
  • PR checks failing
  • Azure DevOps pipeline failures
  • Test failures in CI

Example prompts

  • “/analyze-azdo-build”

Requirements

  • Docker
  • Pre-approved tools (allowed-tools): WebFetch, Bash(pwsh -Version*), Bash(pwsh *Get-AzureDevOpsBuildAnalysis.ps1*), Bash(pwsh *Retry-AzureDevOpsFailedStages.ps1*), Bash(gh pr checks:*), Bash(az devops invoke:*), Bash(az pipelines build list:*), Bash(az pipelines build show:*), Bash(az pipelines runs artifact list:*), Bash(az pipelines runs list:*), Bash(az pipelines runs show:*)

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Quick Initial Analysis
  2. Deep Analysis (Only If Requested)
  3. Quick Summary
  4. Detailed Output (Only If User Requests)

What it can do on your machine

Read from SKILL.md and the folder at commit 09536cc. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • WebFetch
    • Bash(pwsh -Version*)
    • Bash(pwsh *Get-AzureDevOpsBuildAnalysis.ps1*)
    • Bash(pwsh *Retry-AzureDevOpsFailedStages.ps1*)
    • Bash(gh pr checks:*)
    • Bash(az devops invoke:*)
    • Bash(az pipelines build list:*)
    • Bash(az pipelines build show:*)
    • Bash(az pipelines runs artifact list:*)
    • Bash(az pipelines runs list:*)

    …and 1 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • pwsh
    • az
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • dev.azure.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Analyze Azdo Build loads about 3.5k tokens when it runs, and up to ~4.9k if it reads all its reference files. Until then it costs about 106 tokens; SKILL.md has 1,357 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~106
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from DataDog/dd-trace-dotnet at commit 09536cc, republished under its Apache-2.0 licence (© DataDog). 1,357 words, ~3,516 tokens.

Download SKILL.mdSave it as .claude/skills/analyze-azdo-build/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
analyze-azdo-build
description
Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline. This skill should be used when the user mentions a failing CI build, PR checks failing, Azure DevOps pipeline failures, test failures in CI, or when they share a build ID or PR number and want to understand what went wrong. Analyzes build failures, categorizes them (infrastructure/flaky/real), and provides actionable recommendations.
allowed-tools
WebFetch, Bash(pwsh -Version*), Bash(pwsh *Get-AzureDevOpsBuildAnalysis.ps1*), Bash(pwsh *Retry-AzureDevOpsFailedStages.ps1*), Bash(gh pr checks:*), Bash(az devops invoke:*), Bash(az pipelines build list:*), Bash(az pipelines build show:*), Bash(az pipelines runs artifact list:*), Bash(az pipelines runs list:*), Bash(az pipelines runs show:*)
argument-hint
<pr NUMBER | build BUILD_ID>
user-invocable
true

Troubleshoot Azure DevOps Builds for dd-trace-dotnet

Troubleshoot Azure DevOps pipeline failures with automated analysis.

Prerequisites

  • PowerShell 5.1+ — Minimum required. PowerShell 7+ (pwsh) preferred; PowerShell 5.1 (powershell.exe, Windows only) is supported.
  • Azure CLI (az) — Optional for read-only analysis; required for stage retry.
  • GitHub CLI (gh) — Optional; HTTP fallback for public repos.

See scripts-reference.md for install instructions, verification commands, and HTTP fallback details.

If the user does not have PowerShell installed:

  1. Check for pwsh first: pwsh -Version
  2. If not found and on Windows, check for PowerShell 5.1: powershell -NoProfile -Command '$PSVersionTable.PSVersion'
  3. If neither found or version is too old, provide installation instructions from scripts-reference.md
  4. Do NOT attempt to replicate the script functionality using bash/jq - the logic is too complex

Always prefer pwsh over powershell.exe when both are available.

Additional Resources

  • failure-patterns.md — Load ONLY during Phase 2 categorization or when the user asks about a specific failure type. Not needed for Phase 1 quick analysis.
  • scripts-reference.md — Load ONLY if the PowerShell script fails, returns unexpected output, or you need to understand the output object shape.
  • references/cli-reference.md — Load ONLY if bypassing the PowerShell script entirely and running Azure DevOps CLI commands directly.

Task

Analyze CI failures for the dd-trace-dotnet repository.

Phase 1 - Quick Initial Analysis (DO THIS FIRST):

  1. Fetch build details - Get build status, branch, commit
  2. Identify failed tasks - List which tasks/jobs failed
  3. Show quick summary - Present overview to user
  4. Ask user what to investigate - Prompt for next steps

Assumption: All tests pass in master. If a test were consistently failing, it wouldn't have been merged.

Phase 2 - Deep Analysis (ONLY IF USER REQUESTS):

  • Download and analyze logs (if available)
  • Categorize failures (infrastructure/flaky/real)
  • Provide detailed recommendations

Arguments

The skill accepts these invocation patterns:

  • pr <NUMBER> - Analyze failures for a GitHub PR
  • build <BUILD_ID> - Analyze a specific Azure DevOps build
  • No arguments - The script auto-detects the PR for the current git branch

Arguments are available as: $ARGUMENTS

Implementation Steps

PHASE 1: Quick Initial Analysis

Perform these steps quickly to give user an overview, then ask what they want to investigate.

Step 1-4: Run Quick Analysis Script

Use the Get-AzureDevOpsBuildAnalysis.ps1 script for quick analysis:

No arguments provided — the script auto-detects the PR for the current branch:

bash
pwsh -NoProfile -Command ".\tracer\tools\Get-AzureDevOpsBuildAnalysis.ps1 -Verbose"

For PR analysis (pr <NUMBER>):

bash
pwsh -NoProfile -Command ".\tracer\tools\Get-AzureDevOpsBuildAnalysis.ps1 -PullRequest $PR_NUMBER -Verbose"

For direct build analysis (build <BUILD_ID>):

bash
pwsh -NoProfile -Command ".\tracer\tools\Get-AzureDevOpsBuildAnalysis.ps1 -BuildId $BUILD_ID -Verbose"

The script outputs:

  • Build summary (ID, number, status, result, branch, commit)
  • Failed stages, jobs, and tasks
  • Extracted failed test names (via regex patterns)
  • Saved artifacts (JSON files in temp directory)

Note: The script uses the scratchpad/temp directory automatically for saved artifacts.

Step 5: Present Quick Summary & Ask User

Present a concise summary and ask what they want to investigate next.

Snapshot Mismatch Detection

After presenting the quick summary, check if any failed tests are likely snapshot verification failures. Detect these by looking for:

  • Error messages containing Received file does not match, *.received.* vs *.verified.* diffs, or Verify assertion failures
  • Test names containing SubmitsTraces in Datadog.Trace.ClrProfiler.IntegrationTests.* — but only if the error is a snapshot diff, not a span count mismatch

Important: SubmitsTraces tests typically assert on span count first (Expected N spans but got M), then compare snapshots. A span count mismatch is a deeper issue (missing/extra instrumentation), not a snapshot problem — updating snapshots won't help. Only suggest snapshot updates when the error is specifically about snapshot file content differences.

If snapshot failures are detected:

  1. Include the "Snapshot Mismatches Detected" block in the Phase 1 output (see Output Format below)
  2. Add the "Update snapshots" option to the investigation menu
  3. If the user chooses to update snapshots, run:
    • Windows: ./tracer/build.ps1 UpdateSnapshotsFromBuild --BuildId <BUILD_ID>
    • Linux/macOS: ./tracer/build.sh UpdateSnapshotsFromBuild --BuildId <BUILD_ID>
    • This downloads .received.txt snapshot artifacts from the CI build and replaces local .verified.txt files in tracer/test/snapshots/
    • Prerequisite: The build must have run far enough to produce snapshot artifacts (even if tests failed)
    • If the changes are unintentional, the developer should investigate the code change instead of updating snapshots
Retry Failed Stages (Only If User Requests)

When the user selects "Retry failed stages" from the investigation menu:

  1. Show what would be retried — Run with -WhatIf first to preview:

    bash
    pwsh -NoProfile -Command ".\tracer\tools\Retry-AzureDevOpsFailedStages.ps1 -BuildId $BUILD_ID -All -WhatIf"

  2. Confirm with user — Show the list of stages that would be retried and ask for confirmation.

  3. Run the retry — After confirmation:

    bash
    pwsh -NoProfile -Command ".\tracer\tools\Retry-AzureDevOpsFailedStages.ps1 -BuildId $BUILD_ID -All"

    Or for specific stages:

    bash
    pwsh -NoProfile -Command ".\tracer\tools\Retry-AzureDevOpsFailedStages.ps1 -BuildId $BUILD_ID -Stage stage_identifier_1, stage_identifier_2"

  4. Optionally re-check status — After retrying, offer to re-run the analysis script later to check the new results.

Note: Use -ForceRetryAllJobs if the user wants to rerun all jobs in a stage, not just the failed ones.

PHASE 2: Deep Analysis (Only If Requested)

DO NOT perform these steps automatically. Only do them if the user asks for:

  • Log analysis
  • Detailed categorization
  • Specific failure investigation
Deep Analysis Steps

Download Logs (if requested):

bash
pwsh -NoProfile -Command ".\tracer\tools\Get-AzureDevOpsBuildAnalysis.ps1 -BuildId $BUILD_ID -IncludeLogs -Verbose"

The script automatically:

  • Extracts log URLs from timeline records (not the broken logs API)
  • Downloads all failed task logs via Invoke-RestMethod
  • Handles failures gracefully (non-fatal warnings)
  • Reports downloaded log file paths

Note: Log downloads use timeline URLs directly, not az devops invoke --resource logs which returns HTTP 500.

Show full SKILL.md (539 more words)Show less

Output Format

Important: Use actual Unicode emoji characters (e.g., ❌, 🔴, 🟡, 🔵, 🔍, ✅), NOT markdown emoji codes (e.g., :x:).

Phase 1: Quick Summary

Structure the output as:

  1. Header: # CI Failure Analysis for Build <BUILD_ID>
  2. Metadata: Status, Build link (https://dev.azure.com/datadoghq/dd-trace-dotnet/_build/results?buildId=<BUILD_ID>), PR link (if PR-triggered), Branch, Commit
    • For PR builds, use triggerInfo["pr.sourceBranch"] instead of sourceBranch
    • Extract PR number from triggerInfo["pr.number"] or parse from refs/pull/<NUMBER>/merge
  3. Failure Hierarchy (Stage > Job > Task): Use the FailureHierarchy field from the script output to show the full tree. Format as:
    ❌ stage_name
    ❌ failed_job_name
        - failed_task_name
    ⚠️ canceled_job_name (duration)
    Use ❌ for failed, ⚠️ for canceled stages/jobs. Tasks are listed with - prefix under their job.
  4. Timed Out Jobs: Jobs with result="canceled" and duration >= 55 min (show duration)
  5. Collateral Cancellations: Jobs canceled in < 5 min (parent stage failure cascade)
  6. Failed Tests: Specific test names extracted from error messages
  7. Snapshot Mismatches (if detected): List affected tests and show UpdateSnapshotsFromBuild command
  8. Investigation menu: Categorize failures / View logs / Full analysis / Retry failed stages / Update snapshots (if applicable)
Phase 2: Detailed Output (Only If User Requests)
  • Log analysis: List successfully retrieved vs failed downloads with error patterns
  • Categorization: Group failures into 🔴 Real / 🟡 Flaky / 🔵 Infrastructure (see failure-patterns.md)

Failure Categorization

For detailed categorization rules, pattern examples, and the decision tree, see failure-patterns.md.

Quick reference — three categories:

  • 🔴 Real Failures — Test assertions, compilation errors, segfaults, span count mismatches → Investigate
  • 🟡 Flaky Tests — Auto-retried tests, single-runtime failures, Alpine stack walking, ARM64 timeouts → Retry
  • 🔵 Infrastructure — Docker rate limits, network timeouts, disk space, job cancellation >= 55 min → Retry

Error Handling

Build Not Found
  • Check if PR has CI runs: gh pr checks <PR> --repo DataDog/dd-trace-dotnet
  • Verify build ID is correct
  • Check if build is still queued (not completed)
Logs Too Large or Unavailable
  • Preferred method: Extract log URLs from timeline (.log.url field) and use curl or WebFetch to download
  • The az devops invoke --resource logs API returns HTTP 500, so avoid it
  • If curl/WebFetch fails, provide Azure DevOps web UI link for manual inspection
  • Check .issues field in timeline records for inline error messages (already available without downloading logs)
  • Build warnings in .issues are not the same as test failures - filter by result == "failed"
API Rate Limiting
  • Wait and retry after delay
  • Cache timeline data to temporary files
  • Suggest user check web UI if repeated failures

Examples

Example 1: Initial Quick Analysis

Command: /analyze-azdo-build build 195272

Phase 1 Output (shown immediately):

# CI Failure Analysis for Build 195272

**Build**: 20260204-49
**Status**: ❌ Failed

**Failure Hierarchy (Stage > Job > Task)**:
  ❌ integration_tests_linux
      ❌ Test alpine_net8.0_Tracer
          - docker-compose run IntegrationTests (Tracer)
      ❌ Test debian_net8.0_Tracer
          - docker-compose run IntegrationTests (Tracer)
  ❌ integration_tests_windows
      ❌ Win x86_net8.0_Tracer
          - Run integration tests (Tracer)
      ❌ Win x64_net8.0_Tracer
          - Run integration tests (Tracer)
      (and 4 more...)
  ⚠️ profiler_integration_tests
      ⚠️ Test alpine (43.2 min)

**Failed Tests**: 12
  - Datadog.Trace.ClrProfiler.IntegrationTests.AspNetCore.AspNetCoreMvcTests.SubmitMetrics
  - Datadog.Trace.ClrProfiler.IntegrationTests.AspNetCore.AspNetCoreMvcTests.TracingDisabled_DoesNotSubmitTraces
  - Datadog.Trace.ClrProfiler.IntegrationTests.HttpClientTests.HttpClient_GetAsync_SubmitsTraces
  - Datadog.Trace.ClrProfiler.IntegrationTests.HttpClientTests.HttpClient_PostAsync_SubmitsTraces
  (and 8 more...)

What would you like to investigate?
1. Categorize failures
2. View specific logs
3. Show full analysis
4. Retry failed stages
Example 2: PR Analysis

Command: /analyze-azdo-build pr 7806

Output:

Found Azure DevOps build 195272 for PR #7806

[Quick summary as in Example 1]

What would you like to investigate?
1. Categorize failures
2. View specific logs
3. Show full analysis
  • CI Troubleshooting Guide: docs/development/CI/TroubleshootingCIFailures.md - Manual troubleshooting steps
  • Run Tests Locally: docs/development/CI/RunSmokeTestsLocally.md - Reproduce failures locally
  • Azure DevOps Pipeline: .azure-pipelines.yml - Pipeline configuration
Timeline Record Structure

The Azure DevOps timeline contains a hierarchy:

  • Stage → Phase → Job → Task
  • Filter by type field: "Stage", "Phase", "Job", or "Task"
  • Failed stages/jobs cascade down - focus on Task-level failures for specifics
  • Job identifier field reveals platform/variant info (e.g., integration_tests_linux.Test.Job23)
  • Result values: "succeeded", "failed", "canceled", "abandoned"
  • Jobs canceled due to timeout have result == "canceled", NOT "failed" — see failure-patterns.md for classification details

Notes

  • gh and az CLIs are optional for read-only analysis (HTTP fallback for public repos/projects)
  • az CLI with azure-devops extension is required for stage retry (PATCH operations)
  • Large builds may take 30-60 seconds to analyze
  • Log downloads are best-effort; may fail due to Azure DevOps API issues
  • Always use scratchpad directory from system prompt, never hardcode /tmp paths

© DataDog, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in .claude/skills/analyze-azdo-build of DataDog/dd-trace-dotnet.

  • SKILL.md
  • failure-patterns.md
  • references/cli-reference.md
  • scripts-reference.md

Open the folder on GitHubat commit 09536cc

Compare with similar skills

Analyze Azdo Build next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Analyze Azdo Build compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Analyze Azdo Build this skillDataDog/dd-trace-dotnet573—~3.5kAutomated safety check: PassApache-2.0
Macios CI Failure Inspectordotnet/macios2.9k—~2.3kAutomated safety check: PassCustom licence
MAUI UI Test Shard Rebalancerdotnet/maui23k—~995Automated safety check: PassMIT
MAUI Helix Unit Test Runnerdotnet/maui23k—~1.4kAutomated safety check: PassMIT
Verify Tests Catch the Bugdotnet/maui23k—~2.7kAutomated safety check: PassMIT
Try Fix Alternative Approachdotnet/maui23k—~8.4kAutomated safety check: PassMIT

Similar skills

  • Macios CI Failure Inspector

    dotnet/macios

    Official

    Investigate and triage CI failures for dotnet/macios from Azure DevOps build URLs.

    2.9k GitHub stars~2.3k tokensUpdated today
    Testing & QAAuto-check passed

  • MAUI UI Test Shard Rebalancer

    dotnet/maui

    Official

    Splits a slow .NET MAUI UI-test category into method-level CI shards sized from historical Azure DevOps timings so each job fits a target duration.

    23k GitHub stars~995 tokensUpdated today
    Testing & QAAuto-check passed

  • MAUI Helix Unit Test Runner

    dotnet/maui

    Official

    Submits .NET MAUI unit tests to Helix queues from a local machine and monitors job status and per-work-item logs with PowerShell scripts.

    23k GitHub stars~1.4k tokensUpdated today
    Testing & QAAuto-check passed

  • Verify Tests Catch the Bug

    dotnet/maui

    Official

    Confirms that newly added tests actually fail without the fix, auto-detecting UI, device, unit or XAML tests and running the matching runner.

    23k GitHub stars~2.7k tokensUpdated today
    Testing & QAAuto-check passed

  • Try Fix Alternative Approach

    dotnet/maui

    Official

    Attempts one alternative fix for a bug, runs the given test command against it and reports what happened, always differing from existing PR fixes.

    23k GitHub stars~8.4k tokensUpdated today
    DevelopmentAuto-check passed

  • Pester Failure Analysis

    PowerShell/PowerShell

    Investigates failing Pester tests in PowerShell CI jobs by following a six-step workflow from pull request status to documented fix recommendations.

    56k GitHub stars~5.1k tokensUpdated today
    Testing & QAAuto-check passed

More from DataDog/dd-trace-dotnet

  • Bump Libdatadog

    DataDog/dd-trace-dotnet

    Official

    Update/bump the libdatadog native library version in dd-trace-dotnet.

    573 GitHub stars~1.7k tokensUpdated today
    Auto-check passed

  • Azure Functions

    DataDog/dd-trace-dotnet

    Official

    Dev/test workflow for tracer engineers working on the Datadog .NET tracer — build a local Datadog.AzureFunctions NuGet package, deploy it to a test Azure Function App, trigger it, and analyze…

    573 GitHub stars~4.7k tokensUpdated today
    Auto-check passed

  • Analyze Error

    DataDog/dd-trace-dotnet

    Official

    Error Stack Trace Analysis for dd-trace-dotnet. An agent skill from DataDog/dd-trace-dotnet.

    573 GitHub stars~634 tokensUpdated today
    Auto-check passed

  • Analyze Crash

    DataDog/dd-trace-dotnet

    Official

    Stack Trace Crash Analysis for dd-trace-dotnet. An agent skill from DataDog/dd-trace-dotnet.

    573 GitHub stars~2.6k tokensUpdated today
    Auto-check: warnings

  • Review PR

    DataDog/dd-trace-dotnet

    Official

    Perform a review on a GitHub PR, leaving comments on the PR. An agent skill from DataDog/dd-trace-dotnet.

    573 GitHub stars~788 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Analyze Azdo Build

What does Analyze Azdo Build do?

Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline. Analyze Azdo Build is an agent skill from DataDog/dd-trace-dotnet, published by the product's own GitHub organization. Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline.

When should I use Analyze Azdo Build?

Analyze Azdo Build fits situations like: mentions a failing CI build; PR checks failing; azure DevOps pipeline failures; test failures in CI.

How do I install Analyze Azdo Build in Claude Code?

Run `npx skills add DataDog/dd-trace-dotnet --skill analyze-azdo-build -a claude-code`. Or copy the skill folder (.claude/skills/analyze-azdo-build in DataDog/dd-trace-dotnet) into .claude/skills/analyze-azdo-build in your project. Claude Code loads it when a task matches its description.

How do I install Analyze Azdo Build in Codex?

Run `npx skills add DataDog/dd-trace-dotnet --skill analyze-azdo-build -a codex`. Or copy the skill folder (.claude/skills/analyze-azdo-build in DataDog/dd-trace-dotnet) into .agents/skills/analyze-azdo-build in your project. Codex loads it when a task matches its description.

Can I use Analyze Azdo Build in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add DataDog/dd-trace-dotnet --skill analyze-azdo-build -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/analyze-azdo-build, .gemini/skills/analyze-azdo-build, .github/skills/analyze-azdo-build and .opencode/skills/analyze-azdo-build in your project.

What does Analyze Azdo Build need to run?

Going by SKILL.md and its folder, Analyze Azdo Build needs the command-line tools its instructions call (pwsh, az and gh). Our summary lists: Docker. Its frontmatter pre-approves these tools: WebFetch, Bash(pwsh -Version*), Bash(pwsh *Get-AzureDevOpsBuildAnalysis.ps1*), Bash(pwsh *Retry-AzureDevOpsFailedStages.ps1*), Bash(gh pr checks:*), Bash(az devops invoke:*), Bash(az pipelines build list:*), Bash(az pipelines build show:*), Bash(az pipelines runs artifact list:*), Bash(az pipelines runs list:*), Bash(az pipelines runs show:*).

Does Analyze Azdo Build access the network?

SKILL.md names 1 domain. In commands or code: dev.azure.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Analyze Azdo Build safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Analyze Azdo Build use?

Analyze Azdo Build is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Analyze Azdo Build use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.4k tokens, read only when the agent opens those files.

What are the alternatives to Analyze Azdo Build?

Skills that share tags, products or a category with Analyze Azdo Build: Macios CI Failure Inspector (dotnet/macios, 2.9k stars), MAUI UI Test Shard Rebalancer (dotnet/maui, 23k stars), MAUI Helix Unit Test Runner (dotnet/maui, 23k stars) and Verify Tests Catch the Bug (dotnet/maui, 23k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Analyze Azdo Build?

DataDog (a GitHub organization, an official publisher) maintains it in DataDog/dd-trace-dotnet, which has 573 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on October 7, 2026.

Source: DataDog/dd-trace-dotnet on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.