Reviews and refactors .NET/C# code: fixes async patterns, validates DI registration, corrects error handling, adds documentation, enforces style conventions. USE FOR: review C# code, audit project, enforce coding standards, apply .NET best practices, clean up code, fix style issues, apply coding standards, tidy up this file, make this idiomatic C#, fix code quality issues, get PR-ready, prepare for code review, add documentation, fix async patterns, check DI registration, check error handling, fix configuration, bring this up to standard, make this code production-ready. DO NOT USE FOR: non-.NET codebases, read-only .NET questions, trivial single-variable edits.
96
100%
Does it follow best practices?
Impact
92%
1.27xAverage score across 6 eval scenarios
Passed
No known issues
See references/trigger-phrases.md for example trigger phrases per category.
Before processing any files, inspect every *.csproj in the workspace:
<LangVersion> and <TargetFramework> / <TargetFrameworks>.required keyword), C# 12+ features (collection expressions, primary constructors), C# 13+ features (params ReadOnlySpan<T>), or C# 14+ features (field keyword, extension member syntax) must only be applied when the detected language version supports them.net6.0, net7.0, net8.0, net8.0-*) across all projects, and identify the lowest target framework.net8.0 and net8.0-* as supporting .NET 8 APIs (e.g., IExceptionHandler, Keyed DI services, IProblemDetailsService).net6.0 / net7.0, do not recommend APIs that were introduced in .NET 8 or later; instead, prefer equivalent patterns compatible with those target frameworks.Analyze ${selection} if provided. If no selection is made, analyze ALL C# files (**/*.cs) in the workspace, excluding the files listed below.
Skip files matching these patterns — applying fixes to generated or migrated code causes build failures:
**/*.g.cs, **/*.Designer.cs — auto-generated source**/obj/**, **/bin/** — build output**/Migrations/** — EF Core migration filesTest projects (files under a project whose name contains Tests, Specs, or Test):
// ...existing code... to preserve unchanged sections.| # | Sub-Skill | File | Focus Area |
|---|---|---|---|
| 1 | Documentation | references/documentation.md | XML docs, inheritdoc, namespace structure |
| 2 | Architecture | references/architecture.md | Design patterns, records, primary constructors |
| 3 | DI & Services | references/di-services.md | DI registration, service interfaces, null guards, captive dependencies |
| 4 | Localization | references/localization.md | User-facing strings, IStringLocalizer, .resx files |
| 5 | Async Patterns | references/async-patterns.md | async/await, ConfigureAwait, CancellationToken, ValueTask |
| 6 | Configuration | references/configuration.md | Strongly-typed options, IOptions variants, data annotations |
| 7 | Error Handling | references/error-handling.md | Structured logging, LoggerMessage, specific exceptions, ProblemDetails |
| 8 | Code Quality | references/code-quality.md | SOLID, nullable annotations, naming, constants, usings, disposal |
After all sub-skills are complete, produce a single Markdown table:
| File | Sub-Skill | Severity | Description | Recommended Fix |
|---|---|---|---|---|
| ... | ... | Critical / Warning / Info | ... | ... |
Severity: Critical = correctness/runtime risk · Warning = maintainability/perf · Info = style
After outputting the summary table, apply findings in order:
// ...existing code....✅ checklist item.94e070f
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.