In October I wrote about building apps by talking to my computer. Claude Code writes the code, I steer. Works well.

But Claude doesn’t apply Dutch government standards on its own. And we have quite a few of those. Hundreds. API Design Rules, Digikoppeling, OAuth NL, CloudEvents, geo standards, WCAG, and so on. They’re described in documents that few developers read.

Even when a developer wants to follow standards: you don’t always know a standard exists for what you’re doing. You build an API and don’t think about standards. Only later you hear there are API Design Rules. Or never.

Not unwillingness. Unawareness.

Tools that do know

Claude Code has a plugin system with skills1. A skill is a piece of knowledge you give to Claude. Not code. Just a file with instructions and reference material.

Install a skill, and Claude knows things it otherwise wouldn’t. It knows the API Design Rules. It knows there’s a Spectral linter to validate your OpenAPI spec. It knows the Digikoppeling standards. Not because it can say something generic from training data, but because you put the actual knowledge in.

Instead of the developer knowing the standard, the tool knows the standard.

What does it look like?

A skill is called a skill for a reason: it’s a capability. And capabilities turn out to be Markdown files, who would have guessed. They look like this:

---
name: ls-api
description: >
  Activate this skill when working on REST APIs for the
  Dutch government, API Design Rules, OpenAPI validation,
  or API security.
model: sonnet
allowed-tools:
  - Bash(npx @stoplight/spectral-cli *)
  - WebFetch(*)
---

**Agent instruction:** This skill helps implement APIs
conforming to the NL GOV API Design Rules.

## Repositories

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

## Technical rules

- Use `kebab-case` for URI paths
- Use `camelCase` for query parameters and JSON fields
- Versioning via URI path (`/v1/`)
- Error responses conform to RFC 7807
...

The description controls when the skill gets activated. Build an API, Claude sees that and loads the skill. A bit like The Matrix, but with government standards instead of kung fu.

The allowed-tools say what the skill can do. In this case: run the Spectral linter to check your OpenAPI spec, and fetch web pages for current documentation.

You can also invoke a skill manually. /ls-api activates the API Design Rules. /ls-dk gives you Digikoppeling. /ls-iam the OAuth and OpenID Connect profiles for the Dutch government.

A marketplace for government

Individual skills are useful. But it gets interesting when you share them.

I built a marketplace for the Dutch government: overheid-claude-plugins. The marketplace itself is still Claude Code-specific2. A plugin registry you add:

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

Two commands. After that Claude Code knows 88 Logius standards. Because I had Claude generate Markdown files from the standards, with the right knowledge in them.

Four plugins so far:

  • logius-standaarden: 10 skills for API Design Rules, Digikoppeling, OAuth NL, FSC, and more
  • nerds: 14 skills for the Dutch Digital Systems Guidelines
  • developer-overheid: 9 skills based on developer.overheid.nl
  • zad-actions: 5 skills for deployment via ZAD

Together 38 skills.

Making your own skill

A plugin is a directory structure:

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

The plugin.json describes the plugin. The SKILL.md contains the skill. That’s it.

You don’t have to be a developer to write a skill. You need to know which knowledge is relevant and structure it in Markdown. A policy officer can do this. An architect can do this.

Standards that spread themselves

Until now the approach was: write a document, publish it, hope people read it.

Skills turn that around. The standard lives in the tool. The developer doesn’t need to know the standard exists. When they build something the standard applies to, Claude loads the knowledge automatically.

Doesn’t replace reading standards. But it fits better with how developers work.

Try it

If you use Claude Code: add the marketplace and install a plugin. Watch what happens when you build an API and Claude suddenly knows the Design Rules.

If you maintain standards: write a skill.

The marketplace is open for contributions.

  1. Anthropic published skills in December 2025 as an open standard. Microsoft, OpenAI, GitHub Copilot, Cursor and others adopted the standard. Skills work in more than just Claude Code. See also the specification and the Claude Code docs. ↩

  2. The skills themselves are an open standard that works in Copilot, Cursor, Codex and others. The marketplace as distribution channel is Claude Code only for now. Wouldn’t surprise me if others follow. ↩