dotnet

Labels issues and pull requests in the dotnet/maui repository with `area-*` and `platform/*` labels ONLY, based on technical content and platform-file conventions. Used by the gh-aw agentic-labeler workflow and available for batch evaluation and interactive Copilot CLI usage.

Analyzes your local Copilot CLI sessions for dotnet/maui to drive iterative improvements to the PR-review agent (and other agents, skills, and instruction files). Runs a select → extract → score → judge → cluster → propose → emit-eval loop: a deterministic core ranks your worst / most-expensive sessions, then the agent rubric-tags recurring failure modes, proposes concrete repo edits, and emits a vally guard-eval per failure mode so each one becomes a regression test. Triggers on: "analyze my recent maui sessions", "what's making my agent runs expensive", "find failure modes in my Copilot sessions", "turn my session failures into guard evals". LOCAL-ONLY — never uploads, shares, or posts transcripts. Do NOT use for: reviewing a single PR (use pr-review), running tests, or analyzing a GitHub issue.

Investigate CI failures for dotnet/maui PRs and the nightly/official signed build — build errors, Helix test logs, and binlog analysis. Use when asked about failing checks, CI status, test failures, 'why is CI red', 'build failed', 'what's failing on PR', 'is this PR ready to merge', Helix failures, device test failures, or 'nightly is broken', 'nightly build failing', 'inflight feed stale', 'dogfood feed stopped updating', 'official build failed'.

Common safety and triage protocol for .NET MAUI CI-fixer workflows. Use whenever investigating, creating, or advancing a `[ci-fix]` or `[ci-fix-net11]` pull request from a `ci-scan` issue, including manual single-issue dispatches and scheduled sweeps.

Deep code review of PR or materialized candidate-patch changes for correctness, safety, and MAUI conventions. Uses independence-first assessment (code before narrative) and delegates to the maui-expert-reviewer agent for per-dimension sub-agent evaluation. Triggers on: "review code for PR", "code review PR", "review candidate patch", "analyze code changes", "check PR code quality". Do NOT use for: summarizing PRs, describing what changed, general PR questions, running tests, or fixing code.

MAUI-specific dependency flow rules, channel conventions, and feed lookup workflows. Use when asked about darc, BAR, Maestro, feeds for .NET MAUI, build promotion, asset lookup, channel mappings, or dependency flow for dotnet/maui. Wraps the maestro-cli skill and maestro MCP tools with MAUI-specific guardrails.

Evaluates tests added in a PR for coverage, quality, edge cases, and test type appropriateness. Checks if tests cover the fix, finds gaps, and recommends lighter test types when possible. Prefer unit tests over device tests over UI tests. Triggers on: 'evaluate tests in PR', 'review test quality', 'are these tests good enough', 'check test coverage', 'is this test adequate', 'assess test coverage for PR'.

Detects potential regression risks in a PR by cross-referencing lines the PR REMOVES against lines ADDED by recent labeled bug-fix PRs (`i/regression`, `t/bug`, `p/0`, `p/1`) touching the same files. Purely mechanical — no AI/LLM. Emits a CLEAN / OVERLAP / REVERT verdict plus structured findings. Triggers on: "does this PR revert a previous fix", "check PR for regression risk", "find regression risks in PR", "is this change reverting a bug fix". Do NOT use for: assessing ship-readiness of a release branch (use release-readiness), investigating CI failures (use azdo-build-investigator), or general code review (use code-review).

Finds open PRs in the dotnet/maui and dotnet/docs-maui repositories that are good candidates for review, prioritizing by milestone, priority labels, partner/community status.

Queries and triages open GitHub issues that need attention. Helps identify issues needing milestones, labels, or investigation.

Analyzes a completed PR to extract lessons learned from agent behavior. Use after any PR with agent involvement - whether the agent failed, succeeded slowly, or succeeded quickly. Identifies patterns to reinforce or fix, and generates actionable recommendations for instruction files, skills, and documentation.

Guidance for querying and interpreting Copilot and agentic workflow OpenTelemetry token and execution metrics.

Finalizes any PR for merge by verifying title/description match implementation AND performing code review for best practices. Use when asked to "finalize PR", "check PR description", "review commit message", before merging any PR, or when PR implementation changed during review. Do NOT use for extracting lessons (use learn-from-pr), writing tests (use write-tests-agent), or investigating build failures (use azdo-build-investigator and ci-analysis).

End-to-end PR reviewer for dotnet/maui. Orchestrates 3 phases — Pre-Flight, Try-Fix, Report. Gate runs separately before this skill. Use when asked to 'review PR #XXXXX', 'work on PR #XXXXX', or 'fix issue #XXXXX'.

Assesses ship-readiness for .NET MAUI release branches — Servicing Releases (SR) and Previews. Surveys CI pipelines, computes what's actually NEW in the branch (commits + source PRs with revert detection), and cross-references open `regressed-in-*` issues against branch contents to identify port candidates, rejected backports, and unresolved regressions. Supports both in-flight and pre-cut (candidate) modes for SR and Preview branches.

Classifies PR CI/test failures as likely PR-caused or unrelated, compares against base-branch baseline, and emits an overall merge-readiness verdict. Uses gathered GitHub/AzDO/Helix context and the shared MAUI CI facts.

Build and run .NET MAUI device tests locally with category filtering. Supports iOS, MacCatalyst, Android on macOS; Android, Windows on Windows. Use TestFilter to run specific test categories.

Submit and monitor .NET MAUI unit tests on Helix infrastructure. Supports running XAML, Resizetizer, Core, Essentials, and other unit test projects on distributed Helix queues.

Build, pack, and run .NET MAUI integration tests locally. Validates templates, samples, and end-to-end scenarios using the local workload.

