← ClaudeAtlas

dotnet10-conventionslisted

Opinionated C# and .NET 10 coding conventions built around Clean Architecture and plain Dapper: one type per file, file-scoped namespaces, primary constructors, camelCase locals and fields with no underscore prefix, POCO entities with hand written SQL, versioned migration scripts, soft deletes, and a single LookUp catalog table. Use this skill whenever writing, reviewing, refactoring, or scaffolding C# code, solution structures, entities, repositories, services, handlers, DTOs, mappers, or validators for a .NET 10 project that follows these conventions. Also use when creating a new project from scratch, migrating an existing one, or adding a new layer to an existing solution. Apply these conventions without exception unless the user explicitly overrides a rule for a specific case.
GuerthCastro/claude-skills-dotnet · ★ 1 · Code & Development · score 72
Install: claude install-skill GuerthCastro/claude-skills-dotnet
# .NET 10 Coding Conventions Author: Guerth Castro (github.com/GuerthCastro). Licensed under MIT. These are personal, opinionated conventions refined over years of production .NET work. They are deliberately strict: the value is in consistency, not in flexibility. Adopt them whole, or fork and change the rules you disagree with. Everything here runs on plain Dapper and hand written SQL. There is no ORM to install and no base library to reference: the few shared types below are small enough to paste into your own solution and own outright. Placeholders used throughout: `Acme` is the company or organization prefix, `Product` is the product or bounded context name. Replace both with your own. ## Non-negotiable rules - One file per class, interface, enum, or record. No exceptions. - File-scoped namespaces always: `namespace Acme.Product.Domain;`. Never block-style with braces. - Primary constructors always. Do not declare private backing fields unless the field is mutated after construction, consumed by reflection or serialization, or requires derivation with guard clauses. - No XML doc comments (`///`) and no inline comments. Names and tests are the documentation. When a comment feels necessary, the code is not clear enough yet: extract a named method, rename the variable, or tighten the type so the fact becomes structural. Reasoning that genuinely cannot live in code goes in the commit message or the pull request, not the source. There is exactly one standing