awesome-claude-copilot: Instructions file for GitHub Copilot

Standalone Blazor WebAssembly (.NET 10)

These rules target standalone Blazor WebAssembly apps (blazorwasm template): pure client-side .NET running in the browser, deployed as static files (CDN, static hosting, PWA). Grounded in the official docs at learn.microsoft.com/aspnet/core/blazor (?view=aspnetcore-10.0).

Scope and hosting

• The "ASP.NET Core Hosted" WASM template was removed in .NET 8 — never scaffold or suggest the old Client/Server/Shared three-project layout. A standalone WASM app calls its backend as an ordinary web API.
• Standalone WASM has no concept of render modes — @rendermode, InteractiveWebAssembly, InteractiveAuto, prerendering, and .Client projects are Blazor Web App concerns. Never suggest them here.
• Everything shipped to the browser is inspectable: never put secrets, API keys, or private business logic in the app. Sensitive work belongs behind a server API.
• Apply the general C# standards (csharp.instructions.md): C# 14, primary constructors with private readonly _camelCase field capture, collection expressions, is null / is not null.

Components and rendering performance

• Prefer primitive immutable parameter types (string, int, bool, DateTime) so built-in change detection can skip child subtrees; for complex parameters, override ShouldRender with your own change tracking on hot components.
• Use Virtualize<TItem> for long lists (ItemsProvider for remote data, tune ItemSize/OverscanCount); QuickGrid has virtualization built in.
• Put @key on the repeated element or component itself, not on a wrapper — and only when preserving instances/element state matters; it has a small cost otherwise.
• Avoid thousands of tiny component instances (~0.06 ms overhead each in WASM): inline repeated children or use reusable RenderFragment fields instead of dedicated components.
• Event handlers trigger an automatic StateHasChanged; for handlers that don't change state, use the EventUtil/IHandleEvent pattern to suppress it (dispatch exceptions via DispatchExceptionAsync so error boundaries still see them).
• Never compute RenderTreeBuilder sequence numbers (seq++) — hardcode literals (analyzer ASP0006); prefer .razor markup over manual RenderTreeBuilder code entirely.
• Use lifecycle methods correctly: OnInitializedAsync for one-time init, OnParametersSetAsync for parameter-driven work, OnAfterRender{Async} for anything touching ElementReference.