claude-plugins

Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations like EF Core migrations or deploys), or any time a confident output would be cheaper to verify now than to debug later.

Delivers .NET/C# changes incrementally — thin vertical slices with dotnet build + dotnet test verification between each. Use when implementing any feature that touches more than one project or assembly. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.

Instruments .NET/C# code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting to an ASP.NET Core / Blazor / worker / desktop app. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

Hardens .NET/C# code against vulnerabilities — input validation (FluentValidation), EF Core parameterization, ASP.NET Core Identity / JWT bearer / policy-based authz, Data Protection, antiforgery, user-secrets + Key Vault, `dotnet list package --vulnerable`. Use when handling user input, authentication, data storage, or external integrations in ASP.NET Core, Blazor, or Avalonia/MAUI apps that talk to an API.

Drives .NET/C# development with tests — RED/GREEN/REFACTOR with xUnit (v2 or v3) or MSTest, the Prove-It Pattern for bug fixes, the test pyramid with `WebApplicationFactory` for integration and `Playwright`/`Avalonia.Headless` for E2E. Supports both VSTest and Microsoft.Testing.Platform (MTP) runners. Use when implementing any logic, fixing any bug, or changing any behavior.

Meta-skill — discovers and invokes the right .NET/C# agent skill from this marketplace for the task at hand. Use when starting a session, when a task doesn't obviously map to a single skill, or when you need a phase-by-phase map of what's available across Define / Plan / Build / Verify / Review / Ship. Governs how every other skill in `dotnet-skills` is discovered and activated.

Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.

Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

Tests .NET/C# systems at their integration boundaries — HTTP APIs with `WebApplicationFactory<T>`, EF Core against real databases via Testcontainers (PostgreSQL, SQL Server, Redis), Blazor/Razor Pages in real browsers via `Microsoft.Playwright`, Avalonia UI via `Avalonia.Headless.XUnit`. Works with xUnit v2/v3 on VSTest or Microsoft.Testing.Platform. Use when building or debugging anything that crosses a boundary — HTTP, database, file system, message bus, or UI rendering.

Optimizes agent context setup for .NET/C# projects. Use when starting a new session, when agent output quality degrades (wrong patterns, hallucinated APIs, unaware of .NET conventions), when switching between Avalonia/Blazor/ASP.NET Core codebases, or when you need to configure CLAUDE.md, .editorconfig, and analyzer rules for a project.

Grounds every .NET/C# implementation decision in official documentation (Microsoft Learn, EF Core docs, ASP.NET Core docs, Avalonia docs, NuGet README). Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any .NET framework or library where correctness depends on version-specific APIs.

Creates specs before coding a .NET/C# project. Use when starting a new .NET 8+ solution, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Frames examples for Avalonia, ASP.NET Core, Blazor, .NET MAUI, EF Core, xUnit, and MSTest.

Guides stable API and interface design for .NET/C# — HTTP endpoints (Minimal APIs or controllers), library surface area, public records/interfaces, EF Core-backed contracts. Use when designing APIs, module boundaries, `MyApp.Contracts` DTOs, or any public interface where backward compatibility matters.

Automates CI/CD pipelines for .NET/C# projects — GitHub Actions (or Azure DevOps Pipelines) with `setup-dotnet`, quality gates (`dotnet format --verify-no-changes`, `dotnet test`, `dotnet build -warnaserror`, `dotnet list package --vulnerable`), EF Core migrations, preview deploys, feature-flag-driven rollouts, rollback. Use when setting up or modifying build and deployment pipelines for .NET workloads.

Conducts multi-axis code review for .NET/C# changes (correctness, readability, architecture, security, performance). Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

Simplifies .NET/C# code for clarity without changing behavior. Use when refactoring C# code that works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. Preserves exact behavior; examples cover TypeScript, Python, React, and C#.

Guides systematic root-cause debugging for .NET/C# code. Use when `dotnet test` fails, `dotnet build` breaks, behavior doesn't match expectations, or you encounter any unexpected error (NullReferenceException, TaskCanceledException, missing DI registration, EF Core migration conflict). Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

Manages deprecation and migration for .NET/C# systems — removing NuGet packages, retiring controllers/endpoints, sunsetting features, migrating EF Core schemas. Use when removing old code, migrating users from one implementation to another, or deciding whether to maintain or sunset existing code.

Records architectural decisions and writes durable documentation for .NET/C# projects — ADRs, XML doc comments, OpenAPI/Swagger, README with dotnet CLI commands, CLAUDE.md pointers. Use when making architectural decisions, changing public APIs, shipping features, or recording context that future engineers and agents will need.

Builds production-quality Avalonia UIs — MVVM with CommunityToolkit.Mvvm, compiled bindings (`x:DataType`, `x:CompileBindings`), `DataTemplate`s, theming via FluentTheme/SimpleTheme with `ThemeVariant`, keyboard navigation, `AutomationProperties` for accessibility, adaptive layouts across desktop/mobile/browser targets. Use when building or modifying Avalonia 11/12 user interfaces, implementing views and view-models, or fixing visual or UX issues in an Avalonia app.

Structures git workflow practices for .NET/C# projects — atomic commits, trunk-based branches, pre-commit hygiene with `dotnet test` + `dotnet format`, worktrees for parallel agent work. Use when making any code change to a .NET solution, when committing, branching, resolving conflicts, or organizing work across multiple parallel streams.

Refines raw ideas into sharp, actionable .NET/C# concepts through structured divergent and convergent thinking. Use "idea-refine" or "ideate" to trigger when deciding what to build next in a .NET solution — new Avalonia app, ASP.NET Core API, EF Core data model, NuGet library, or process improvement.

Optimizes .NET/C# application performance — measure first with BenchmarkDotNet / dotnet-counters / dotnet-trace / PerfView, then fix the specific bottleneck (EF Core N+1, sync-over-async, Gen2 GC pressure, thread-pool starvation, allocation hotspots, unbounded queries, missing pagination, Kestrel misconfiguration). Use when performance requirements exist, when latency / throughput / memory regresses, or when profiling reveals a bottleneck that needs fixing.

Breaks .NET/C# work into ordered, verifiable tasks. Use when you have a spec or clear requirements and need to decompose work into implementable units with dotnet CLI verification steps. Use when a task feels too large to start, when you need to estimate scope across a multi-project solution, or when parallel work is possible.

Prepares production launches for .NET/C# systems — pre-launch checklist with `dotnet test` + `dotnet list package --vulnerable`, feature flags via `IOptions<T>`, staged rollout with Application Insights / OpenTelemetry monitoring, EF Core migration rollback, `dotnet ef database update` to previous migration. Use when deploying to production, preparing a release, setting up monitoring, planning a staged rollout, or needing a rollback strategy.

Use when the user asks to "review Avalonia structure", "review XAML project", "improve theming", "add design tokens", "organize styles", or needs Avalonia/MAUI architecture guidance. Supports Avalonia 11.x and 12.x with version-specific checks.