In deel 1 maakte je van een conventie een skill en committe je die in de repo. Iedereen die de repo cloont krijgt hem. Opgelost — voor één conventie, in één repo.

Maar je echte setup is meer dan één skill.

Het is de add-endpoint-skill én een subagent die diffs reviewt zoals jouw team reviewt én een hook die na elke edit dotnet build draait zodat niemand code merged die niet compileert én een MCP-server gericht op je staging-database. Dat zijn vier dingen, op vier plekken, en je team heeft tien mensen en twaalf repo’s.

Dat allemaal met de hand rondkopiëren is hoe drift ontstaat. De ene repo heeft de nieuwste review-subagent, de andere die van vorige maand. Eén developer heeft de build-hook opgezet, drie niet. Binnen één sprint is “hoe we werken” op elke machine anders.

Een plugin lost dat op. Hij bundelt de hele setup en installeert hem met één commando.

Wat een plugin eigenlijk is

Een plugin is een geversioneerde bundel Claude Code-uitbreidingen. Eén map kan bevatten:

  • skills — zoals de add-endpoint-skill uit deel 1,
  • subagents — gespecialiseerde agents met hun eigen context, bv. een code reviewer,
  • commands — je eigen slash-commando’s,
  • hooks — scripts die afgaan op lifecycle-events (voordat een tool draait, na een edit, als Claude klaar is),
  • MCP-definities — verbindingen met je database, issue tracker of interne API’s.

Eén /plugin install en een developer heeft het allemaal in één keer. Update de plugin, verhoog de versie, en iedereen haalt dezelfde wijziging op. Geen gists, geen “kopieer mijn config”, geen Slack-thread met de titel “mijn Claude Code-setup (definitief)(v2)”.

De blog heeft al een post over plugins ontdekken in de marketplace. Deze gaat over de andere richting: je eigen plugin bouwen en verschepen.

De opbouw

Een plugin is gewoon een map met een manifest. Hier een minimale team-plugin:

acme-dotnet/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── add-endpoint/
│       └── SKILL.md          # de skill uit deel 1
├── agents/
│   └── dotnet-reviewer.md    # een review-subagent
└── hooks/
    └── hooks.json            # draai dotnet build na edits

Het manifest bindt alles samen:

{
  "name": "acme-dotnet",
  "version": "1.0.0",
  "description": "Acme's gedeelde Claude Code-setup voor .NET-services.",
  "author": "Platform team"
}

Dat is het hele idee: neem de dingen die je al hebt en zet ze onder één dak met een versienummer.

De onderdelen

De skill schreef je al in deel 1. Zet de map er ongewijzigd in.

De subagent is een markdown-bestand met wat front matter — een reviewer die jouw .NET-valkuilen kent:

---
name: dotnet-reviewer
description: Reviewt een diff op onze .NET-conventies vóór een PR.
tools: Read, Grep, Bash
---

Je reviewt C#-wijzigingen voor dit team. Signaleer, op volgorde van
ernst:

- `async void` buiten event handlers
- endpoints die een exception gooien i.p.v. `Result<T>` teruggeven
- `DbContext` die rechtstreeks vanuit een handler wordt gebruikt
- EF Core-queries die een N+1 gaan opleveren
- nieuwe publieke API zonder xUnit-test

Rapporteer alleen wat je zeker weet. Geen stijl-muggenzifterij.

De hook is waar een plugin zijn geld verdient, want een hook draait deterministisch — hij is niet afhankelijk van of iemand het onthoudt. Deze bouwt na elke edit, zodat een compile-fout in seconden opduikt in plaats van in CI:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "dotnet build --nologo -clp:ErrorsOnly"
          }
        ]
      }
    ]
  }
}

Een skill suggereert hoe je code schrijft. Een hook controleert het, elke keer, op elke machine die de plugin heeft. Dat verschil is de hele reden om ze samen te bundelen.

Het naar het team verschepen

Je distribueert een plugin via een marketplace — wat groter klinkt dan het is. Een marketplace is gewoon een git-repo met een klein indexbestand, en dat mag een privé-repo in je eigen GitHub-org zijn.

Voeg een .claude-plugin/marketplace.json toe die je plugin vermeldt, en een teamlid draait:

# eenmalig, om je interne marketplace toe te voegen
/plugin marketplace add acme/claude-tooling

# daarna de bundel installeren
/plugin install acme-dotnet@acme-tooling

Meer is het niet. Ze hebben nu de skill, de reviewer en de build-hook — dezelfde versies als jij.

Als de conventie verandert, verander je het op één plek. Verhoog de versie, en iedereen krijgt de update de volgende keer dat ze de plugin ophalen. De manier waarop je team werkt heeft nu een release-proces, net als je code.

Waar dit scherp wordt

Twee dingen om serieus te nemen, want een plugin is krachtiger dan een skill.

Hooks draaien code op de machines van je collega’s. Dat dotnet build-commando is onschuldig, maar het mechanisme is niet kieskeurig — een hook kan van alles draaien. Als je een plugin verscheept, vraag je mensen die te vertrouwen zoals ze een dependency vertrouwen. Houd de repo toegangsbeheerd, review hook-wijzigingen als productiecode, en haal nooit een plugin je teamsetup in die je niet hebt gelezen.

Een gedeelde setup verspreidt een fout net zo snel als een fix. Het voordeel van “iedereen krijgt meteen hetzelfde” heeft een voor de hand liggend nadeel. Een kapotte hook hindert niet één persoon; hij legt het hele team stil. Versioneer dus bewust, en behandel een plugin-release met dezelfde zorg als een deploy — want voor de workflow van je team is het er een.

Probeer het deze week

Neem de skill die je na deel 1 schreef en voeg er precies één ding aan toe: één hook die na edits dotnet build draait (of je snelste testproject). Zet beide in een plugin-map met een plugin.json, push het naar een repo, en laat één collega het installeren.

Je rolt het nog niet uit naar iedereen — je bewijst de loop: één keer bouwen, overal installeren, op één plek updaten.

Hoe distribueer jij vandaag je Claude Code-setup — een plugin, een gedeelde repo, of nog met de hand kopiëren? Laat het weten in de comments. Ik vermoed dat de meeste teams hier verder achterlopen dan ze willen toegeven, en ik zie graag hoe mensen het oplossen.

Dit is deel 2 van een korte serie over Claude Code inzetten over een heel team. Deel 1 was de gedeelde skill.

Volgende — deel 3, op 3 augustus: de ongemakkelijke vraag. Als je hele team zó snel AI-geschreven code oplevert, wie is er dan eigenlijk verantwoordelijk voor — en hoe bouw je de review-gates die een mens in de lus houden?