Claude Code kent C# al. Het kan controllers schrijven, dependency injection opzetten, EF Core-migraties genereren. Maar het kent jouw project niet. Het weet niet dat je team overal MediatR gebruikt, of dat integratietests altijd in een apart project staan met een specifieke naamconventie.
Dat is precies waar skills en plugins voor zijn. Ze maken van Claude Code een .NET-specialist die jouw exacte werkwijze begrijpt.
Wat zijn skills?
Skills zijn herbruikbare prompttemplates die Claude Code specifieke workflows aanleren. Zie het als ervaring in een bestand. Je schrijft op hoe iets gedaan moet worden, en Claude volgt dat patroon elke keer.
Een skill wordt gedefinieerd in een SKILL.md-bestand. Het leeft in een repository (van jou of van iemand anders), en eenmaal geinstalleerd leest Claude Code het als context wanneer je aan een relevante taak werkt. Geen API-calls, geen externe services — gewoon gestructureerde instructies die Claude’s gedrag sturen.
Het verschil met een gewone CLAUDE.md is de scope. Je CLAUDE.md beschrijft jouw project. Een skill beschrijft een workflow die werkt over projecten heen. Testpatronen. Code-generatietemplates. Architectuurconventies.
Wat zijn plugins?
Plugins breiden Claude Code uit met externe tools en integraties. Waar skills instructies zijn, zijn plugins mogelijkheden. Ze voegen nieuwe tools toe die Claude kan aanroepen tijdens een sessie.
Een plugin kan Claude Code verbinden met je database, je CI-pipeline of een externe API. Het gebruikt het Model Context Protocol (MCP) om deze tools op een gestandaardiseerde manier beschikbaar te stellen. Ik schreef eerder over het bouwen van MCP-servers in een eerdere post.
Voor .NET-developers zijn plugins interessant wanneer je wilt dat Claude interactie heeft met dingen buiten je codebase — specifieke dotnet CLI-commando’s draaien, een package registry bevragen, of verbinden met Azure DevOps.
De marketplace: het /install-commando
Claude Code heeft een ingebouwde manier om community skills en plugins te browsen en te installeren. In een Claude Code-sessie typ je:
/install
Dit opent de marketplace — een gecureerde lijst van skills en plugins die je direct kunt installeren. Je kunt zoeken op trefwoord, browsen per categorie, of kijken wat populair is in de community.
Als je iets interessants vindt, is installeren een enkel commando. Claude Code downloadt de skill of plugin en voegt het toe aan je configuratie. Voor skills betekent dit dat de SKILL.md-bestanden lokaal worden opgeslagen. Voor plugins wordt de MCP-serverconfiguratie opgezet.
Je kunt ook direct vanuit een GitHub-repository installeren:
/install aaronontheweb/dotnet-skills
Dit haalt skills op uit een specifieke repo zonder eerst de marketplace te browsen. Handig wanneer iemand een link deelt in een blogpost of op social media.
.NET-specifieke skills die het installeren waard zijn
De meest uitgebreide .NET skill-collectie die ik heb gevonden is dotnet-skills van Aaron Stannard (Aaronontheweb). Het bevat 30+ skills voor:
- EF Core — migratiestrategieen, query-optimalisatie, relatie-configuratie
- Testing — xUnit-patronen, integratietesten met
WebApplicationFactory, mocking met NSubstitute - Aspire — service discovery, orchestratie, dashboard-setup
- Architectuur — clean architecture templates, MediatR-patronen, vertical slice structuur
- Performance — benchmarking met BenchmarkDotNet, memory profiling patronen
Wat deze skills waardevol maakt is de specificiteit. De EF Core skill zegt niet alleen “gebruik EF Core.” Het beschrijft wanneer je AsNoTracking() inzet, hoe je complexe queries structureert, wanneer je terugvalt op raw SQL. Het legt het soort kennis vast dat normaal alleen in het hoofd van een senior developer zit.
Andere community skills die het bekijken waard zijn:
- Minimal API-patronen — endpoints structureren, validatie met FluentValidation, OpenAPI-configuratie
- Blazor component skills — component lifecycle, state management, JS interop patronen
- Azure deployment skills — ARM templates, Bicep, App Service configuratie
Een geinstalleerde skill gebruiken
Laat me een concreet voorbeeld doorlopen. Na het installeren van de dotnet-skills collectie open ik een .NET-project en vraag Claude om een integratietest te schrijven.
Zonder de skill schrijft Claude een basale test met HttpClient en hardcoded URL’s. Het werkt, maar het is niet hoe een productie .NET-project integratietesten doet.
Met de testing skill geinstalleerd weet Claude:
WebApplicationFactory<Program>te gebruiken als testbasis- Een custom
IServiceCollectionop te zetten voor testdependencies IClassFixturete gebruiken voor gedeelde setup- Een echte testdatabase te maken met een unieke naam per testklasse
public class OrderEndpointTests : IClassFixture<WebApplicationFactory<Program>>
{
private readonly HttpClient _client;
public OrderEndpointTests(WebApplicationFactory<Program> factory)
{
_client = factory.WithWebHostBuilder(builder =>
{
builder.ConfigureServices(services =>
{
// Vervang de echte database met een in-memory variant
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);
}
}
De skill heeft Claude de juiste manier aangeleerd. Niet zomaar een werkende manier, maar de manier die je team verwacht bij een code review.
Je eigen skill maken
Community skills zijn geweldig, maar de echte kracht zit in skills maken voor de conventies van je eigen team. Een SKILL.md-bestand is gewoon Markdown met gestructureerde instructies.
Hier is een eenvoudig voorbeeld voor een team dat een specifiek servicepatroon gebruikt:
# Service Layer Conventies
## Wanneer toepassen
Bij het aanmaken of wijzigen van serviceklassen in de `Services/`-directory.
## Regels
- Elke service implementeert een interface in `Abstractions/`
- Alleen constructor injection — geen service locator
- Alle publieke methoden retourneren `Result<T>` (geen exceptions voor businesslogica)
- Logging: injecteer `ILogger<T>`, log bij method entry (Debug) en bij errors (Error)
- Validatie gebeurt in de service, niet in de controller
## Voorbeeldstructuur
\```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());
}
}
\```
Zet dit in je repo, en elke developer in het team krijgt hetzelfde Claude-gedrag. Nieuwe teamleden hoeven de conventies niet uit hun hoofd te leren — Claude kent ze al.
Plugins vs. skills: wanneer gebruik je wat?
Dit was voor mij in het begin verwarrend. Hier is de simpele regel:
Gebruik een skill als je wilt dat Claude een patroon of conventie volgt. Skills zijn instructies. Ze voegen geen nieuwe mogelijkheden toe — ze sturen hoe Claude de mogelijkheden gebruikt die het al heeft.
Gebruik een plugin als je wilt dat Claude interactie heeft met iets externs. Een database, een CI-systeem, een API. Plugins voegen tools toe die Claude kan aanroepen.
In de praktijk gebruik je als .NET-developer veel meer skills dan plugins. Je dagelijkse werk is code schrijven die patronen volgt, en dat is precies waar skills in uitblinken. Plugins zijn voor specifieke integraties — verbinden met Azure, NuGet bevragen, interactie met je ticketsysteem.
Beperkingen en kanttekeningen
Skills zijn geen magie. Het is context, en context heeft grenzen.
Tokenbudget. Elke geinstalleerde skill gebruikt tokens uit je contextvenster. Installeer dertig skills en Claude heeft minder ruimte om na te denken over je daadwerkelijke code. Wees selectief — installeer wat je ook echt gebruikt.
Kwaliteit varieert. Community skills zijn geschreven door mensen met verschillende ervaringsniveaus. Sommige zijn uitstekend. Sommige zijn verouderd. Review een skill altijd voordat je hem installeert, net zoals je een NuGet-package zou reviewen.
Skills dwingen niet af. Een skill vertelt Claude wat het moet doen, maar Claude kan er nog steeds van afwijken. Als je instructie conflicteert met wat er in de codebase staat, volgt Claude mogelijk de code in plaats van de skill. Combineer skills met hooks voor daadwerkelijke afdwinging.
Plugins vergen onderhoud. MCP-servers zijn software. Ze breken, ze moeten geupdate worden, ze hebben bugs. Als een plugin verbindt met een externe API, kan die API veranderen. Houd je pluginlijst compact.
Begin met verkennen
Dit is wat ik deze week zou doen:
- Draai
/installin je volgende Claude Code-sessie en browse wat er beschikbaar is - Installeer dotnet-skills van Aaronontheweb en probeer het op een echt project
- Schrijf een
SKILL.mdvoor het meestvoorkomende patroon van je team — dat patroon dat je steeds opnieuw uitlegt bij code reviews
Skills zijn de snelste manier om te gaan van “Claude schrijft degelijk C#” naar “Claude schrijft C# zoals mijn team het schrijft.” En dat verschil is groter dan je denkt.