Je typt voor de vijfde keer deze week dezelfde instructie in. Hoe je artikelen wilt opmaken, welke checks er voor een release moeten gebeuren, hoe jullie commitberichten eruitzien. Elke sessie opnieuw, want Claude begint elke keer met een leeg hoofd.

Skills lossen precies dat op. Je schrijft de instructie één keer op in een bestand, en vanaf dat moment kan Claude hem oppakken wanneer hij relevant is. In dit artikel leggen we uit wat een skill is, hoe je er zelf een maakt en waar je op moet letten.

Wat is een skill?

Een skill is een map met daarin een tekstbestand dat SKILL.md heet. In dat bestand staat wat Claude moet doen. Meer is het niet, en die eenvoud is precies het punt.

De naam van de map wordt het commando. Zet je een map huisstijl op de juiste plek, dan kun je in een sessie /huisstijl typen en laadt Claude de instructies. Claude kan de skill ook zelf oppakken wanneer hij bij je vraag past, zonder dat je iets typt.

Wanneer maak je een skill?

De vuistregel is simpel: wanneer je dezelfde instructie, checklist of werkwijze voor de tweede of derde keer intypt.

Een tweede signaal is dat een stukje van je CLAUDE.md is uitgegroeid van een feit naar een procedure. “Dit project gebruikt pnpm” is een feit en hoort in CLAUDE.md. “Om een release uit te brengen doe je achtereenvolgens dit, dit en dit” is een procedure en hoort in een skill.

Dat onderscheid heeft een praktische reden. CLAUDE.md wordt bij elke sessie volledig meegelezen en kost dus altijd ruimte. De inhoud van een skill wordt alleen geladen wanneer die daadwerkelijk gebruikt wordt. Lange naslaginformatie kost je zo bijna niets tot het moment dat je het nodig hebt.

Je eerste skill maken

We maken een skill die je artikelen nakijkt op je eigen stijlregels. Drie stappen.

Maak de map aan. Open een terminal en typ:

mkdir -p ~/.claude/skills/huisstijl

Die locatie, met de tilde vooraan, is je persoonlijke skills-map. Skills die daar staan werken in al je projecten.

Schrijf het SKILL.md-bestand. Maak in die map een bestand met de naam SKILL.md en zet daarin bijvoorbeeld dit:

---
description: Controleert een tekst op onze huisstijlregels. Gebruik dit wanneer de gebruiker een artikel, blogpost of nieuwsbericht laat nakijken of herschrijven.
---

Controleer de tekst op deze punten:

1. Geen gedachtestreepjes, gebruik komma's of dubbele punten
2. Geen emoji in de lopende tekst
3. Geen samenvatting aan het einde van het artikel
4. Geen opsommingen waar een gewone zin volstaat
5. Actieve zinnen, geen lijdende vorm

Geef per punt aan of het klopt. Noem de zinnen die aangepast moeten worden
en stel een concrete herschrijving voor.

Het stukje tussen de streepjes bovenaan heet frontmatter. Daar staan de instellingen. Alles daaronder zijn de instructies die Claude volgt.

Test hem. Start Claude Code in een map en typ /huisstijl, of vraag simpelweg om een tekst na te kijken. In het tweede geval besluit Claude zelf of de skill van toepassing is.

Het belangrijkste veld is de description

Hier gaat het bij beginners bijna altijd mis, dus lees dit stuk twee keer.

De description is geen documentatie voor jou, maar de trigger voor Claude. Claude ziet aan het begin van elke sessie een lijst met alle skillnamen en hun descriptions. Op basis van die tekst besluit hij of een skill relevant is voor wat je vraagt. De inhoud van het SKILL.md-bestand ziet hij op dat moment nog niet.

Een vage description betekent dus een skill die nooit afgaat. “Helpt met teksten” is te breed. Beter is: “Controleert een tekst op onze huisstijlregels. Gebruik dit wanneer de gebruiker een artikel of blogpost laat nakijken of herschrijven.” Die tweede versie bevat woorden die jij daadwerkelijk gebruikt als je iets vraagt.

Zet het belangrijkste gebruiksscenario vooraan. De tekst wordt afgekapt als je veel skills hebt, en dan verdwijnt de staart als eerste.

Waar sla je een skill op?

De plek bepaalt wie de skill kan gebruiken.

