aspnetcore

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.