**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.

| `POSSIBLY_TRANSIENT` | No correlation with PR changes, no known issues. Suggest checking the target branch, searching for issues, or retrying. |

- **Infrastructure vs code**: Don't label failures as "infrastructure" unless Build Analysis flagged them or the same test passes on the target branch. See the anti-patterns in "Interpreting Results" above.

Before running the script, read the PR to understand what you're analyzing. Context changes how you interpret every failure.

1. **Read PR metadata** — title, description, author, labels, linked issues

2. **Classify the PR type** — this determines your interpretation framework:

| PR Type | How to detect | Interpretation shift |

|---------|--------------|---------------------|

| **Code PR** | Human author, code changes | Failures likely relate to the changes |

| **Flow/Codeflow PR** | Author is `dotnet-maestro[bot]`, title mentions "Update dependencies" | Missing packages may be behavioral, not infrastructure (see anti-pattern below) |

| **Backport** | Title mentions "backport", targets a release branch | Failures may be branch-specific; check if test exists on target branch |

| **Merge PR** | Merging between branches (e.g., release → main) | Conflicts and merge artifacts cause failures, not the individual changes |

| **Dependency update** | Bumps package versions, global.json changes | Build failures often trace to the dependency, not the PR's own code |

3. **Check existing comments** — has someone already diagnosed the failures? Is there a retry pending?

4. **Note the changed files** — you'll use these to evaluate correlation after the script runs

Run with `-ShowLogs` for detailed failure info.

1. **Check Build Analysis** — Known issues are safe to retry

2. **Correlate with PR changes** — Same files failing = likely PR-related

3. **Compare with baseline** — If a test passes on the target branch but fails on the PR, compare Helix binlogs. See [references/binlog-comparison.md](references/binlog-comparison.md) — **delegate binlog download/extraction to subagents** to avoid burning context on mechanical work.

4. **Interpret patterns** (but don't jump to conclusions):

- Device failures, Docker pulls, network timeouts → *Could* be infrastructure, but verify against the target branch first

Before stating a failure's cause, verify your claim:

- **"Infrastructure failure"** → Did Build Analysis flag it? Does the same test pass on the target branch? If neither, don't call it infrastructure.

- **"Transient/flaky"** → Has it failed before? Is there a known issue? A single non-reproducing failure isn't enough to call it flaky.

- **"PR-related"** → Do the changed files actually relate to the failing test? Correlation in the script output is heuristic, not proof.

- **"Safe to retry"** → Are ALL failures accounted for (known issues or infrastructure), or are you ignoring some?

- **"Not related to this PR"** → Have you checked if the test passes on the base branch? Don't assume — verify.

The script outputs both human-readable failure details and a `[CI_ANALYSIS_SUMMARY]` JSON block. Use both to produce a structured response.

Use this format — adapt sections based on what you find:

**1. Summary verdict** (1-2 sentences)

Lead with the most important finding. Is CI green? Are failures PR-related? Known issues?

**2. Failure details** (2-4 bullets)

For each distinct failure category, state: what failed, why (known/correlated/unknown), and evidence.

**3. Recommended actions** (numbered list)

Specific next steps: retry, fix specific files, investigate further. Include `/azp run` commands if retrying.

3. Layer in Step 0 context — PR type, author intent, changed files

4. Reason over all three to produce contextual recommendations — the `recommendationHint` is a starting point, not the final answer

5. Look for patterns the heuristic may have missed (e.g., same failure across multiple jobs, related failures in different builds)

1. Check if same test fails on the target branch before assuming transient

2. Look for `[ActiveIssue]` attributes for known skipped tests

3. Use `-SearchMihuBot` for semantic search of related issues

4. Binlogs in artifacts help diagnose MSB4018 task failures

5. Use the MSBuild MCP server (`binlog.mcp`) to search binlogs for Helix job IDs, build errors, and properties

6. If checking CI status via `gh pr checks --json`, the valid fields are `bucket`, `completedAt`, `description`, `event`, `link`, `name`, `startedAt`, `state`, `workflow`. There is **no `conclusion` field** in current `gh` versions — `state` contains `SUCCESS`/`FAILURE` directly

7. When investigating internal AzDO pipelines, check `az account show` first to verify authentication before making REST API calls