Zet je hem in ~/.claude/skills/, dan is hij persoonlijk en werkt hij in al je projecten op deze computer. Dat is de juiste plek voor je eigen manier van werken.

Zet je hem in .claude/skills/ binnen een projectmap, dan hoort hij bij dat project. Commit je die map naar Git, dan krijgt je hele team de skill erbij. Dat is de juiste plek voor afspraken die bij de code horen en niet bij jou.

Hebben een persoonlijke en een projectskill dezelfde naam, dan wint de persoonlijke. Handig om te weten als je afwijkt van een teamafspraak.

Wie mag een skill starten?

Standaard kunnen jullie beiden een skill aanroepen: jij met een schuine streep, Claude automatisch. Voor sommige skills wil je dat niet.

Neem een skill die iets publiceert of verstuurt. Die wil je niet laten afgaan omdat Claude besluit dat je code er klaar voor uitziet. Voeg in dat geval een regel toe aan de frontmatter:

---
description: Publiceert het artikel naar de site
disable-model-invocation: true
---

Vanaf dat moment kun jij de skill starten en Claude niet. Probeert hij het alsnog, dan wordt de aanroep geblokkeerd en stelt hij voor dat jij het commando zelf typt.

Het omgekeerde bestaat ook. Met user-invocable: false mag alleen Claude de skill oppakken. Dat is nuttig voor achtergrondkennis die geen actie is. Een skill die uitlegt hoe een oud systeem in elkaar zit, bijvoorbeeld: Claude moet dat weten wanneer het relevant is, maar het is geen commando dat jij zou willen typen.

Meer dan één bestand

Een skill hoeft niet uit één bestand te bestaan. In dezelfde map kun je voorbeelden, sjablonen, lange naslagdocumenten en scripts kwijt.

Verwijs er dan wel naar vanuit SKILL.md, zodat Claude weet wat er in die bestanden staat en wanneer hij ze moet openen. Iets als: “voor de volledige stijlgids, zie naslag.md”. Zonder die verwijzing blijven de bestanden onaangeroerd.

Houd SKILL.md zelf kort, onder de vijfhonderd regels. Alles wat je erin zet blijft na het laden de rest van de sessie in het geheugen zitten en kost dus doorlopend ruimte. Schrijf wat er moet gebeuren, niet waarom.

Skills die er al zijn

Claude Code komt met een aantal ingebouwde skills die je meteen kunt gebruiken. Typ een schuine streep in een sessie en je ziet ze langskomen.

Een paar bruikbare: /doctor controleert je installatie en instellingen, /code-review kijkt je wijzigingen na, /debug helpt bij het opsporen van een fout, en /verify bouwt en start je project om te controleren of een wijziging echt werkt in plaats van alleen dat de tests groen zijn.

Maak je zelf een skill met dezelfde naam als een ingebouwde, dan gaat jouw versie voor.

Als je skill niet afgaat

Het meest voorkomende probleem, en bijna altijd hetzelfde: de description sluit niet aan bij hoe jij je vragen formuleert.

Loop dan deze punten langs. Vraag eerst in een sessie welke skills beschikbaar zijn, zodat je zeker weet dat Claude hem ziet. Verschijnt hij niet in die lijst, dan staat het bestand op de verkeerde plek of heet het niet precies SKILL.md. Verschijnt hij wel, maar gaat hij niet af, dan zitten er te weinig herkenbare woorden in de description. Bekijk hoe je je vraag stelde en neem die woorden erin op.

Werkt het nog niet, roep de skill dan een keer direct aan met de schuine streep. Werkt hij dan wel, dan weet je dat de instructies goed zijn en dat alleen de trigger nog niet klopt.

Het omgekeerde probleem, een skill die te vaak afgaat, los je op door de description specifieker te maken of door automatische aanroep helemaal uit te zetten.

Waarom dit de moeite waard is

Skills voelen bij de eerste kennismaking als een extra laag om te leren. Dat klopt ook, en voor een losse vraag zijn ze overbodig.

Ze gaan renderen op het moment dat je hetzelfde werk vaker doet. Elke instructie die je in een skill vastlegt is een instructie die je nooit meer hoeft in te typen, en die bovendien hetzelfde blijft ook als jij hem zelf een keer half opschrijft. Dat is minder een technische winst dan een organisatorische.