ci-analysis

Azure DevOps and Helix CI Analysis

Analyze CI build status and test failures in Azure DevOps and Helix for dotnet repositories (runtime, sdk, aspnetcore, roslyn, and more).

🚨 NEVER use gh pr review --approve or --request-changes. Only --comment is allowed. Approval and blocking are human-only actions.

Workflow: Gather PR context (Step 0) → collect failure data → synthesize recommendations. The agent drives the investigation; tools provide the data.

Accessing services: Start with MCP tools if available. Get repo-specific CI guidance early — it provides the investigation workflow, tool selection, failure patterns, and classification algorithm for that repo. The guidance evolves with the toolset, so it always reflects current capabilities.

If MCP tools aren't loaded, the Helix CLI tool provides the same capabilities via bash with progressive discovery.

For AzDO, multiple tool sets may exist for different organizations — match the org in the build URL to the correct tools (see references/azdo-helix-reference.md). If queries return null, check the org before trying other approaches. For complex investigations, track what you've tried in SQL to avoid repeating failed approaches.

When to Use This Skill

• Checking CI status ("is CI passing?", "why is CI red?")
• Investigating CI failures or determining merge readiness
• Debugging Helix test issues or build errors
• URLs containing dev.azure.com, helix.dot.net, or GitHub PR links with failing checks
• Questions like "retry CI", "rerun tests", "test failures", "checks failing"
• Investigating canceled or timed-out jobs for recoverable results

Not for: GitHub Actions workflows, non-Helix repos, or build performance (use binlog analysis).

💡 Per-repo CI patterns differ significantly. Get repo-specific guidance early — it tells you which tools to use, what log patterns to search for, and what gotchas to expect. This is the fastest path and prevents wasted calls.