csharp-best-practices
Skill4 starsChanged 10 months agoMITView on GitHub
Use when implementing or refactoring C# code and you must apply best practices aligned to the project's effective C# language version and .NET target/runtime. Detect the language/runtime, prefer the newest supported features, and consult version-specific references progressively from C# 10 upward.
In this repository67 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agents-onboardingSkill
- agent-workitem-automationSkill
- architecture-testingSkill
- aspire-integration-testingSkill
- automated-standards-enforcementSkill
- best-practice-introductionSkill
- branching-strategy-and-conventionsSkill
- broken-windowSkill
- change-risk-rollbackSkill
- ci-cd-conformanceSkill
- component-boundary-ownershipSkill
- contract-consistency-validationSkill
- deployment-provenanceSkill
- documentation-as-codeSkill
- documentation-scaffoldSkill
- dotnet-bespoke-code-minimisationSkill
- dotnet-best-practicesSkill
- dotnet-domain-primitivesSkill
- dotnet-efcore-practicesSkill
- dotnet-healthchecksSkill
- dotnet-logging-serilogSkill
- dotnet-mapping-standardSkill
- dotnet-open-source-first-governanceSkill
- dotnet-source-generation-firstSkill
- dotnet-specification-patternSkill
- dotnet-testing-assertionsSkill
- environment-traceabilitySkill
- finishing-a-development-branch-iddSkill
- greenfield-baselineSkill
- impacted-scope-enforcementSkill
- incremental-change-impactSkill
- incremental-deploymentSkill
- innersource-governance-bootstrapSkill
- issue-driven-deliverySkill
- library-extraction-stabilisationSkill
- local-dev-experienceSkill
- markdown-authorSkill
- modern-csharp-coding-standardsSkill
- monorepo-orchestration-setupSkill
- observability-logging-baselineSkill
- pair-programmingSkill
- persona-switchingSkill
- process-skill-routerSkill
- quality-gate-enforcementSkill
- release-tagging-planSkill
- repo-best-practices-bootstrapSkill
- repository-foundation-bootstrapSkill
- requirements-gatheringSkill
- runtime-tooling-validationSkill
- safe-brownfield-refactorSkill
- scoped-colocationSkill
- security-processesSkill
- selective-build-testSkill
- semantic-version-impactSkill
- session-awareSkill
- skills-first-workflowSkill
- static-analysis-securitySkill
- structured-review-workflowSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 16 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈16
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 28
Detect language version: Check LangVersion in csproj, Directory.Build.props, or infer from TFM
- Distinctive: line 29
Record determination: Document effective C# version and how it was determined
- Distinctive: line 31
Apply highest-priority guidance: When conflicts exist, newest version guidance wins
- Distinctive: line 33
Apply to touched code only: Avoid unrelated formatting changes unless broader refactor requested
- Distinctive: line 34
Validate build and tests: Ensure changes compile and pass tests
- Distinctive: line 35
Emit summary: Document applied practices and any pending analyzer decisions
- Distinctive: line 40
Prefer the newest supported features while remaining compatible with the configured target framework and repository conventions.
- Very specific: line 88
If V >= 11: load csharp-11.md
- Distinctive: line 95
When guidance overlaps or conflicts across versions:
- Distinctive: line 127
When encountering an optional analyzer recommendation, the agent MUST:
- Very specific: line 130
Do NOT enable the rule globally in .editorconfig, Directory.Build.props, Directory.Build.targets, or equivalent.
- Distinctive: line 132
Do NOT mass-refactor existing code to satisfy the rule.
- Distinctive: line 135
Ask whether the rule should be:
- Distinctive: line 142
Leave the rule disabled globally.
- Distinctive: line 148
If clarification is requested, record:
- Distinctive: line 166
Do not enable preview features unless explicitly configured.
- Distinctive: line 167
Do not upgrade SDK or TFM unless requested.
- Distinctive: line 168
Avoid unrelated formatting changes and "style churn".
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
C# Best Practices (Version-Aware Skill)
Overview
Apply C# best practices appropriate to the project's effective language version. This skill detects the language/runtime configuration, prefers the newest supported features, and consults version-specific references progressively from C# 10 upward while respecting repository conventions.
When to Use
- Implementing or refactoring C# code in any .NET project
- Reviewing C# code for best practice alignment
- Upgrading code to use newer C# language features
- Resolving analyzer warnings or style issues
- Onboarding to an existing C# codebase to understand effective patterns
Core Workflow
- Detect language version: Check LangVersion in csproj, Directory.Build.props, or infer from TFM
- Record determination: Document effective C# version and how it was determined
- Load references progressively: Load reference docs from C# 10 up to the effective version
- Apply highest-priority guidance: When conflicts exist, newest version guidance wins
- Handle optional analyzers: Pause and request clarification for optional/contentious rules
- Apply to touched code only: Avoid unrelated formatting changes unless broader refactor requested
- Validate build and tests: Ensure changes compile and pass tests
- Emit summary: Document applied practices and any pending analyzer decisions
Intent
Apply C# best practices appropriate to the project's effective language version. Prefer the newest supported features while remaining compatible with the configured target framework and repository conventions.
Detect language version precedence (authoritative order)
Precedence
- Explicit
<LangVersion>in the project (*.csproj) <LangVersion>inDirectory.Build.props(nearest first, then parents)- Imported props/targets explicitly setting
<LangVersion>(includingDirectory.Build.targets) - Target Framework Moniker (TFM) inference
- SDK pinning / build evidence (diagnostics only; never overrides explicit LangVersion)
Target framework mapping
- net6.0 → C# 10
- net7.0 → C# 11
- net8.0 → C# 12
- net9.0 → C# 13
- net10.0 → C# 14
Multi-targeting
- Shared code uses the minimum supported C# version across TFMs.
- Higher-version features are allowed only inside TFM-guarded regions
(e.g.
#if NET9_0_OR_GREATER) or TFM-specific source sets.
Output requirements
Record:
- Effective C# version
- How it was determined (csproj / Directory.Build.props / import / inferred)
- Active configuration/platform assumptions used
Progressive reference loading and prioritization
Principle
Best practices accumulate across C# versions. The agent must load and apply guidance in sequence from the baseline (C# 10) up to the project's effective C# version.
Loading order (progressive)
Given an effective C# version V, load reference docs in ascending order:
- Always load:
references/csharp-10.md - Then load each subsequent version up to
V:- If
V>= 11: loadcsharp-11.md - If
V>= 12: loadcsharp-12.md - If
V>= 13: loadcsharp-13.md - If
V>= 14: loadcsharp-14.md
- If
Priority rule (conflicts and overlap)
When guidance overlaps or conflicts across versions:
- The highest supported version wins (latest loaded reference has highest priority).
- Older guidance remains applicable only if it does not conflict with newer guidance and is still relevant.
Reporting requirement
In the change summary or PR description, record:
- Effective C# version
- Ordered list of reference docs consulted (e.g., C#10 → C#11 → C#12)
- Highest-version feature(s) applied and where
Optional analyzer governance (mandatory clarification)
Definition
An analyzer rule or formatting recommendation is considered optional if:
- It is context-sensitive or contentious (readability trade-offs).
- It can introduce widespread churn when enabled globally.
- It changes construction/architecture patterns rather than correcting defects.
- It is marked as "Optional (requires clarification)" in any reference document.
Examples include (non-exhaustive):
IDE0290– Use primary constructorIDE0305– Use collection expression for fluent
Mandatory agent behavior
When encountering an optional analyzer recommendation, the agent MUST:
- Pause global enforcement
- Do NOT enable the rule globally in
.editorconfig,Directory.Build.props,Directory.Build.targets, or equivalent. - Do NOT mass-refactor existing code to satisfy the rule.
- Do NOT enable the rule globally in
- Request clarification from the user
- Ask whether the rule should be:
- Enabled globally
- Enabled only for new/modified code
- Left disabled (status quo)
- Provide a short explanation of what it enforces and key trade-offs.
- Ask whether the rule should be:
- Default if no response
- Leave the rule disabled globally.
- Apply the recommendation only opportunistically in newly written or directly modified code if it improves clarity and aligns with local conventions.
Documentation requirement
If clarification is requested, record:
- Analyzer ID
- User decision
- Enforcement scope (global / touched code / none)
Execution flow
- Detect and record the effective C# version.
- Load reference documents progressively from C# 10 up to the effective version (latest has highest priority).
- Apply best practices only to touched code unless a broader refactor is requested.
- Validate build and tests.
- Emit a summary of applied practices and any optional analyzer decisions pending or confirmed.
Guardrails
- Do not enable preview features unless explicitly configured.
- Do not upgrade SDK or TFM unless requested.
- Avoid unrelated formatting changes and "style churn".
Red Flags - STOP
These statements indicate misalignment with C# best practices:
| Thought | Reality |
| "Let's use C# 14 features everywhere" | Match the project's effective language version; don't assume latest |
| "Enable all analyzers globally" | Optional analyzers need clarification; mass changes cause churn |
| "Preview features are fine for production" | Avoid preview unless explicitly configured and justified |
| "Upgrade the TFM while fixing this bug" | Don't upgrade SDK/TFM unless explicitly requested |
| "This code style is better" | Avoid unrelated formatting changes; focus on the task at hand |
| "Apply the latest patterns to all code" | Only modify touched code unless broader refactor is requested |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

