Skills Verbeteren — Vier Praktijken

Laatst bijgewerkt 16 september 2026

TL;DR: Stop met per klus een eigen agent bouwen; geef één generieke agent skills, en maak die skills beter langs vier lijnen — bewezen code opslaan, scherpe descriptions, correcties vastleggen, en verifiëren vóór oplevering.

De makers van agent skills bij Anthropic zijn volgens deze bron gestopt met het bouwen van een aparte agent per taak, omdat de onderliggende agent veel algemener bleek dan verwacht. Het alternatief is een gelaagd model: het model is de processor, de agent runtime het besturingssysteem, en skills zijn de apps. Claude Code kan al bestanden lezen, code schrijven en tools aanroepen — dat hoef je niet per use case opnieuw te bouwen. Je geeft dezelfde generieke agent een skill met het proces, de context, de scripts en de voorbeelden voor één specifieke klus.

De vier praktijken hieronder gaan niet over of je skills gebruikt, maar over waarom de meeste skills middelmatig blijven.

1. Sla bewezen code op — DRY voor agents

Het team zag Claude telkens vrijwel hetzelfde Python-script herschrijven om styling op een slide deck toe te passen. Dat kost tokens, en het resultaat verschilt per run omdat het elke keer opnieuw bedacht wordt.

De oplossing: laat Claude dat script opslaan binnen de skill — in hun eigen woorden een tool voor zijn toekomstige zelf. De volgende run draait de versie die al bewezen werkte. Het is het klassieke DRY-principe (don't repeat yourself) toegepast op een agent.

Werkwijze: 1. Zodra Claude een script produceert waarvan het resultaat klopt: laat het opslaan in de scripts/-map van de skill. 2. Werk de SKILL.md bij zodat toekomstige runs dat bestand uitvoeren in plaats van het te herschrijven. 3. Draai dezelfde taak twee keer en vergelijk de uitkomst — controleer dat de skill het opgeslagen bestand daadwerkelijk aanroept.

De omliggende AI-output varieert nog steeds een beetje; wat je hebt vervangen is één verse gok door een vast stuk code.

2. Scherpe descriptions — progressive disclosure werkt alleen met eenduidigheid

Claude leest bij het opstarten niet alle skills volledig. Het leest alleen de naam en de description uit de YAML-frontmatter, en pas als je prompt matcht wordt de volledige SKILL.md geladen; grotere referentiebestanden en scripts blijven in de map tot de taak ze nodig heeft. Anthropic noemt dit progressive disclosure — informatie laden alleen wanneer nodig. Het voorkomt context rot.

Maar dat mechanisme staat of valt met de description. Zegt de ene skill "help met content" en de andere "maak marketingassets", dan overlappen ze en gokt Claude. Een bruikbare description noemt zowel wat de skill doet als wanneer hij moet draaien, in de woorden die een echte gebruiker gebruikt:

Deze skill maakt LinkedIn-carousels op basis van een onderwerp, een transcript of een outline. Gebruik dit wanneer de gebruiker vraagt om een carousel, carouselslides of een LinkedIn-documentpost.

Regels: één specifieke klus per skill, echte gebruikerswoorden in de description, en geen twee skills die om dezelfde vraag concurreren.

Je kunt Claude dit zelf laten auditen: laat het per skill benoemen wat hij doet, wanneer hij zou moeten triggeren en waar hij overlapt met andere skills, en alleen de ambigue descriptions herschrijven. Test daarna met drie prompts: een voor de hand liggende aanvraag die moet triggeren, een anders geformuleerde die ook moet triggeren, en een niet-gerelateerde die niet mag triggeren.

Een skill die Claude niet kan vinden, is een skill die je niet hebt.

3. Correcties vastleggen in plaats van weggooien

Elke keer dat je Claude corrigeert en daarna de chat sluit, gooi je die les weg. Zeg je alleen "fix het", dan wordt de output gerepareerd maar blijft het proces stuk.

Skills bewaren geen conversatiegeschiedenis — ze bewaren procedurele kennis: hoe de klus hoort te gaan. De diagnose bepaalt waar de correctie landt:

Draai daarna dezelfde taak opnieuw en verifieer de fix. Het patroon is breder toepasbaar dan alleen skills: als een agent zegt een bestand niet te kunnen vinden, geef dan niet het pad — laat hem terugredeneren waar hij zocht en waarom hij het miste, en werk vervolgens de routing bij zodat de volgende run op de juiste plek begint. Dit is dezelfde lus als Compound Engineering, op skill-niveau.

Kanttekening bij "model-proof"

Geen enkele skill dwingt een zwakker model tot het niveau van een sterker model. Wat wél overdraagbaar is, is je proces: agent skills zijn een open formaat, dus dezelfde skills-map werkt in compatibele harnassen als Codex of Hermes Agent. Test een belangrijke skill in een tweede harnas; valt het resultaat uit elkaar, zoek dan naar verborgen aannames, ontbrekende voorbeelden of instructies die maar één model begrijpt.

4. Verifieer vóór oplevering — het 70%-probleem

Dit is volgens de bron het grootste gat in de meeste AI-workflows. De skill draait, maakt het bestand, meldt "klaar" — en dan blijkt de opmaak stuk, of dekken de bronnen de claims niet. De AI deed 70-80%, jij doet de laatste 20-30% handmatig.

Als je zelf weet hóe je dat werk controleert, bak die controle dan in de skill:

• Slide deck → render elke slide als afbeelding, inspecteer de screenshots, herstel wat afgesneden of onleesbaar is, render opnieuw.
• Onderzoeksrapport → open de primaire bronnen, koppel elke claim aan bewijs, schrap wat niet te verifiëren was.
• Script, advertentie of ander subjectief werk → laat een paar persona-subagents het beoordelen (een beginner zegt waar hij afhaakt, een sceptische koper wat hij niet gelooft). Neem niet elk stuk feedback over — pak wat meer dan één keer terugkomt.

Verificatie is niet Claude die zijn eigen werk leest en "ziet er goed uit" zegt. Het vraagt bewijs van buiten de eerste versie: een screenshot, een testresultaat, een bron, een referentievoorbeeld of het oordeel van een andere agent-rol. Nog beter is een objectieve succesmetriek waar de agent op door blijft werken.

Een instructie die je in vrijwel elke skill kunt zetten: definieer eerst de acceptatiecriteria, maak de eerste versie, inspecteer die met de passende verificatiemethode, herstel elk gevonden probleem, doe nog een ronde, en lever pas op als aan de criteria is voldaan — met een korte opsomming van wat er gecontroleerd is en wat níet verifieerbaar bleek.

De eerste output wordt daarmee een interne concepttekst. Jouw eerste blik hoort niet de eerste blik van de agent te zijn, maar zijn vierde of vijfde. Jij blijft de eindredacteur waar smaak, strategie en zakelijk oordeel spelen — het doel is alleen dat je geen tijd meer kwijt bent aan problemen die de AI zelf had kunnen vangen.

Open vragen

• De bron noemt twee Anthropic-engineers als afzender ("Barry Jien" en "Mahesh Marog" in het automatische transcript, vermoedelijk fonetisch verminkt). De originele uitspraak van Anthropic is niet in de clipping opgenomen — waar die precies staat (blogpost, podcast, conferentietalk) is niet geverifieerd.
• Hoe verhoudt "sla het script op in de skill" zich tot skills die je met anderen deelt? Een opgeslagen script maakt de skill minder portabel (afhankelijkheden, paden) terwijl praktijk 3 juist portabiliteit bepleit.
• Voor welke skills in mijn eigen OS is een objectieve succesmetriek te formuleren, en waar blijft verificatie noodgedwongen subjectief?

Verwante concepten

• Claude 5 Prompt- en Setup-Playbook — zelfde skillbouwregels (skill volgt op een bestaande taak, korte SKILL.md, voorbeelden boven regels), maar met een tegengesteld standpunt over praktijk 4: die bron stelt dat expliciete verificatie-instructies bij Claude 5-modellen juist geschrapt moeten worden
• Skills en Plugins — wat een skill is en welke kant-en-klare skills er zijn; dit artikel gaat over de kwaliteit van je eigen skills
• Skill Systems — meerdere skills koppelen; progressive disclosure is daar het argument tegen mega-skills, hier het argument vóór scherpe descriptions
• Compound Engineering — dezelfde lus (correctie → duurzame instructie), op projectniveau in plaats van skill-niveau
• Parallelle Bouwagents met Screenshot-Zelfkritiek (Fable 25) — praktijk 4 volledig uitgewerkt: render → pixelkritiek → herstel als verplichte passages
• Subagents — persona-reviewers uit praktijk 4, en hetzelfde description-mechanisme voor progressive disclosure
• Zelfverbeterende Kennisbank — hetzelfde principe (het systeem verbetert door gebruik) toegepast op kennis in plaats van procedures

Bronnen

• Anthropic Engineer Explains: What to Build Instead of AI Agents — Nate Herk, 13-09-2026