Purpose
Only inspect .NET language and runtime conventions in code within the ecosystem (C#, F#)language and runtime conventions. Do not define scope (diff vs codebase) or perform security/architecture analysis; these are handled through scope and cognitive skills. Emit in standard formatresult listfor aggregation. Focus on async/await and ConfigureAwait, nullable reference types and NRE avoidance, API and versioning, resources and IDisposable, collections and LINQ, and testability.
Core Objective
Primary objective: Generate a .NET language/runtime result list covering async/await, nullable types, API stability, resource management, LINQ usage, and testability for the given code scope.
Success criteria(all requirements must be met):
- ✅ .NET scope only: Review only .NET (C#/F#) language and runtime conventions; no scope selection, security, or architecture analysis performed
- ✅ Cover all six .NET dimensions: async/await, nullable reference types, API/versioning, resources/IDisposable, collections/LINQ, and testability (if relevant)
- ✅ Result format compatible: each result includes location, category (
language-dotnet), severity, title, description, and optional recommendation - ✅ File:line references: all findings reference specific file locations with line numbers
- ✅ Exclude non-.NET code: .NET-specific rules are not analyzed for non-.NET files unless explicitly in scope
Acceptancetest: Does the output contain a .NET-centric result list with file:line references covering all relevant language/runtime dimensions without performing security, architecture, or scope analysis?
Scope boundaries (Scope boundaries)
This skill is responsible for：
- async/await correctness and ConfigureAwait usage (library vs application code)
- Nullable reference types and NRE avoidance
- Public API stability and versioning strategy
- IDisposable, IAsyncDisposable, and using statement patterns
- Collections and LINQ efficiency (multiple enumeration, allocations, span/memory)
- Testability (DI, sealed/overridable, static usage)
This skill is not responsible for：
- Scope selection — scope is provided by the caller
- Security analysis (injection, authentication, cryptography) — use "review-security"
- Architecture analysis — use "review-architecture"
- Performance deep dive — use "review-performance"
- Full orchestrated review — use "review code"
- Codebase state review — use
review-codebase
Handoff point: When all .NET findings are published, hand them off to "orchestrate-code-review" for aggregation. For security or architecture issues found in .NET code, note them and recommend running the appropriate cognitive skill.
Use cases (Use cases)
- Orchestrated review: when orchestrate-code-review runs a .NET project's scope → language → framework → library → cognitive, use as the language step.
- .NET-only review: When the user only wants to check language/runtime conventions (for example, after adding a new C# file).
- PR .NET pre-check checklist: Ensure async, nullable, and resource patterns are correct.
When to use: When the code under review is .NET (C#/F#) and the task includes language/runtime quality. Scope (diff vs paths) is determined by the caller or the user.
Behavior (behavior)
The scope of this skill
- Analyze：Given code scope.NET language and runtime conventions in (caller-provided files or diff). Does not determine scope; accepts code scope as input.
- Do not: Perform scope selection (diff vs codebase), security review, or architecture review; do not look at non-.NET files unless asked to ignore language.
Audit checklist (.NET dimensions only)
- async/await and ConfigureAwait: correct use of async; configure Await(false) where appropriate (library code); cancellation token propagation; avoid async void except for event handlers.
- Nullable reference types and NRE: nullable annotations; null checks and null tolerance where reasonable; avoid unnecessary null-forgiving.
- API and versioning: public API surface stability; breaking changes; versioning or deprecation strategy for libraries.
- Resources and IDisposable: correct use of IDisposable, using statements, IAsyncDisposable; no leaked handles or streams.
- Collections and LINQ: appropriate use of LINQ; allocation and enumeration; avoid multiple enumeration; related span/memory.
- Testability: dependency injection and testability; static usage; sealed/overridable where it affects testing.
Tone and references
- Professional and technical: reference specific locations (file: line). Emit findings containing location, category, severity, title, description, recommendation.
Input & Output (Input & Output)
Input (Input)
- Code scope: files or directories (or diff) already selected by the user or scope skill. This skill does not determine scope; it only checks the language conventions of the provided .NET code.
Output (Output)
- InAppendix: Output Contractemit zero or more in the format defined infindings。
- The category of this skill is language-dotnet。
Limits (Limits)
Hard Boundaries (Hard Boundaries)
- Do notperform security, architecture, or scope selection. Follow .NET language and runtime conventions.
- Do notgive conclusions without specific locations or actionable recommendations.
- Do notcheck .NET-specific rules for non-.NET code unless the user explicitly includes it (for example, embedded scripts).
Skill Boundaries (Skill Boundaries)
Do not do these(other skills can handle them):
- Do not select or define code scope - scope is determined by the caller or "review code"
- Do not perform security analysis - use "review-security"
- Do not perform architecture analysis - use "review-architecture"
- Do not review non-.NET code for .NET conventions
When to stop and hand off：
- When all .NET findings are published, hand them off to "orchestrate-code-review" for aggregation
- When the user needs a comprehensive review (scope + language + cognitive), redirect to "review code"
- When security issues are found in .NET code, note them and suggest "review security"
Self-Check
Core success criteria
- .NET scope only: Only review .NET (C#/F#) language and runtime conventions; no scope selection, security, or architecture analysis was performed
- Covers all six .NET dimensions: async/await, nullable reference types, API/versioning, resources/IDisposable, collections/LINQ, and testability (if relevant)
- Conforms to the findings format: each finding includes location, category (
language-dotnet), severity, title, description, and optional recommendation - File:line references: all results reference specific file locations with line numbers
- Excludes non-.NET code: does not analyze non-.NET files for .NET-specific rules unless explicitly in scope
Process quality checks
- Were only .NET language/runtime dimensions reviewed (no scope/security/architecture)?
- Were the relevant async, nullable, IDisposable, LINQ, and testability aspects covered?
- Does each finding include location, category=language-dotnet, severity, title, description, and optional recommendation?
- Does file:line reference the issue?
Acceptance test
Does the output contain a .NET-centric findings list with file:line references covering all relevant language/runtime dimensions without performing security, architecture, or scope analysis?
Examples (Examples)
Example 1: Async method
- Input: An async C# method that calls other async methods without passing a CancellationToken.
- Expected: Emit a finding for CancellationToken propagation (e.g., minor/suggestion); reference the method and parameter list. Category = language-dotnet.
Example 2: Nullable and disposal
- Input: A C# class that holds an IDisposable and does not implement IDisposable or use using.
- Expected: Emit a finding for resource disposal, and possibly nullability if the field can be null. Category = language-dotnet.
Edge case: Mixed C# and SQL
- Input: A file containing C# and embedded SQL strings.
- Expected: Only review the C# parts for .NET conventions (e.g., async, nullable, disposal). Do not emit SQL injection findings; that is for review-security or review-sql.