Update 3 skills: ci-analysis-flow-analysis-flow-tracing (#4)

* Update 3 skills: ci-analysis-flow-analysis-flow-tracing

Synced from copilot-skills

* Add maestro MCP server to plugin.json

Required by flow-analysis and flow-tracing skills for subscription
health, build freshness, and codeflow management queries.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address review feedback: fix deadlock, timeout, doc accuracy

- flow-health.cs: Read stdout/stderr async to prevent deadlock on
  full stderr buffer; handle WaitForExit timeout by killing process
- Get-SdkVersionTrace.ps1: Normalize preview.1→preview1 for VMR
  branch names; fix fallback text to reference <Sha> element not
  attribute; replace MCP tool name with generic guidance
- servicing-topology.md: Fix Sha attribute→<Sha> element; fix
  source-manifest.json path to src/source-manifest.json

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* flow-analysis: integrate codeflow_statuses, cross-validation, force-trigger

Trained from sessions analyzing Maestro bookkeeping bug. Changes:
- Add Step 0: codeflow statuses as fast-path entry point
- Expand forward flow diagnosis with bookkeeping bug pattern
- Add cross-validation via validate option on subscription health
- Update remediation: smart trigger, force-trigger via MCP

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Update ci-analysis, flow-analysis, flow-tracing from copilot-skills

- ci-analysis: remove slop, tighten reference docs, drop ADO MCP dependency
- flow-analysis: sync latest content
- flow-tracing: sync latest content

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Update ci-analysis: remove binlog-comparison reference (extracted to separate skill)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address PR review feedback

- flow-health.cs: properly async (WaitForExitAsync), SemaphoreSlim throttle,
  gh failure tracking with non-zero exit, auth check at startup,
  forward-flow ci-red count fix in summary
- Get-SdkVersionTrace.ps1: Invoke-RestMethod instead of Invoke-WebRequest,
  single-match constraint in Find-ComponentInManifest,
  1xx GA branch fallback to main, gh api fallback text
- vmr-build-topology.md: HttpClient instead of Invoke-WebRequest in example

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Remove ADO MCP servers from plugin.json

The Helix MCP (hlx) now provides all the AzDO pipeline and artifact
functionality that ci-analysis needs. The separate ado-dnceng and
ado-dnceng-public MCP servers are no longer required.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address second round of review feedback

- flow-health.cs: use try/catch TimeoutException instead of ContinueWith
- Get-SdkVersionTrace.ps1: URL-encode branch name in gh api call
- ci-analysis SKILL.md: fix dangling binlog-comparison skill reference

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: lewing

plugins/dotnet-dnceng/plugin.json

@@ -15,28 +15,6 @@
   ],
   "skills": "./skills",
   "mcpServers": {
-    "ado-dnceng-public": {
-      "command": "npx",
-      "args": [
-        "-y",
-        "@azure-devops/mcp",
-        "dnceng-public"
-      ],
-      "env": {
-        "AZURE_DEVOPS_AUTH_METHOD": "azure-cli"
-      }
-    },
-    "ado-dnceng": {
-      "command": "npx",
-      "args": [
-        "-y",
-        "@azure-devops/mcp",
-        "dnceng"
-      ],
-      "env": {
-        "AZURE_DEVOPS_AUTH_METHOD": "azure-cli"
-      }
-    },
     "hlx": {
       "command": "dotnet",
       "args": [
@@ -56,6 +34,14 @@
     "mihubot": {
       "type": "http",
       "url": "https://mihubot.xyz/mcp"
+    },
+    "maestro": {
+      "command": "dotnet",
+      "args": [
+        "dnx",
+        "--yes",
+        "lewing.maestro.mcp"
+      ]
     }
   }
 }

plugins/dotnet-dnceng/skills/ci-analysis/SKILL.md

@@ -53,8 +53,6 @@ For full parameter reference and mode details, see [references/script-modes.md](
 
 ## Step 0: Gather Context (before running anything)
 
-Context changes how you interpret every failure. **Don't skip this.**
-
 1. **Read PR metadata** — title, description, author, labels, linked issues
 2. **Classify the PR type**:
 
@@ -121,7 +119,7 @@ Lead with a 1-2 sentence verdict, then the summary table, then detail bullets (o
 - **Recommendation generation**: [references/recommendation-generation.md](references/recommendation-generation.md)
 - **Analysis workflow (Steps 1–3)**: [references/analysis-workflow.md](references/analysis-workflow.md)
 - **Helix artifacts & binlogs**: [references/helix-artifacts.md](references/helix-artifacts.md)
-- **Binlog comparison**: [references/binlog-comparison.md](references/binlog-comparison.md)
+- **Binlog comparison**: For cross-build binlog diffs, use deep investigation techniques from [references/delegation-patterns.md](references/delegation-patterns.md)
 - **Build progression analysis**: [references/build-progression-analysis.md](references/build-progression-analysis.md)
 - **Subagent delegation**: [references/delegation-patterns.md](references/delegation-patterns.md)
 - **Azure CLI investigation**: [references/azure-cli.md](references/azure-cli.md)

plugins/dotnet-dnceng/skills/ci-analysis/references/azure-cli.md

@@ -4,7 +4,7 @@ The AzDO MCP tools handle most pipeline queries directly. This reference covers
 
 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.
+> 💡 Use `az pipelines` before raw REST. `--query` (JMESPath) and `-o table` are useful for filtering.
 
 ## Checking Authentication
 

plugins/dotnet-dnceng/skills/ci-analysis/references/binlog-comparison.md

@@ -12,9 +12,7 @@ When the current build is failing, the PR's build history can reveal whether the
 
 ### Step 0: Start with the recent builds
 
-Don't try to analyze the full build history upfront — especially on large PRs with many pushes. Start with the most recent N builds (5-8), present the progression table, and let the user decide whether to dig deeper into earlier builds.
-
-On large PRs, the user is usually iterating toward a solution. The recent builds are the most relevant. Offer: "Here are the last N builds — the pass→fail transition was between X and Y. Want me to look at earlier builds?"
+Start with the 5-8 most recent builds. Present the progression table and offer to look at earlier builds if needed.
 
 ### Step 1: List builds for the PR
 
@@ -24,7 +22,7 @@ On large PRs, the user is usually iterating toward a solution. The recent builds
 
 Query AzDO for builds on `refs/pull/{PR}/merge` branch, sorted by queue time descending, top 20, in the `public` project. The response includes `triggerInfo` with `pr.sourceSha` — the PR's HEAD commit for each build.
 
-> 💡 Key parameters: `branchName: "refs/pull/{PR}/merge"`, `queryOrder: "QueueTimeDescending"`, `top: 20`, project `public` (for dnceng-public org).
+> Key parameters: `branchName: "refs/pull/{PR}/merge"`, `queryOrder: "QueueTimeDescending"`, `top: 20`, project `public` (for dnceng-public org).
 
 **Without MCP (fallback):**
 ```powershell

plugins/dotnet-dnceng/skills/ci-analysis/references/build-progression-analysis.md

@@ -1,6 +1,6 @@
 # Subagent Delegation Patterns
 
-CI investigations involve repetitive, mechanical work that burns main conversation context. Delegate data gathering to subagents; keep interpretation in the main agent.
+Delegate data gathering to subagents; keep interpretation in main.
 
 ## Pattern 1: Scanning Multiple Console Logs
 

plugins/dotnet-dnceng/skills/ci-analysis/references/delegation-patterns.md

@@ -2,14 +2,12 @@
 
 ## Result Categories
 
-**Known Issues section**: Failures matching existing GitHub issues — these are tracked and being investigated.
+**Known Issues section**: Failures matching existing GitHub issues.
 
-**Build Analysis check status**: The "Build Analysis" GitHub check is **green** only when *every* failure is matched to a known issue. If it's **red**, at least one failure is unaccounted for — do NOT claim "all failures are known issues" just because some known issues were found. You must verify each failing job is covered by a specific known issue before calling it safe to retry.
+**Build Analysis check status**: Green = *every* failure matched a known issue. Red = at least one unmatched. Verify each failing job is covered before calling it safe to retry.
 
 **Canceled/timed-out jobs**: Jobs canceled due to earlier stage failures or AzDO timeouts. Dependency-canceled jobs don't need investigation. **Timeout-canceled jobs may have all-passing Helix results** — the "failure" is just the AzDO job wrapper timing out, not actual test failures. To verify: get the Helix job pass/fail summary for each job in the timed-out build (include passed work items). If all work items passed, the build effectively passed.
 
-> ❌ **Don't dismiss timed-out builds.** A build marked "failed" due to a 3-hour AzDO timeout can have 100% passing Helix work items. Check before concluding it failed.
-
 **PR Change Correlation**: Files changed by PR appearing in failures — likely PR-related.
 
 **Build errors**: Compilation failures need code fixes.

plugins/dotnet-dnceng/skills/ci-analysis/references/failure-interpretation.md

@@ -30,8 +30,6 @@ The `Files` array contains artifacts with `FileName` and `Uri` properties.
 - **Standard unit tests** → Console logs only, no binlogs
 - **Crash failures** (exit code 134) → Core dumps may be present
 
-Always query the specific work item to see what's available rather than assuming a fixed structure.
-
 ## Common Artifact Patterns
 
 | File Pattern | Purpose | When Useful |

plugins/dotnet-dnceng/skills/ci-analysis/references/helix-artifacts.md

@@ -38,7 +38,7 @@ $logContent | Select-String -Pattern "error|FAIL" -Context 2,5
 
 ## Search Helix Logs and Artifacts Remotely
 
-> 💡 **Prefer remote search over download.** Search Helix console logs and uploaded files in place — find errors without downloading first. Only fall back to full log retrieval or file download when remote search isn't sufficient.
+> 💡 Search logs remotely before downloading.
 
 Use your Helix MCP tools to:
 - **Search a work item's console log** for error patterns (with context lines)

plugins/dotnet-dnceng/skills/ci-analysis/references/manual-investigation.md

@@ -16,9 +16,9 @@ Read `recommendationHint` as a starting point, then layer in context:
 | `MERGE_CONFLICTS` | PR has merge conflicts — CI won't run. Tell the user to resolve conflicts. Offer to analyze a previous build by ID. |
 | `NO_BUILDS` | No AzDO builds found (CI not triggered). Offer to check if CI needs to be triggered or analyze a previous build. |
 
-## Layering Nuance
+## Refining with Context
 
-Then layer in nuance the heuristic can't capture:
+Refine the recommendation with context the heuristic can't capture:
 
 - **Mixed signals**: Some failures match known issues AND some correlate with PR changes → separate them. Known issues = safe to retry; correlated = fix first.
 - **Canceled jobs with recoverable results**: If `canceledJobNames` is non-empty, mention that canceled jobs may have passing Helix results (see [failure-interpretation.md](failure-interpretation.md) — Recovering Results).