dotnet-claude-kit: teaching a coding agent your .NET conventions

The problem the kit is written against

The README states the problem in a way that is specific enough to be testable. Claude Code is powerful, but out of the box it does not know your .NET conventions. It generates DateTime.Now instead of TimeProvider. It wraps EF Core in repository abstractions. It picks an architecture without asking about your domain. And it reads entire source files when a Roslyn query would cost ten times fewer tokens.

Those four complaints are the design brief. The first two are about API and design choices, the third is about the agent making an architectural decision on the user's behalf, and the fourth is about cost.

The answer is described as a curated knowledge and action layer that sits between Claude Code and your .NET project, installed by dropping a single CLAUDE.md into the repository. The README is emphatic about the install: no configuration, no setup wizards, just copy one file and go.

The knowledge layer covers which architecture fits the project, with vertical slice architecture, Clean Architecture, domain driven design and a modular monolith named as the options, and how to write modern C# 14 with primary constructors, collection expressions and records. It also covers building minimal APIs with IEndpointGroup auto-discovery, TypedResults and proper OpenAPI metadata, using EF Core without repository wrappers with compiled queries and interceptors, and testing with WebApplicationFactory and Testcontainers instead of in-memory fakes.

The action layer is the part that makes it more than a style guide, and it is what distinguishes this from the other collections of agent definitions.

The inventory: skills, agents, commands, rules and templates

The header line of the README gives the counts, and they are worth taking at face value as an inventory rather than as a quality measure. There are 47 skills, 10 specialist agents, 16 slash commands, 10 rules, 5 project templates and 22 MCP tools, along with automation hooks. The README also says the kit is built for .NET 10 and C# 14, is architecture-aware and token-efficient.

The repository layout matches that inventory. There is a skills/ directory, an agents/ directory, a hooks/ directory, a knowledge/ directory, a templates/ directory, an mcp/ directory and mcp-configs/, plus a docs/ directory.

What makes it stand out from a plain list of prompts is that the same repository ships for several agent runtimes. There is a .claude-plugin/ directory and a .claude/ directory for Claude Code, a .codex/ directory and an opencode.json for Codex and OpenCode, a .cursor/ directory for Cursor, and a .mcp.json for the MCP server configuration. A single CLAUDE.md is the entry point, and the other runtimes get their own configuration files.

That matters because the agent definition format is not standardised, and a kit that only works in one runtime is a kit that locks you in. This one at least tries to be portable.

The release history also shows that the project is more than one package. The recent releases are v0.11.0 tagged as a Deep Audit Release, CWM.RoslynNavigator v0.8.0 and CWM.RoslynNavigator v0.7.0, and the RoslynNavigator releases are in the same repository, which suggests the MCP server is being developed as a separately consumable component rather than only as part of the plugin.

The Roslyn MCP server and the token argument

The headline capability is surgical code analysis through 22 Roslyn powered MCP tools with guaranteed bounded responses, and the mechanism is worth understanding because it is a different approach to context management rather than a better prompt.

The tools do specific things. get_symbol_source reads one method body instead of the whole file. get_file_outline shows what is in a file before you read it. resolve_stack_trace turns an exception into a file and line in your own code. And analyze_change_impact answers what breaks if I change this in one call.

The bounding is the part that makes it usable. Every list-returning tool reports a Truncated flag, and the README states plainly that no tool can blow your context window. That is a design constraint imposed deliberately, and it is the difference between a tool that is occasionally unusable because it returned 2000 tokens of a file and one that is predictable.

The comparison table puts a number on the claim. Without the kit, codebase navigation reads entire files at 500 to 2000 or more tokens each. With the kit, Roslyn MCP queries cost 30 to 150 tokens each, which the README rounds to about ten times token savings on exploration. Those figures are the project's own, and the reader should treat them as such, but the mechanism is plausible because a Roslyn query returns symbols and references rather than text.

The other tools in the list are governance tools. get_endpoint_map inventories every route with its auth posture, one of authorized, anonymous or unmarked, in one token-cheap call, and the security scan command starts every auth audit there. get_di_registrations maps every service registration with lifetimes, duplicate detection and captive dependency risks, such as a singleton holding a scoped service.

The idea is that the audits a team would otherwise run with a script or by reading are available as bounded queries, and the slash commands orchestrate them.

The slash commands as a quality workflow

The command list is where the kit stops being advice and starts being a process, and each command maps onto a task a .NET team actually has to do.

The architecture check verifies that the code still matches its declared architecture, whether that is vertical slice, Clean, domain driven design or a modular monolith, looking for dependency direction problems, layer violations, module leaks and cycles, and it reports file and line evidence along with fixes.

The dependency health command reports stale packages, CVEs and commercial licence traps, naming MediatR 13 and later, MassTransit 9 and later, FluentAssertions 8 and later and AutoMapper 15 and later. The framing is that an innocent update-all can change your legal position, and the version thresholds are the ones where those packages moved to a paid licence. A command that tells you about a licence change before you pull the package is a genuinely useful thing to have, and it is not something the model would reliably volunteer.

Scaffolding produces a complete feature in one command, with the Result pattern, validation, OpenAPI metadata, pagination, CancellationToken and tests, checked against a nine point checklist, and it works across all four architectures.

The health check performs automated codebase analysis using the MCP tools, with an anti-pattern scan, diagnostics, dead code detection and test coverage, producing a graded report card. The pull request review is multi-dimensional, covering anti-patterns, diagnostics, API surface changes, blast radius, architecture compliance and test coverage.

