Marktmannen wiki Coderen met AI

Skills Verbeteren — Vier Praktijken

Laatst bijgewerkt

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. Volgens de bron voorkomt het "context rot" (jargon van de bron, geen gedocumenteerde term).

Nuance — het listing-budget: in Claude Code krijgt de skill-lijst een budget van 1% van het contextvenster (instelbaar met skillListingBudgetFraction). Heb je veel skills, dan blijven alle namen staan maar vallen beschrijvingen weg, te beginnen bij de minst gebruikte skills — en daarmee de woorden waarop Claude matcht. Per skill worden description + when_to_use bovendien afgekapt op 1.536 tekens: zet de kern vooraan. /skill-doctor (v2.1.252+) laat zien wat elke skill aan context kost en hoe vaak hij gebruikt wordt.

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. De bron adviseert daarna een test met drie prompts (een praktijkadvies, geen gedocumenteerde methode): 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.

Wie mag de skill starten? Naast de description bepalen een paar frontmattervelden wanneer een skill laadt:

  • disable-model-invocation: true — Claude laadt de skill niet zelf; alleen jij start hem met /naam. Handig voor workflows die je bewust handmatig wilt triggeren.
  • user-invocable: false — alleen Claude roept de skill aan; hij verdwijnt uit het /-menu. Bedoeld voor achtergrondkennis.
  • paths: — glob-patronen; Claude laadt de skill automatisch alleen bij werk aan bestanden die daarop matchen.

Let ook op waar een skill staat: persoonlijke skills in ~/.claude/skills/ laden niet in Cowork of cloudsessies.

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:

Oorzaak Waar je het vastlegt
Het proces klopte niet Instructies in de SKILL.md
Stem, merk of voorbeelden ontbraken Een referentiebestand in de skill-map
Dezelfde fout blijft terugkomen Een expliciete regel die hem verbiedt
De code was onbetrouwbaar Een opgeslagen script (praktijk 1)

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 (de Agent Skills open standard, sinds 18-12-2025), 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. Technisch kan dat in Claude Code door een skill in een subagent te laten draaien (context: fork met agent:); dat persona-reviewers beter werk opleveren, is advies van de bron, niet gemeten.

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
  • Skills Bouwen — Zeven Bijgewerkte Regels — zeven structuurregels (contentlijst, degrees of freedom, per-model testen, referenties één niveau diep, checklists, self-correction, afhankelijkheden) als aanvulling naast deze vier praktijken

Bronnen

#skills #werkwijze #context

Backlinks