Claude Code already knows C#. It can write controllers, set up dependency injection, scaffold EF Core migrations. But it doesn’t know your project. It doesn’t know your team uses MediatR for everything, or that you always put integration tests in a separate project with a specific naming convention.
That’s where skills and plugins come in. They turn Claude Code from a general-purpose assistant into a .NET specialist that understands your exact workflow.
What are skills?
Skills are reusable prompt templates that teach Claude Code specific workflows. Think of them as experience in a file. You write down how something should be done, and Claude follows that pattern every time.
A skill is defined in a SKILL.md file. It lives in a repository (yours or someone else’s), and once installed, Claude Code reads it as context whenever you work on a relevant task. No API calls, no external services — just structured instructions that guide Claude’s behavior.
The key difference from a regular CLAUDE.md is scope. Your CLAUDE.md describes your project. A skill describes a workflow that works across projects. Testing patterns. Code generation templates. Architecture conventions.
What are plugins?
Plugins extend Claude Code with external tools and integrations. Where skills are instructions, plugins are capabilities. They add new tools that Claude can call during a session.
A plugin might connect Claude Code to your database, your CI pipeline, or a third-party API. It uses the Model Context Protocol (MCP) to expose these tools in a standardized way. I wrote about building MCP servers in an earlier post.
For .NET developers, plugins are interesting when you want Claude to interact with things outside your codebase — running specific dotnet CLI commands, querying a package registry, or connecting to Azure DevOps.
The marketplace: the /install command
Claude Code has a built-in way to browse and install community skills and plugins. In a Claude Code session, type:
/install
This opens the marketplace — a curated list of skills and plugins you can install directly. You can search by keyword, browse by category, or look at what’s popular in the community.
When you find something interesting, installing it is a single command. Claude Code downloads the skill or plugin and adds it to your configuration. For skills, this means the SKILL.md files are stored locally. For plugins, it sets up the MCP server configuration.
You can also install directly from a GitHub repository:
/install aaronontheweb/dotnet-skills
This pulls skills from a specific repo without browsing the marketplace first. Useful when someone shares a link in a blog post or on social media.
.NET-specific skills worth installing
The most comprehensive .NET skill collection I’ve found is dotnet-skills by Aaron Stannard (Aaronontheweb). It contains 30+ skills covering:
- EF Core — migration strategies, query optimization, relationship configuration
- Testing — xUnit patterns, integration testing with
WebApplicationFactory, mocking with NSubstitute - Aspire — service discovery, orchestration, dashboard setup
- Architecture — clean architecture templates, MediatR patterns, vertical slice structure
- Performance — benchmarking with BenchmarkDotNet, memory profiling patterns
What makes these skills valuable is the specificity. The EF Core skill doesn’t just say “use EF Core.” It describes when to use AsNoTracking(), how to structure complex queries, when to drop down to raw SQL. It encodes the kind of knowledge that usually lives in a senior developer’s head.
Other community skills worth looking at:
- Minimal API patterns — structuring endpoints, validation with FluentValidation, OpenAPI configuration
- Blazor component skills — component lifecycle, state management, JS interop patterns
- Azure deployment skills — ARM templates, Bicep, App Service configuration
Using an installed skill
Let me walk through a concrete example. After installing the dotnet-skills collection, I open a .NET project and ask Claude to write an integration test.
Without the skill, Claude writes a basic test with HttpClient and hardcoded URLs. It works, but it’s not how a production .NET project does integration testing.
With the testing skill installed, Claude knows to:
- Use
WebApplicationFactory<Program>as the test base - Set up a custom
IServiceCollectionfor test dependencies - Use
IClassFixturefor shared setup - Create a proper test database with a unique name per test class
public class OrderEndpointTests : IClassFixture<WebApplicationFactory<Program>>
{
private readonly HttpClient _client;
public OrderEndpointTests(WebApplicationFactory<Program> factory)
{
_client = factory.WithWebHostBuilder(builder =>
{
builder.ConfigureServices(services =>
{
// Replace the real database with an in-memory one
services.RemoveAll<DbContextOptions<AppDbContext>>();
services.AddDbContext<AppDbContext>(options =>
options.UseInMemoryDatabase($"TestDb-{Guid.NewGuid()}"));
});
}).CreateClient();
}
[Fact]
public async Task CreateOrder_ReturnsCreated()
{
var order = new CreateOrderRequest("Test Product", 2);
var response = await _client.PostAsJsonAsync("/api/orders", order);
response.StatusCode.Should().Be(HttpStatusCode.Created);
}
}
The skill taught Claude the right way to do it. Not just a working way, but the way your team would expect to see in a code review.
Creating your own skill
Community skills are great, but the real power is creating skills for your own team’s conventions. A SKILL.md file is just Markdown with structured instructions.
Here’s a simple example for a team that uses a specific service pattern:
# Service Layer Conventions
## When to apply
When creating or modifying service classes in the `Services/` directory.
## Rules
- Every service implements an interface in `Abstractions/`
- Constructor injection only — no service locator
- All public methods return `Result<T>` (not exceptions for business logic)
- Logging: inject `ILogger<T>`, log at method entry (Debug) and on errors (Error)
- Validation happens in the service, not the controller
## Example structure
\```csharp
public class OrderService : IOrderService
{
private readonly ILogger<OrderService> _logger;
private readonly AppDbContext _context;
public OrderService(ILogger<OrderService> logger, AppDbContext context)
{
_logger = logger;
_context = context;
}
public async Task<Result<OrderDto>> GetByIdAsync(int id)
{
_logger.LogDebug("Getting order {OrderId}", id);
var order = await _context.Orders.FindAsync(id);
if (order is null)
return Result<OrderDto>.NotFound($"Order {id} not found");
return Result<OrderDto>.Success(order.ToDto());
}
}
\```
Put this in your repo, and every developer on the team gets the same Claude behavior. New team members don’t need to memorize the conventions — Claude already knows them.
Plugins vs. skills: when to use which
This confused me at first. Here’s the simple rule:
Use a skill when you want Claude to follow a pattern or convention. Skills are instructions. They don’t add new capabilities — they shape how Claude uses the capabilities it already has.
Use a plugin when you need Claude to interact with something external. A database, a CI system, an API. Plugins add tools that Claude can call.
In practice, most .NET developers will use far more skills than plugins. Your day-to-day work is writing code that follows patterns, and that’s exactly what skills excel at. Plugins are for specific integrations — connecting to Azure, querying NuGet, interacting with your ticketing system.
Limitations and caveats
Skills are not magic. They’re context, and context has limits.
Token budget. Every installed skill uses tokens from your context window. Install thirty skills and Claude has less room to think about your actual code. Be selective — install what you actually use.
Quality varies. Community skills are written by humans with different experience levels. Some are excellent. Some are outdated. Always review a skill before installing it, just like you’d review a NuGet package.
Skills don’t enforce. A skill tells Claude what to do, but Claude can still deviate. If your instruction conflicts with what’s in the codebase, Claude might follow the code instead of the skill. Combine skills with hooks for actual enforcement.
Plugins need maintenance. MCP servers are software. They break, they need updates, they have bugs. If a plugin connects to an external API, that API can change. Keep your plugin list lean.
Start exploring
Here’s what I’d do this week:
- Run
/installin your next Claude Code session and browse what’s available - Install dotnet-skills by Aaronontheweb and try it on a real project
- Write one
SKILL.mdfor your team’s most common pattern — the one you keep explaining in code reviews
Skills are the fastest way to go from “Claude writes decent C#” to “Claude writes C# the way my team writes C#.” And that difference matters more than you think.