The convention learning feature is the one that distinguishes the kit from a style guide, because it detects project-specific patterns, in naming, structure and modifiers, and enforces them in new code, adapting to your codebase rather than to a general opinion.

There are also active hooks, which are automated quality scripts: format on edit, a destructive-command guard, and restore on a project file change. Those are tested on Windows and Linux in continuous integration, which is the detail that suggests they are real rather than aspirational.

Where dotnet-claude-kit is the wrong choice

The first limitation is that the kit assumes you have already made the decisions it enforces. It will ask which architecture fits your project, and the whole point of the architecture check is to hold the code to that answer. A team that has not settled on an architecture gets a tool that keeps asking, and a team that has deliberately chosen a mix gets a tool that tells it is inconsistent.

The second is the token saving claim, which is the most repeated and the least independently verifiable figure in the README. The mechanism is credible, since a Roslyn query genuinely returns less text than a file read, but the numbers are the project's own, they are specific to a codebase with a particular shape, and a large file with a lot of comments will still be read. Nobody should reorganise their context budget around a figure in a comparison table.

The third is the surface area. 47 skills, 10 agents, 16 commands, 10 rules, 5 templates, 22 tools and hooks is a lot of material to install into a repository, and a lot of behaviour to reason about when the agent does something unexpected. A team that wants one convention enforced and nothing else has adopted a system.

The fourth is the coupling to a fast-moving platform. The kit targets .NET 10 and C# 14, the README says every package recommendation is verified against NuGet with licensing warnings, and it watches for a .NET 11 preview so the guidance does not rot. That maintenance is the project's own labour, and it is a subscription to somebody else's upkeep.

The fifth is the plugin model itself. This is a plugin plus an MCP server plus configuration for several runtimes, and each of those has its own update path, so the number of things that can be out of date in a given session is larger than it looks.

How dotnet-claude-kit compares with a plain CLAUDE.md and with an MCP server of your own

The comparison with a plain CLAUDE.md is the honest baseline, since the kit's own entry point is a file in the repository. A hand-written CLAUDE.md can say use TimeProvider, do not wrap EF Core in repositories, and follow our layering, and it costs an afternoon.

What the kit adds is the enforcement. The architecture check, the dependency report, the endpoint map and the convention learning are not things a static instruction file can do, because they need to read your code and compare it against something. The claim in the README is that Claude does not just know the right patterns, it actively applies and enforces them, and that difference is real.

The second comparison is with writing your own MCP server over Roslyn. That is the route to the same token savings, and it is entirely reasonable if you want the tools for a different purpose. What you lose is the shipped set of 22 tools, the bounded-response guarantees and the orchestration commands, and the work of building and maintaining a language server bridge is not small. Writing your own is the right answer if the kit's tools do not cover the questions you actually ask of your code.

The third comparison is with the other agent definition collections. A collection of plain prompts is a style guide, portable, small and cheap. This is a toolchain that has to run a Roslyn language server and hook into edits. The trade is capability for machinery, and the right choice depends on whether the enforcement matters more than the simplicity.

The fourth point is about the platform rather than the tool. The repository ships configuration for Claude Code, Codex, OpenCode and Cursor, which suggests the author expects these to be used interchangeably, and that portability is a design goal rather than an accident.

Licence, project state and what to check before you install it

The licence field on the repository records MIT, with a LICENSE file at the root. That is permissive, and it is the right choice for a kit you copy into your own repository and then modify for your own conventions.

The project is not archived and the last push was on 2026-08-07, so it is maintained, with the most recent release being v0.11.0 in July 2026 tagged as a Deep Audit Release, alongside the two RoslynNavigator releases. The 0.x version is consistent with a plugin that is still changing shape.

The repository is organised as a kit rather than a library. The .claude-plugin/ and .claude/ directories hold the Claude Code pieces, with the .codex/, .cursor/ and .opencode/ directories carrying the equivalents for other runtimes, and an opencode.json and a .mcp.json for configuration. The skills/, agents/, hooks/, knowledge/, templates/, mcp/ and mcp-configs/ directories hold the content, with docs/ for the documentation. There is a CHANGELOG.md, a CONTRIBUTING.md, an AGENTS.md and a CLAUDE.md, the last of which is presumably the entry point the README describes.

Four things to check before you install it.

That you have made the architectural decision. The kit enforces one of four, and the architecture check will tell you when the code stops matching it.

Which runtime you are using, and whether the configuration for it is current. The multi-runtime directories are a strength, but they are also the most likely to fall behind.

How much of the 47 skills and 16 commands you actually want enabled, because installing the whole kit and then switching off most of it leaves the token overhead of reading instructions you have disabled.

And the dependency check, because the commercial licence trap warnings are the part of this kit with a concrete financial consequence, and they are only as good as the version thresholds the author maintains.

Editorial conclusion

dotnet-claude-kit suits a .NET team that has already decided its conventions and wants a coding agent to follow them, and that is bothered by how much context the agent burns reading files. It is the wrong tool if you have not settled on an architecture, since the kit will ask you to pick one and enforce it, and the wrong choice if you want a general purpose agent rather than a .NET specific one. Before adopting it, read the comparison table in the README with the numbers in mind as claims rather than measurements, and check the plugin installation section, because this is a plugin and an MCP server rather than a library you reference from a project file.

Frequently asked questions

Official sources

1. codewithmukesh/dotnet-claude-kit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases