In oktober schreef ik over hoe ik apps bouw door tegen mijn computer te praten. Claude Code schrijft de code, ik stuur bij. Dat werkt goed.

Maar Claude past niet uit zichzelf Nederlandse overheidsstandaarden toe. En daar hebben we er nogal wat van. Honderden. API Design Rules, Digikoppeling, OAuth NL, CloudEvents, geo-standaarden, WCAG, en zo verder. Ze staan beschreven in documenten die weinig developers lezen.

En zelfs als een developer zich aan standaarden wíl houden: je weet niet altijd dat er een standaard bestaat voor wat je aan het doen bent. Je bouwt een API en denkt niet aan standaarden. Pas later hoor je dat er API Design Rules zijn. Of nooit.

Niet onwil, maar onwetendheid.

Tools die het wél weten

Claude Code heeft een plugin-systeem met skills1. Een skill is een stuk kennis dat je aan Claude geeft. Geen code. Gewoon een bestand met instructies en referentiemateriaal.

Als je een skill installeert, weet Claude dingen die het anders niet zou weten. Het kent de API Design Rules. Het weet dat er een Spectral linter bestaat om je OpenAPI-spec te valideren. Het kent de Digikoppeling-standaarden. Niet omdat het daar generiek iets over kan zeggen op basis van trainingsdata, maar omdat jij de actuele kennis erin hebt gestopt.

In plaats van dat de developer de standaard moet kennen, kent de tool de standaard.

Hoe ziet dat eruit?

Een skill heet niet voor niets een skill: het is een vaardigheid. En vaardigheden blijken Markdown-bestanden te zijn, wie had dat gedacht. Vaardigheden zien er zo uit:

---
name: ls-api
description: >
  Activeer deze skill bij werk aan REST APIs voor de
  Nederlandse overheid, API Design Rules, OpenAPI
  validatie, of API beveiliging.
model: sonnet
allowed-tools:
  - Bash(npx @stoplight/spectral-cli *)
  - WebFetch(*)
---

**Agent-instructie:** Deze skill helpt bij het implementeren
van APIs conform de NL GOV API Design Rules.

## Repositories

| Repo | Beschrijving |
|------|-------------|
| [API-Design-Rules](https://github.com/Logius-standaarden/API-Design-Rules) | Hoofdrepository |
| [API-Design-Rules-linter](https://github.com/Logius-standaarden/API-Design-Rules-linter) | Spectral linter |

## Technische regels

- Gebruik `kebab-case` voor URI-paden
- Gebruik `camelCase` voor query parameters en JSON-velden
- Versioning via URI-pad (`/v1/`)
- Foutmeldingen conform RFC 7807
...

De description bepaalt wanneer de skill wordt geactiveerd. Bouw je een API, dan herkent Claude dat en laadt de skill. Een beetje zoals in The Matrix, maar dan met overheidsstandaarden in plaats van kung fu.

De allowed-tools bepalen wat de skill mag doen. In dit geval: de Spectral linter draaien om je OpenAPI-spec te controleren, en webpagina’s ophalen voor actuele documentatie.

Je kunt een skill ook handmatig aanroepen. /ls-api activeert de API Design Rules. /ls-dk geeft je Digikoppeling. /ls-iam de OAuth- en OpenID Connect-profielen voor de Nederlandse overheid.

Een marktplaats voor de overheid

Individuele skills zijn nuttig. Maar het wordt pas echt wat als je ze deelt.

Ik heb een marktplaats gemaakt voor de Nederlandse overheid: overheid-claude-plugins. De marktplaats zelf is nog Claude Code-specifiek2. Een register van plugins dat je toevoegt:

claude plugin marketplace add MinBZK/overheid-claude-plugins
claude plugin install logius-standaarden@overheid-plugins

Twee commando’s. Daarna kent Claude Code 88 Logius-standaarden. Omdat ik Markdown-bestanden heb laten genereren door Claude, op basis van de standaarden, met de juiste kennis erin.

Er staan nu vier plugins in:

  • logius-standaarden: 10 skills voor API Design Rules, Digikoppeling, OAuth NL, FSC, en meer
  • nerds: 14 skills voor de Nederlandse Richtlijn Digitale Systemen
  • developer-overheid: 9 skills gebaseerd op developer.overheid.nl
  • zad-actions: 5 skills voor deployment via ZAD

Samen 38 skills.

Zelf een skill maken

Een plugin is een mappenstructuur:

mijn-plugin/
  .claude-plugin/
    plugin.json
  skills/
    mijn-skill/
      SKILL.md
  LICENSE

De plugin.json beschrijft de plugin. De SKILL.md bevat de skill. Dat is het.

Je hoeft geen developer te zijn om een skill te schrijven. Je moet weten welke kennis relevant is en die structureren in Markdown. Een beleidsmedewerker kan dit. Een architect kan dit.

Standaarden die zichzelf verspreiden

Tot nu toe was de aanpak: schrijf een document, publiceer het, hoop dat mensen het lezen.

Skills draaien dat om. De standaard zit in de tool. De developer hoeft niet te weten dat de standaard bestaat. Als die developer iets bouwt dat de standaard raakt, laadt Claude de kennis automatisch.

Dat vervangt het lezen van standaarden niet. Maar het past beter bij hoe developers werken.

Probeer het

Als je Claude Code gebruikt: voeg de marktplaats toe en installeer een plugin. Kijk wat er gebeurt als je een API bouwt en Claude ineens de Design Rules kent.

Als je standaarden beheert: schrijf een skill.

De marktplaats staat open voor bijdragen.

  1. Anthropic heeft skills in december 2025 als open standaard gepubliceerd. Microsoft, OpenAI, GitHub Copilot, Cursor en anderen hebben de standaard overgenomen. Skills werken dus niet alleen in Claude Code. Zie ook de specificatie en de Claude Code documentatie. ↩

  2. De skills zelf zijn een open standaard die ook werkt in Copilot, Cursor, Codex en anderen. De marktplaats als distributiekanaal is voorlopig alleen Claude Code. Het zou me niet verbazen als anderen volgen. ↩