dotnet-best-practices
Skill4 starsChanged 10 months agoMITView on GitHub
Use when designing, implementing, maintaining, or reviewing .NET features, projects, and codebases. Covers architecture, runtime/framework choices, SDK/tooling, packaging, deployment strategy, and version-aware best practices, including code review and ongoing maintenance scenarios.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- github/awesome-copilottheir own version, first seen Oct 25, 2026
- PracticalSwan/agent-skillstheir own version, first seen Oct 19, 2026
- itsfatduck/optimizerDucktheir own version, first seen Oct 8, 2026
- Adhamxon/claude-code-skillstheir own version, first seen Jul 30, 2026
- mduongvandinh/ai-best-practices-skillstheir own version, first seen Feb 19, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- github/awesome-copilot★ 41ksame name
- itsfatduck/optimizerDuck★ 11ksame name
- PracticalSwan/agent-skills★ 22same name
- mduongvandinh/ai-best-practices-skills★ 18same name
- Adhamxon/claude-code-skills★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
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
- csharp-best-practicesSkill
- deployment-provenanceSkill
- documentation-as-codeSkill
- documentation-scaffoldSkill
- dotnet-bespoke-code-minimisationSkill
- 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
15 rules. 0 are common, 14 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
14
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Default for production: upgrade to the latest LTS .NET version.
- Distinctive: line 35
Use STS releases only when a specific platform feature is required and you have an explicit follow-on plan to land on the latest LTS.
- Distinctive: line 40
Use this skill when you are:
- Distinctive: line 60
Document risks, breaking changes, and required test gates
- Distinctive: line 64
Read this file (baseline standards + operating procedure).
- Distinctive: line 69
If upgrading across majors, also load:
- Distinctive: line 81
Prefer secure defaults; do not weaken them without a threat-model justification.
- Very specific: line 88
Ensure graceful shutdown and cancellation propagation (IHostApplicationLifetime, hosted services).
- Distinctive: line 89
Use bounded concurrency, timeouts, and resilience for outbound calls.
- Distinctive: line 90
Avoid sync-over-async; use async end-to-end for I/O.
- Distinctive: line 95
Avoid allocations on hot paths.
- Distinctive: line 96
Use Span/Memory-friendly APIs where appropriate (especially in libraries).
- Distinctive: line 97
Consider AOT/trimming selectively (CLI, serverless cold-start, edge) once compatibility is validated.
- Distinctive: line 103
Keep nullable reference types enabled and clean (avoid blanket suppressions).
- Distinctive: line 111
When used during code review, apply this skill to evaluate:
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
.NET best practices (version-aware, progressive-loading)
Overview
Apply modern .NET platform capabilities and recommended engineering practices across the full lifecycle of a .NET codebase. This skill covers runtime/framework choices, SDK/tooling, packaging, deployment strategy, and version-aware best practices for implementation, maintenance, and code review scenarios.
Purpose
Apply modern .NET platform capabilities and recommended engineering practices across the full lifecycle of a .NET codebase, including:
- feature implementation and enhancement
- routine maintenance and refactoring
- code review and pull request validation
- runtime/framework upgrades
- production hardening and operational improvements
This skill complements a C# language-focused skill by concentrating on .NET runtime/framework, hosting, SDK/tooling, packaging, and operational practices.
Upgrade policy (default)
- Default for production: upgrade to the latest LTS .NET version.
- Use STS releases only when a specific platform feature is required and you have an explicit follow-on plan to land on the latest LTS.
When to use
Use this skill when you are:
- Implementing new .NET features or services
- Modifying existing application or library code
- Reviewing pull requests or performing structured code reviews
- Refactoring or modernizing legacy .NET code
- Upgrading target frameworks, SDKs, or runtime versions
- Validating alignment with current .NET platform best practices
- Establishing or enforcing repository standards for .NET projects
For cross-language or organization-wide security processes, use the security-processes skill alongside this one.
Core Workflow
- Identify target .NET version and load corresponding version reference
- For upgrades, load upgrade-cumulative.md and lts-upgrade-playbook.md
- Apply baseline engineering standards (security, reliability, performance, maintainability)
- Review code against version-specific recommended patterns
- Validate configuration centralisation and analyzer enforcement
- Produce target framework recommendation and adoption checklist
- Document risks, breaking changes, and required test gates
Progressive loading model
- Read this file (baseline standards + operating procedure).
- Load only the references you need:
- Version indexes:
references/dotnet-6.md,references/dotnet-7.md,references/dotnet-8.md,references/dotnet-9.md,references/dotnet-10.md
- If upgrading across majors, also load:
references/upgrade-cumulative.mdreferences/lts-upgrade-playbook.md
- For .NET-specific security enforcement, load:
references/dotnet-security-tooling.md
- For cross-language security processes (SCA/SBOM/container scanning, policy gates, exception handling), use:
security-processesskill
Baseline engineering standards (version-agnostic)
Security
- Prefer secure defaults; do not weaken them without a threat-model justification.
- Enforce HTTPS and HSTS in production; own reverse-proxy/header configuration explicitly.
- Centralize authN/authZ; validate all inbound data; avoid unsafe dynamic deserialization patterns.
- Patch cadence: treat runtime/framework security updates as routine work with defined SLAs.
Reliability
- Ensure graceful shutdown and cancellation propagation (
IHostApplicationLifetime, hosted services). - Use bounded concurrency, timeouts, and resilience for outbound calls; prevent retry storms.
- Avoid sync-over-async; use async end-to-end for I/O.
Performance
- Measure first: tracing/metrics, baseline benchmarks.
- Avoid allocations on hot paths; use pooling where it materially helps.
- Use Span/Memory-friendly APIs where appropriate (especially in libraries).
- Consider AOT/trimming selectively (CLI, serverless cold-start, edge) once compatibility is validated.
Maintainability & governance
- Centralize build configuration in
Directory.Build.props/Directory.Build.targets. - Enable analyzers; move toward warnings-as-errors for critical projects/new code.
- Keep nullable reference types enabled and clean (avoid blanket suppressions).
- Standardize package versioning strategy.
- Adopt NuGet Central Package Management (
Directory.Packages.props) as soon as supported by your toolchain, and enforce "no versions in csproj PackageReference" with documented exceptions.
Code review lens (how to apply this skill in PRs)
When used during code review, apply this skill to evaluate:
- Platform alignment
- Is the code aligned with the target .NET version's recommended patterns?
- Are deprecated or superseded APIs being introduced?
- Runtime and performance awareness
- Does the change introduce unnecessary allocations, sync-over-async, or blocking I/O?
- Are newer runtime/library capabilities being ignored where they would simplify or harden the code?
- Security posture
- Does the change unnecessarily widen the public API surface?
- Are defaults being weakened (auth, HTTPS, serialization, validation)?
- Maintainability
- Are analyzers respected or suppressed without justification?
- Is configuration, dependency management, and hosting consistent with repo standards?
- Upgrade readiness
- Will this change make future LTS upgrades harder (tight coupling, legacy patterns, hidden assumptions)?
Outputs (what this skill should produce)
- Target framework recommendation (latest LTS) and upgrade plan/backlog.
- Version-specific adoption checklist (what to adopt now vs later).
- Cumulative upgrade checklist when crossing multiple majors.
- Risks/breaking-change checklist and required test gates (contract/perf/integration).
- Repository standards updates (packaging, analyzers, SDK pinning, CI enforcement).
Red Flags - STOP
These statements indicate misalignment with .NET best practices:
| Thought | Reality |
| "We'll stay on .NET 6 indefinitely" | LTS versions have end-of-life dates; plan upgrades proactively |
| "Sync-over-async is fine for this case" | Async should be end-to-end; sync-over-async causes thread pool starvation |
| "We don't need analyzers" | Analyzers catch issues at compile time; enable and address warnings |
| "NuGet package versions in csproj are fine" | Use Central Package Management for consistency and security |
| "Security patches can wait" | Runtime security updates need defined SLAs; treat as routine work |
| "AOT/trimming will just work" | Validate compatibility before enabling; many patterns are incompatible |
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.

