analyze-azdo-build
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.
71
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly defines a narrow, specific domain (Azure DevOps CI build failure analysis for a specific pipeline), provides comprehensive trigger terms that match natural developer language, and explicitly states both what the skill does and when it should be used. The categorization detail (infrastructure/flaky/real) adds valuable specificity about the skill's analytical capabilities.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple concrete actions: analyze build failures, categorize them into specific categories (infrastructure/flaky/real), and provide actionable recommendations. Also names the specific pipeline (dd-trace-dotnet) and platform (Azure DevOps). | 3 / 3 |
Completeness | Clearly answers both 'what' (analyzes Azure DevOps CI build failures, categorizes them, provides recommendations) and 'when' (explicit 'Use when' clause listing multiple trigger scenarios including failing CI builds, PR checks, build IDs, etc.). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'failing CI build', 'PR checks failing', 'Azure DevOps pipeline failures', 'test failures in CI', 'build ID', 'PR number', 'what went wrong'. These are highly natural phrases a developer would use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific pipeline name (dd-trace-dotnet), specific platform (Azure DevOps), and specific task (CI build failure analysis with categorization). Very unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, highly actionable skill with excellent workflow clarity and concrete executable commands throughout. Its main weakness is length — several sections (Timeline Record Structure, detailed output format specs, snapshot detection heuristics) could be moved to reference files to improve conciseness and progressive disclosure. The two-phase design with user decision points is well-executed and the error handling is thorough.
Suggestions
Move the 'Timeline Record Structure' section and detailed output format specification to scripts-reference.md or a new output-format.md to reduce the main file's token footprint.
Consolidate the repeated reminders that Phase 2 is 'only if requested' into a single clear statement at the phase boundary rather than repeating it in multiple places.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long (~250 lines) and includes some redundant information (e.g., repeating that Phase 2 is only if requested multiple times, explaining timeline record structure that could be in a reference file). However, most content is task-specific and not explaining concepts Claude already knows. Some sections like 'Timeline Record Structure' and detailed snapshot mismatch detection logic could be trimmed or moved to reference files. | 2 / 3 |
Actionability | Excellent actionability throughout — provides exact bash commands with proper PowerShell invocations, specific flag combinations (-WhatIf, -IncludeLogs, -Verbose, -All), concrete output format examples, and copy-paste ready commands for every scenario (PR, build ID, no args, retry, snapshot update). The examples section shows realistic input/output pairs. | 3 / 3 |
Workflow Clarity | The two-phase workflow is clearly sequenced with explicit steps. The retry workflow includes a WhatIf preview step before execution (validation checkpoint), user confirmation gate, and optional re-check. Phase 1 has clear steps 1-5 with a decision point asking the user what to investigate. Error handling covers multiple failure modes with specific recovery actions. | 3 / 3 |
Progressive Disclosure | References to failure-patterns.md, scripts-reference.md, and cli-reference.md are well-signaled with clear loading conditions (e.g., 'Load ONLY during Phase 2'). However, the SKILL.md itself is quite long and includes content that could be offloaded — the Timeline Record Structure section, detailed snapshot mismatch detection logic, and the full output format specification could live in reference files. Without bundle files to verify, the references appear well-structured but the main file retains too much detail. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- DataDog/dd-trace-dotnet
- Commit
6249bb4
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.