ci-analysis skill: MSBuild guidance, merge commit shortcut, MCP alternatives (#124359)

Follow-up to #124240 with three improvements to the ci-analysis skill:

### Changes

**MSBuild cross-platform guidance** (build-progression-analysis.md)
- Added anti-pattern warning about MSBuild property path separator
differences (`;` vs `:`) when comparing binlogs across Windows/Linux
Helix queues
- This is a common false positive in build progression analysis

**Merge commit shortcut for target SHA extraction**
(build-progression-analysis.md)
- Added Step 2b shortcut: `gh api
repos/{owner}/{repo}/git/commits/{sourceVersion} --jq '.parents[0].sha'`
- Extracts target branch HEAD from the merge commit's first parent —
much simpler than parsing checkout logs
- Noted caveat: only works for the latest build (GitHub recomputes merge
ref on each push)
- Added `get_commit` MCP tool as alternative when available

**Inline MCP tool alternatives** (all 4 files)
- Added `pull_request_read` as alternative to `gh pr checks` in SKILL.md
- Added `search_issues` MCP note in azdo-helix-reference.md
- Added `get_commit` MCP note in build-progression-analysis.md
- Reframed azure-cli.md with one-sentence MCP-first preamble

All changes are minimal inline additions — no structural changes to the
skill.

Author: lewing

.github/skills/ci-analysis/SKILL.md

@@ -9,7 +9,7 @@ Analyze CI build status and test failures in Azure DevOps and Helix for dotnet r
 
 > 🚨 **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) → run the script → read the human-readable output + `[CI_ANALYSIS_SUMMARY]` JSON → synthesize recommendations yourself. The script collects data; you generate the advice.
+**Workflow**: Gather PR context (Step 0) → run the script → read the human-readable output + `[CI_ANALYSIS_SUMMARY]` JSON → synthesize recommendations yourself. The script collects data; you generate the advice. For supplementary investigation beyond the script, MCP tools (AzDO, Helix, GitHub) provide structured access when available; the script and `gh` CLI work independently when they're not.
 
 ## When to Use This Skill
 
@@ -75,7 +75,7 @@ The script operates in three distinct modes depending on what information you ha
 ## What the Script Does
 
 ### PR Analysis Mode (`-PRNumber`)
-1. Discovers AzDO builds associated with the PR (via `gh pr checks` — finds failing builds and one non-failing build as fallback; for full build history, use `azure-devops-pipelines_get_builds`)
+1. Discovers AzDO builds associated with the PR (via `gh pr checks`, or `pull_request_read` with method `get_status` — finds failing builds and one non-failing build as fallback; for full build history, use `azure-devops-pipelines_get_builds`)
 2. Fetches Build Analysis for known issues
 3. Gets failed jobs from Azure DevOps timeline
 4. **Separates canceled jobs from failed jobs** (canceled may be dependency-canceled or timeout-canceled)

.github/skills/ci-analysis/references/azdo-helix-reference.md

@@ -80,7 +80,7 @@ Some repositories (e.g., dotnet/sdk) run tests directly on the build agent. The
 - `Known Build Error` - Used by Build Analysis across all dotnet repositories
 - Search syntax: `repo:<owner>/<repo> is:issue is:open label:"Known Build Error" <test-name>`
 
-Example searches:
+Example searches (use `search_issues` when GitHub MCP is available, `gh` CLI otherwise):
 ```bash
 # Search in runtime
 gh issue list --repo dotnet/runtime --label "Known Build Error" --search "FileSystemWatcher"

.github/skills/ci-analysis/references/azure-cli.md

@@ -1,5 +1,7 @@
 # Deep Investigation with Azure CLI
 
+The AzDO MCP tools (`azure-devops-pipelines_*`) handle most pipeline queries directly. This reference covers the Azure CLI fallback for cases where MCP tools are unavailable or the endpoint isn't exposed (e.g., downloading artifacts, inspecting pipeline definitions).
+
 When the CI script and GitHub APIs aren't enough (e.g., investigating internal pipeline definitions or downloading build artifacts), use the Azure CLI with the `azure-devops` extension.
 
 > 💡 **Prefer `az pipelines` / `az devops` commands over raw REST API calls.** The CLI handles authentication, pagination, and JSON output formatting. Only fall back to manual `Invoke-RestMethod` calls when the CLI doesn't expose the endpoint you need (e.g., build timelines). The CLI's `--query` (JMESPath) and `-o table` flags are powerful for filtering without extra scripting.

.github/skills/ci-analysis/references/build-progression-analysis.md

@@ -46,7 +46,23 @@ Each build's `triggerInfo` contains `pr.sourceSha` — the PR's HEAD commit when
 
 > ⚠️ **Target branch moves between builds.** Each build merges `pr.sourceSha` into the target branch HEAD *at the time the build starts*. If `main` received new commits between build N and N+1, the two builds merged against different baselines — even if `pr.sourceSha` is the same. Always extract the target branch HEAD to detect baseline shifts.
 
-### Step 2b: Extract the target branch HEAD from checkout logs
+### Step 2b: Extract the target branch HEAD
+
+**Shortcut for the latest build — use the GitHub merge commit:**
+
+For the current/latest build, the merge ref (`refs/pull/{PR}/merge`) is available via the GitHub API. The merge commit's first parent is the target branch HEAD at the time GitHub computed the merge:
+
+```
+gh api repos/{OWNER}/{REPO}/git/commits/{sourceVersion} --jq '.parents[0].sha'
+```
+
+Or with GitHub MCP: `get_commit` with the `sourceVersion` SHA — the first parent in the response is the target branch HEAD.
+
+Where `sourceVersion` is the merge commit SHA from the AzDO build (not `pr.sourceSha`). This is simpler than parsing checkout logs.
+
+> ⚠️ **This only works for the latest build.** GitHub recomputes `refs/pull/{PR}/merge` on each push, so the merge commit changes. For historical builds in a progression analysis, the merge ref no longer reflects what was built — use the checkout log method below.
+
+**For historical builds — extract from checkout logs:**
 
 The AzDO build API doesn't expose the target branch SHA. Extract it from the checkout task log.
 
@@ -207,3 +223,5 @@ Use target-branch comparison first to confirm the failure is PR-related. Use bui
 > ❌ **Don't make fix recommendations from progression alone.** "Build N passed and build N+1 failed after adding commit C" is a fact worth reporting. "Therefore revert commit C" is a judgment that requires more context than the agent has — the commit may be addressing a critical review concern, fixing a different bug, or partially correct.
 
 > ❌ **Don't assume earlier passing builds prove the original approach was complete.** A build may pass because it didn't change enough to trigger the failing test scenario. The reviewer who requested additional changes may have identified a real gap.
+
+> ❌ **Don't assume MSBuild changes only affect the platform you're looking at.** MSBuild properties, conditions, and targets are shared infrastructure. A commit that changes a condition, moves a property, or modifies a restore flag can impact any platform that evaluates the same code path. When a commit touches MSBuild files, verify its impact across all platforms — don't assume it's scoped to the one you're investigating.