Attempts ONE alternative fix for a bug, tests it empirically, and reports results. ALWAYS explores a DIFFERENT approach from existing PR fixes. Use when CI or an agent needs to try independent fix alternatives. Invoke with problem description, test command, target files, and optional hints.

Verifies tests catch the bug. Auto-detects test type (UI tests, device tests, unit tests) and dispatches to the appropriate runner. Supports two modes - verify failure only (test creation) or full verification (test + fix validation).

Creates UI tests for a GitHub issue and verifies they reproduce the bug. Iterates until tests actually fail (proving they catch the issue). Use when PR lacks tests or tests need to be created for an issue.

Creates XAML unit tests for GitHub issues in the Controls.Xaml.UnitTests project. Tests XAML parsing, compilation (XamlC), and source generation. Use when testing XAML-specific behavior, not UI interactions.

Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.

Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.

Generate before/after .NET public API diff reports for a release milestone with `RunApiDiff.ps1`. Pure report generation only; to verify the diff against the shipped build (dotnet-inspect, revert detection) use the api-diff-validation skill.

Validate that a generated API diff matches the APIs actually shipped in a .NET build, and that every new API traces to a real change. Uses dotnet-inspect to query the build's ref packs and cross-references new APIs against candidate PRs to catch missed reverts, renames, and kept-internal APIs before they reach release notes. Distinct from the pure api-diff skill, which only generates the diff reports.

Apply the shared reader-centric rubric used to rank candidate features for release notes, blog posts, and docs. Use this when you need scoring and cut guidance independent of any one output format or task.

Generate `changes.json` for a .NET release milestone by selecting the correct VMR base/head refs and running `release-notes generate changes`. Handles preview-only multi-branch targeting (`main` vs release branches vs tags) and emits the authoritative manifest of what shipped. DO NOT USE FOR: API diffs (use api-diff), API verification (use api-diff-validation), feature scoring (use generate-features), or writing markdown release notes (use release-notes).

Generate `features.json` from `changes.json` by ranking and annotating shipped changes. `features.json` keeps the same schema as `changes.json` and adds optional scoring fields so release notes, docs, and blog posts can apply different cutoffs. Uses the shared `editorial-scoring` rubric. DO NOT USE FOR: regenerating VMR diffs (use generate-changes) or writing final markdown (use release-notes).

Create the GitHub release discussion in dotnet/core and the locked mirror announcement issue in dotnet/announcements for a .NET preview, RC, or GA release. USE FOR: publishing release discussions after release notes exist, mirroring a newly created discussion into dotnet/announcements, verifying an existing post, and re-running a partially completed publication safely. DO NOT USE FOR: writing release notes, generating changes/features.json, or retrying create commands blindly after cancellation.

Generate and maintain .NET release notes from `features.json`. Uses `generate-changes` for authoritative shipped-change data, `generate-features` for scoring/triage, `update-existing-branch` for incremental reruns on populated branches, `editorial-scoring` for the shared rubric, `api-diff` to generate API diff reports and `api-diff-validation` for API verification, and a multi-model `review-release-notes` pass for final editorial QA.

Review `features.json` scores and draft release notes against the editorial examples and the shared `editorial-scoring` rubric. Use it to identify over-scored, under-scored, or missing features before publishing release notes. DO NOT USE FOR: generating `changes.json` or writing the first draft.

Create and update per-distro package files in release-notes/{version}/distros/ that document .NET runtime dependencies and package availability for each Linux distribution. USE FOR: setting up distros/ for a new .NET version, updating dependency package names when distro versions change, auditing package data. DO NOT USE FOR: supported-os.json changes (use update-supported-os skill), os-packages.json (legacy format).

Refresh an existing .NET release-notes milestone branch set incrementally. Checks whether the VMR ref moved, regenerates `changes.json` only when needed, merges the delta into `features.json`, integrates new material into existing markdown clusters across the per-component branches, and responds to review feedback. USE FOR: reruns on a populated release-notes branch set. DO NOT USE FOR: first-pass generation of a new milestone (use generate-changes, generate-features, and release-notes).

Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.

Review a proposed public API for the dotnet/aspnetcore repo the way the @dotnet/aspnet-api-review team would, and recommend concrete changes to the API shape. USE FOR reviewing an API proposal or api-ready-for-review issue, critiquing a ref-assembly diff, deciding whether a new or changed type/method/overload/property should be added at all, evaluating whether an API change or addition is a good idea, changing/extending an existing API or a shipped default/convention, or checking naming/namespace/nullability/async/sealing/return-type/overload/language-feature choices. Trigger phrases: "review this API", "is this API a good idea", "should we add", "API proposal", "api-ready-for-review". Produces a verdict, a need assessment (commonality + target audience), per-type bullet changes, and a diff against the existing repo API surface. DO NOT USE FOR implementing an approved API, writing analyzers, or general code review unrelated to public API surface.

Validate a Blazor feature or behavior interactively in a browser using the canonical Components samples in this repo, before writing E2E tests. USE FOR exercising a Blazor change in src/Components (a render-mode behavior, an interactive component, enhanced navigation, forms, streaming, prerendering), deciding which sample to use, where to add a test page, how to set the render mode (Server/WebAssembly/Auto/static SSR), how to confirm the app is actually interactive (not just static SSR), and how to inspect the browser console and network for errors. Covers BlazorWebAppGlobal, BlazorWebAppPerPage, and BlazorWebAssemblyStandalone, launching them against the in-tree framework, and driving them with the Playwright MCP browser tools. DO NOT USE FOR writing the permanent E2E/Selenium tests themselves, non-Components areas, or unit tests.