using-dotnet

using-dotnet

Scope

• Establishing .NET/C# routing discipline before clarifying questions, planning, command execution, or edits.
• Detecting .NET intent from prompt and repository signals (.sln, .slnx, .csproj, global.json, .cs).
• Enforcing first-step routing through dotnet-advisor and baseline loading order.
• Defining priority and rigidity rules for downstream skill invocation.

Out of scope

• C# implementation details and coding-standard specifics -> dotnet-csharp
• Deep domain implementation patterns -> dotnet-api, dotnet-ui, dotnet-testing, dotnet-devops, dotnet-tooling, dotnet-debugging
• Specialist deep-review workflows -> dotnet-security-reviewer, dotnet-performance-analyst, dotnet-testing-specialist

Simplicity First (KISS)

Write the simplest code that solves the problem. Agents consistently over-engineer — more abstractions, more layers, more indirection than the task warrants.

• Do the direct thing. If you need a file, create it — don't write code that generates it. If you need data, put it where it belongs — don't assemble it from embedded strings at runtime. When you catch yourself building something indirect (a generator, a template, a wrapper), stop and ask: "Can I just do this directly?"
• Write readable code, not clever code. A plain if/else over a chain of ternaries. A foreach over a hard-to-read LINQ expression. A flat method over nested callbacks. Clear beats compact. This does NOT mean avoiding modern C# — use latest language features ([..4], list patterns, primary constructors, raw string literals, collection expressions). Modern syntax is concise AND readable. The target is convoluted logic, not concise syntax.
• Don't add what wasn't asked for. No extra config options, no "while we're at it" refactors, no preemptive error handling for impossible scenarios, no comments or XML docs on code unrelated to the current task.
• Match architecture to scope. Simple CRUD doesn't need DDD, MediatR, CQRS, or a pipeline of behaviors. A 20-line handler doesn't need 5 files. Scale the pattern to the problem.
• Earn every abstraction. Don't create IOrderService for one OrderService. Don't extract a helper for something that happens once. Three similar lines of code are fine — extract only when a real pattern emerges across 3+ call sites.
• Use what the framework gives you. DbContext is your Unit of Work. DbSet<T> is your repository. .NET has TimeProvider, ILogger<T>, IHttpClientFactory, System.Text.Json. Use them directly — don't wrap, don't abstract, don't add a NuGet package for something the framework already does.
• Fewer files, fewer layers. In new or small projects, don't split into Controller + Service + Repository + DTO + Mapper + Interface when one or two files will do. In existing codebases, follow the established patterns. Add layers only when the code gets hard to understand without them.