only. Do not define scope (diff vs codebase) or perform security/architecture analysis; those are handled by scope and cognitive skills. Emit a
findings list
in the standard format for 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 Goal
Produce a .NET language/runtime findings list covering async/await, nullable types, API stability, resource management, LINQ usage, and testability for the given code scope.
Success Criteria
(ALL must be met):
✅
.NET-only scope
Only .NET (C#/F#) language and runtime conventions are reviewed; no scope selection, security, or architecture analysis performed
✅
All six .NET dimensions covered
async/await, nullable reference types, API/versioning, resources/IDisposable, collections/LINQ, and testability are assessed where relevant
✅
Findings format compliant
Each finding includes Location, Category (
language-dotnet
), Severity, Title, Description, and optional Suggestion
✅
File:line references
All findings reference specific file locations with line numbers
✅
Non-.NET code excluded
Non-.NET files are not analyzed for .NET-specific rules unless explicitly in scope
Acceptance Test
Does the output contain a .NET-focused findings list with file:line references covering all relevant language/runtime dimensions without performing security, architecture, or scope analysis?
Scope Boundaries
This skill handles
:
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, allocation, span/memory)
for aggregation. For security or architecture concerns found in the .NET code, note them and suggest running the appropriate cognitive skill.
Use Cases
Orchestrated review
Used as the language step when
review-code
runs scope → language → framework → library → cognitive for .NET projects.
.NET-only review
When the user wants only language/runtime conventions checked (e.g. after adding a new C# file).
Pre-PR .NET 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 user.
Behavior
Scope of this skill
Analyze
.NET language and runtime conventions in the
given code scope
(files or diff provided by the caller). Do not decide scope; accept the code range as input.
Do not
Perform scope selection (diff vs codebase), security review, or architecture review; do not review non-.NET files unless asked to ignore language.
Review checklist (.NET dimension only)
async/await and ConfigureAwait
Correct use of async; ConfigureAwait(false) where appropriate (library code); cancellation token propagation; avoid async void except event handlers.
Nullable reference types and NRE
Nullable annotations; null checks and null-forgiving where justified; avoid unnecessary null-forgiving.
API and versioning
Public API surface stability; breaking changes; versioning or deprecation strategy for libraries.
Resources and IDisposable
Proper use of IDisposable, using statements, and IAsyncDisposable; no leaking handles or streams.
Collections and LINQ
Appropriate use of LINQ; allocation and enumeration; avoid multiple enumeration; span/memory where relevant.
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 with Location, Category, Severity, Title, Description, Suggestion.
Input & Output
Input
Code scope
Files or directories (or diff) already selected by the user or by the scope skill. This skill does not decide scope; it reviews the provided .NET code for language conventions only.
Output
Emit zero or more
findings
in the format defined in
Appendix: Output contract
.
Category for this skill is
language-dotnet
.
Restrictions
Hard Boundaries
Do not
perform security, architecture, or scope selection. Stay within .NET language and runtime conventions.
Do not
give conclusions without specific locations or actionable suggestions.
Do not
review non-.NET code for .NET-specific rules unless the user explicitly includes it (e.g. embedded scripts).
Skill Boundaries
Do NOT do these
(other skills handle them):
Do NOT select or define the 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 emitted, hand off to
review-code
for aggregation
When the user needs a full 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-only scope
Only .NET (C#/F#) language and runtime conventions are reviewed; no scope selection, security, or architecture analysis performed
All six .NET dimensions covered
async/await, nullable reference types, API/versioning, resources/IDisposable, collections/LINQ, and testability are assessed where relevant
Findings format compliant
Each finding includes Location, Category (
language-dotnet
), Severity, Title, Description, and optional Suggestion
File:line references
All findings reference specific file locations with line numbers
Non-.NET code excluded
Non-.NET files are not analyzed for .NET-specific rules unless explicitly in scope
Process Quality Checks
Was only the .NET language/runtime dimension reviewed (no scope/security/architecture)?
Are async, nullable, IDisposable, LINQ, and testability covered where relevant?
Is each finding emitted with Location, Category=language-dotnet, Severity, Title, Description, and optional Suggestion?
Are issues referenced with file:line?
Acceptance Test
Does the output contain a .NET-focused findings list with file:line references covering all relevant language/runtime dimensions without performing security, architecture, or scope analysis?
Examples
Example 1: Async method
Input
C# method that is async and calls other async methods without passing CancellationToken.
Expected
Emit a finding (e.g. minor/suggestion) for CancellationToken propagation; reference the method and parameter list. Category = language-dotnet.
Example 2: Nullable and disposal
Input
C# class that holds an IDisposable and does not implement IDisposable or use using.
Expected
Emit finding(s) for resource disposal and possibly nullable if the field can be null. Category = language-dotnet.
Edge case: Mixed C# and SQL
Input
File with C# and embedded SQL strings.
Expected
Review only 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.
Appendix: Output contract
Each finding MUST follow the standard findings format:
Element
Requirement
Location
path/to/file.ext
(optional line or range).
Category
language-dotnet
.
Severity
critical
|
major
|
minor
|
suggestion
.
Title
Short one-line summary.
Description
1–3 sentences.
Suggestion
Concrete fix or improvement (optional).
Example:
-
**
Location
**
:
src/Services/DataLoader.cs:22
-
**
Category
**
language-dotnet
**
Severity
**
minor
**
Title
**
Async method does not accept or forward CancellationToken
**
Description
**
Long-running or cancellable operations should support cancellation.
**
Suggestion
**
Add CancellationToken parameter and pass it to underlying async calls.