De skill crashte mijn hoofdsessie. Geen zachte fout — geen "hmm, dat zag er niet helemaal goed uit"-situatie. Ik heb het over een context window van 47.000 tokens dat in acht seconden werd opgeslokt, omdat een research-skill die ik had geschreven de volledige issue-geschiedenis van een GitHub-repository in het gesprek probeerde te trekken. Claude stopte midden in een zin met reageren. De sessie was verloren.
Dat was drie weken geleden. Ik probeerde een skill te bouwen die concurrentie-informatie zou verzamelen voordat ik een technisch artikel schreef. Simpel idee: GitHub bevragen, recente issues ophalen, trends samenvatten. De skill werkte — technisch gezien. Maar het werkte zoals een brandweerslang werkt wanneer je een koffiekopje probeert te vullen. Alle data kwam binnen, en het vernietigde alles eromheen.
Ik besteedde de week erna aan het herbouwen van die skill met drie functies die ik had genegeerd: context forking, dynamic context injection en background agents. Dezelfde skill draait nu in zijn eigen geïsoleerde sessie, verwerkt data via shell-scripts voordat Claude het ooit te zien krijgt, en werkt asynchroon terwijl ik verder codeer in mijn hoofdvenster. Tokenverbruik daalde van 47.000 naar ongeveer 3.200. Dezelfde outputkwaliteit. Een compleet ander universum van efficiëntie.
Die ervaring leerde me iets wat ik in geen enkele documentatie of tutorial had gelezen: de basale skill-architectuur — een map met een SKILL.md-bestand — is de startlijn, niet de finishlijn. De geavanceerde functies bovenop die basis zijn waar skills van "slim prompttrucje" naar "echte autonome workflow" gaan. En de meeste ontwikkelaars die nu skills bouwen, hebben ze nog niet aangeraakt.
Dit is alles wat ik heb geleerd over de geavanceerde kant van Claude Code skills — de onderdelen die me van speelgoed bouwen naar systemen bouwen brachten.
Waar Skills Nu Staan (En Waarom de Basis Niet Genoeg Is)
Als je mijn eerdere uitleg hebt gelezen over hoe agent skills op fundamenteel niveau werken, ken je het kernconcept: een skill is een map met een SKILL.md-bestand met YAML frontmatter en markdown-instructies. Claude laadt de metadata, ziet welke skills beschikbaar zijn, en haalt de volledige inhoud pas op wanneer een skill relevant is voor de huidige taak. Progressieve onthulling. Contextefficiëntie. Modulaire expertise.
Die architectuur is oprecht goed. Ik gebruik dagelijks nog steeds eenvoudige skills — mijn commit message formatter, mijn code review checklist, mijn deployment pre-flight script. Ze zijn simpel, ze werken, en ze besparen me 10-15 minuten per gebruik.
Maar ik bleef tegen muren aanlopen.
De research-skill-ramp was het dramatische voorbeeld, maar de stillere mislukkingen waren leerzamer. Een skill die de huidige projectstatus nodig had — welke bestanden zijn gewijzigd, op welke branch zit ik, welke dependencies zijn geïnstalleerd — maar alleen toegang had tot statische instructies die geschreven waren op het moment van skill-creatie. Een skill die een complexe meerstappenworkflow uitvoerde en mijn hoofdgesprek vervuilde met 30 berichten aan tussenresultaten waar ik niets aan had. Een skill die briljant werkte met Opus 4, maar stappen begon te hallucineren nadat ik overschakelde naar Sonnet 4.6.
Elk van deze mislukkingen wees naar dezelfde kloof: eenvoudige skills zijn statisch. Ze coderen kennis, maar ze kunnen zich niet aanpassen aan live context, hun werk niet isoleren, en niet bewijzen dat ze nog correct functioneren naarmate modellen evolueren.
Anthropic zag duidelijk dezelfde kloof. Het skill-systeem per maart 2026 bevat functies die elk van die problemen aanpakken. De uitdaging is dat deze functies over verschillende pagina's zijn gedocumenteerd, in verschillende contexten worden uitgelegd, en — eerlijk gezegd — niet altijd duidelijk zijn in hun kracht totdat je de specifieke muur hebt geraakt die ze oplossen.
Ik ga ze allemaal doorlopen in de volgorde waarin ik wou dat ik ze had geleerd.
Skill-typen: Kies de Juiste Architectuur Voordat Je Een Regel Schrijft
Voordat je een geavanceerde skill bouwt, moet je één vraag beantwoorden: welk soort probleem lost deze skill op? Anthropic categoriseert skills in twee typen, en de verkeerde keuze betekent dat je iets bouwt dat ofwel te ingewikkeld ofwel te beperkt is.
Capability Uplift Skills
Deze geven Claude mogelijkheden die het standaard niet heeft. Mijn Airtop browserautomatiseringsskill is een puur capability uplift — Claude kan van zichzelf geen cloudbrowser aansturen, maar met de skill geïnstalleerd kan het websites navigeren, formulieren invullen, data extraheren en geauthenticeerde sessies afhandelen. De Airtop-integratie compileert instructies in gewoon Engels naar deterministische code die draait op een echte Chromium-instantie in de cloud.
Andere capability uplift-voorbeelden die ik dagelijks gebruik: een skill die Lighthouse-audits uitvoert en de scores terugkoppelt naar het gesprek. Een skill die mijn Airtable-projectdatabase bevraagt. Een skill die Remotion-videocomposities genereert en rendert.
Het patroon is consistent — capability uplift skills bevatten uitvoerbare scripts (bash, Python, Node) die Claude als tools aanroept. De markdown-instructies vertellen Claude wanneer en hoe de tool te gebruiken. Het script doet het eigenlijke werk.
Encoded Preference Skills
Deze voegen geen nieuwe mogelijkheden toe. Ze coderen specifieke workflows, conventies en besluitvormingspatronen. Mijn code review skill geeft Claude geen nieuwe tools — Claude kan al code lezen en verbeteringen voorstellen. De skill codeert de reviewstandaarden van mijn team: controleer eerst op N+1 queries, verifieer dat alle publieke methoden docblocks hebben, markeer elke ruwe SQL die niet geparametriseerd is, zorg dat foutresponses ons API-contract volgen.
Het onderscheid is belangrijk omdat het de complexiteit bepaalt. Capability uplift skills hebben scripts nodig, tooldefinities, soms MCP-serverconfiguraties. Encoded preference skills zijn pure markdown — vaak slechts 50-200 regels aan precieze instructies. Als je een encoded preference skill bouwt en merkt dat je shell-scripts schrijft, heb je waarschijnlijk het type verkeerd geïdentificeerd.
Ik maakte deze fout twee keer voordat het bleef hangen. Ik bouwde een uitgebreide skill met een Python-script om de testpatronen van mijn codebase te "analyseren," terwijl alles wat ik eigenlijk nodig had een markdown-bestand was dat Claude vertelde "gebruik bij het schrijven van tests voor dit project Pest in plaats van PHPUnit, mock externe services met Http::fake(), en test altijd eerst het faalscenario." De markdown-only versie was sneller te bouwen, sneller te laden, en produceerde betere resultaten omdat Claude niet hoefde te wisselen tussen instructies opvolgen en tools aanroepen.
Dat gezegd hebbende — de krachtigste skills die ik heb gebouwd combineren beide typen. De research-skill die ik uiteindelijk heb gerepareerd? Capability uplift voor dataverzameling (shell-scripts die de GitHub API bevragen), encoded preferences voor analyse (hoe verschillende signalen te wegen, welk format de output moet hebben). Hybride skills zijn waar het interessant wordt, en waar de geavanceerde functies hun complexiteit beginnen te verdienen.
Context Forking: Geef Skills Hun Eigen Ruimte om Na te Denken
Dit is de functie die mijn research-skill redde. En het is degene waarvan ik denk dat de meeste ontwikkelaars hem als eerste moeten leren.
Dit is het probleem dat context forking oplost. Wanneer een skill in je hoofdsessie van Claude draait, leeft elke token die het genereert — elke tussenstap, elk stuk data dat het verwerkt, elke redenering die het volgt — in je hoofd-context window. Een skill die 15 stappen werk doet voordat het een eindantwoord produceert, heeft 15 stappen context gedumpt waar je niet om hebt gevraagd in je gesprek. Je volgende prompt moet nu concurreren met al die ruis om de aandacht van Claude.
Ik heb dit vorige maand gemeten op een echt project. Mijn hoofdsessie zat op ongeveer 12.000 tokens toen ik een skill activeerde die mijn package.json analyseerde, controleerde op verouderde dependencies, bekende kwetsbaarheden kruislings verifieerde, en een geprioritiseerd updateplan produceerde. Tegen de tijd dat de skill klaar was, bevatte mijn context window 38.000 tokens. De output van de skill — het deel dat ik eigenlijk wilde — was ongeveer 800 tokens. De andere 25.200 tokens waren werkgeheugen waar ik nooit meer naar zou kijken. En ze zouden daar zitten, capaciteit consumeren en de focus van Claude licht verslechteren, voor de rest van de sessie.
Context forking elimineert dit volledig. Je voegt één regel toe aan de YAML frontmatter van je skill:
---
name: dependency-audit
description: Analyzes project dependencies for security issues and updates
context: fork
---
Die context: fork-instructie vertelt Claude Code om een dedicated subagent te starten voor deze skill. De subagent krijgt zijn eigen context window, zijn eigen gespreksgeschiedenis, en de volledige skill-inhoud geïnjecteerd bij de start. Het doet al zijn werk in isolatie en stuurt alleen het eindresultaat terug naar je hoofdsessie.
Dezelfde dependency audit skill, hetzelfde project. Kosten hoofdsessie: ongeveer 1.200 tokens (het verzoek en de geretourneerde samenvatting). De subagent verbruikte zijn eigen 26.000 tokens in zijn eigen venster, dat werd opgeruimd nadat de skill was voltooid.
Het mentale model dat mij hielp: denk aan context forking alsof je een functie in een aparte thread draait in plaats van inline. De inline-versie werkt, maar blokkeert je hoofdthread en laat zijn stackframes rondslingeren. De geforkte versie draait onafhankelijk en retourneert een schoon resultaat.
Wanneer Forken (En Wanneer Niet)
Ik fork alles wat meer dan 3-4 stappen tussenverwerking omvat. Korte skills — een commit message formatteren, een migratiebestand genereren, een enkele configuratie controleren — draaien prima in de hoofdcontext. De overhead van het starten van een subagent is het niet waard voor een skill die 500 tokens aan werkgeheugen genereert.
Maar alles wat research, analyse, meervoudige bestandsverwerking of complexe redenering omvat? Fork het. De contextbesparing accumuleert over een werkdag. Ik moest vroeger elke 2-3 uur mijn Claude-sessies herstarten omdat de context te rommelig werd. Met geforkte skills die het zware werk doen, ga ik regelmatig volledige 8-urige sessies zonder verslechtering.
Iets wat de documentatie onvoldoende benadrukt: geforkte skills kunnen specificeren welk agentmodel er wordt gebruikt. Ik draai mijn hoofdsessie op Opus 4.6 voor zijn diepe redenering, maar mijn eenvoudigere geforkte skills — dataverzameling, formatting, bestandsorganisatie — draaien op Sonnet 4.6 voor een fractie van de kosten. Dit stel je in via de frontmatter:
---
name: format-changelog
description: Generates a formatted changelog from git history
context: fork
model: sonnet
---
Een enkele research-skill die me vroeger $0,40 per run kostte op Opus kost nu $0,06 omdat de dataverzamelingsfork op Sonnet draait en alleen de uiteindelijke analysestap Opus gebruikt in mijn hoofdsessie. Over een maand dagelijks gebruik is dat echt geld.
Dynamic Context Injection: Skills Die Weten Wat Er Nu Gebeurt
Statische instructies falen op het moment dat je projectstatus ertoe doet. Dit leerde ik bij het bouwen van een deployment-skill die de huidige git-branch moest weten, de laatste commit-hash, welke omgevingsvariabelen waren ingesteld, en of er migraties in behandeling waren. Ik kon instructies hardcoden over hoe deze dingen te controleren, maar de skill zou tokens besteden aan Claude die commando's uitvoert en output verwerkt die ik van tevoren had kunnen verzamelen.
Dynamic context injection draait het model om. In plaats van dat Claude de projectstatus ontdekt tijdens runtime, verzamelt een preprocessing-script de data voordat de skill laadt, en injecteert het direct in de inhoud van de skill. Claude ontvangt de skill met live data al ingebed. Geen ontdekkingsstap. Geen verspilde tokens.
De syntax gebruikt !command-placeholders in je SKILL.md:
---
name: deploy-preflight
description: Runs deployment readiness checks for current branch
context: fork
---
## Current Project State
- **Branch:** !git rev-parse --abbrev-ref HEAD
- **Last commit:** !git log -1 --oneline
- **Uncommitted changes:** !git status --porcelain | wc -l
- **Pending migrations:** !php artisan migrate:status --pending 2>/dev/null || echo "N/A"
- **Node version:** !node --version
- **Environment:** !echo $APP_ENV
## Deployment Checklist
Based on the current state above, verify the following...
Wanneer deze skill geactiveerd wordt, voert Claude Code elk !command-shellcommando uit, vangt de output op en vervangt de placeholder door het daadwerkelijke resultaat. Claude ziet:
- **Branch:** feature/payment-gateway
- **Last commit:** a3f2c91 Add Stripe webhook handler
- **Uncommitted changes:** 3
- **Pending migrations:** 2 pending
Niet de commando's. De resultaten. Claude begint te redeneren over deployment-gereedheid vanuit de daadwerkelijke projectstatus in plaats van tokens te besteden aan het ontdekken ervan.
De tokenbesparing is aanzienlijk — mijn deploy-preflight skill daalde van ongeveer 4.800 tokens (met Claude die ontdekkingscommando's uitvoert) naar 1.900 tokens (met vooraf geïnjecteerde status). Maar de grotere winst is nauwkeurigheid. Wanneer Claude zelf de status ontdekt, parseert het soms commandouitvoer verkeerd, slaat het een controle over als het "zeker genoeg" is, of raakt het afgeleid door een onverwacht antwoord. Met vooraf geïnjecteerde data is elk stuk status gegarandeerd aanwezig en correct geformatteerd.
Injection Combineren met Forking
De echte krachtmove is beide samen gebruiken. Mijn competitive research skill — degene waarmee dit hele verhaal begon — ziet er nu zo uit:
---
name: competitive-research
description: Analyzes GitHub activity and trends for a given technology
context: fork
model: sonnet
---
## Research Context
Target technology: {{topic}}
Date range: !date -v-30d +%Y-%m-%d to !date +%Y-%m-%d
## Recent Activity
!gh api search/repositories --jq '.[0:5] | .[] | "\(.full_name) - \(.stargazers_count) stars - \(.description)"' -q "{{topic}} pushed:>$(date -v-30d +%Y-%m-%d)"
## Trending Issues
!gh api search/issues --jq '.[0:10] | .[] | "[\(.repository_url | split("/") | last)] \(.title)"' -q "{{topic}} is:issue created:>$(date -v-7d +%Y-%m-%d)"
De shell-commando's verwerken de GitHub API-queries vooraf. De context: fork draait alles in een geïsoleerde subagent op Sonnet. Mijn hoofd-Opus-sessie ontvangt een schone samenvatting. Totale tokenkosten hoofdsessie: ongeveer 900 tokens. Totaal daadwerkelijk uitgevoerd werk: equivalent aan wat vroeger mijn 47.000-token context window opblies.
Dat is geen incrementele verbetering. Dat is een fundamenteel andere mogelijkheid.
Background Agents: Skills Die Werken Terwijl Jij Werkt
Sommige skills kosten tijd. Een uitgebreide beveiligingsaudit van een codebase. Een volledige testsuiteuitvoering met analyse. Het scrapen en samenvatten van 20 pagina's documentatie. Deze workflows kunnen 3-5 minuten duren — een eeuwigheid wanneer je zit te wachten tot je terminal weer bruikbaar wordt.
Background agents lossen dit op door skills asynchroon te laten draaien. Je activeert de skill, het start een background agent, en je hoofdsessie blijft responsief. Wanneer de background agent klaar is, presenteert het de resultaten.
Ik gebruik dit dagelijks voor mijn testanalyse-skill. Na het pushen van een feature-branch activeer ik de skill:
/skill test-analysis
De skill forkt naar een background agent, draait de volledige testsuite, vangt eventuele fouten op, analyseert dekkingsrapporten en stelt een samenvatting op. Ondertussen werk ik al aan de volgende feature in mijn hoofdsessie. Drie minuten later komt de background agent terug met:
Test Analysis Complete:
- 247 tests passed, 2 failed
- Failed: OrderCalculation::test_discount_stacking (assertion mismatch on line 89)
- Failed: PaymentGateway::test_timeout_retry (mock not returning expected response)
- Coverage: 78.3% (down 0.4% from main branch)
- Suggestion: The discount stacking failure looks like a rounding issue...
De workflow is vergelijkbaar met hoe je Ctrl+B zou gebruiken om een draaiende subagent naar de achtergrond te verplaatsen — de agent blijft onafhankelijk doorwerken, zelfs nadat je hoofdtaak verdergaat. Het /tasks-commando geeft je een dashboard van alles dat op de achtergrond draait, met ID's die je kunt gebruiken om de status te controleren, details te bekijken of te annuleren.
Wat niemand je vertelt over background agents: ze zijn het meest waardevol niet vanwege de tijdsbesparing, maar vanwege de contextisolatie. Voordat ik background agents gebruikte, draaide ik mijn testsuite in Claude's hoofdsessie en kreeg ik 200+ regels testoutput terug die ik mentaal moest filteren. De background agent verwerkt al die ruis in zijn eigen context en geeft me alleen het signaal terug.
Als je liever iemand hebt die dit soort multi-agent skill-systemen vanaf nul bouwt, neem ik Claude Code-automatiseringsprojecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.
Skills Installeren: Het Ecosysteem Is Groter Dan Je Denkt
Ik moet even teruggaan en praten over het installeren van skills in je systeem, want het installatieverhaal heeft zich snel ontwikkeld.
Het Plugin-commando
De primaire methode is het ingebouwde plugin-systeem van Claude Code:
/plugin install <skill-name>@<marketplace>
Voor de officiële skills-repository van Anthropic:
/plugin install document-skills@anthropic-agent-skills
Je kunt ook externe marktplaatsen registreren:
/plugin marketplace add alirezarezvani/claude-skills
Na het toevoegen van een marktplaats wordt elke skill in die repository installeerbaar met één commando.
Het skills.sh-ecosysteem
Het skills.sh-ecosysteem is geëxplodeerd sinds ik er voor het eerst over schreef. Per maart 2026 zijn er meer dan 7.000 geëvalueerde skills over meerdere marktplaatsen, compatibel met niet alleen Claude Code maar ook met Codex CLI, Gemini CLI, Cursor en Antigravity IDE. Het universele SKILL.md-format betekent dat een skill die je bouwt voor Claude werkt in al deze tools.
De beste ontdekkingsmethode die ik heb gevonden: blader door SkillHub of de VoltAgent awesome-agent-skills-repository, die skills cureert van officiële ontwikkelteams en de community. Filter op categorie, bekijk beoordelingen en installeer met één commando.
Handmatige Installatie
Voor skills die je zelf bouwt — en daar zit de echte kracht — heb je twee opties:
Projectgebonden: Zet de skill-map in .claude/skills/ in je repository. Elk teamlid dat de repo kloont krijgt de skill automatisch. Versiebeheerd, gedeeld, consistent.
Persoonlijk: Zet het in ~/.claude/skills/ voor skills die je beschikbaar wilt hebben in alle projecten. Mijn formatteringsskills, mijn algemene code review-standaarden, mijn schrijfstijlgids — deze staan in mijn persoonlijke map omdat ze niet projectspecifiek zijn.
De mapstructuur is eenvoudig:
.claude/skills/
deploy-preflight/
SKILL.md # Frontmatter + instructions
scripts/
check-deps.sh # Optional executable scripts
templates/
deploy-log.md # Optional reference files
Claude ziet de skillnaam en beschrijving uit de frontmatter. De volledige inhoud wordt pas geladen wanneer de skill wordt geactiveerd. Scripts in de map worden tools die de skill kan aanroepen.
Skills Handmatig Bouwen: De Patronen Die Echt Werken
Ik heb ongeveer 40 skills gebouwd in de afgelopen vier maanden. De meeste vroege exemplaren waren middelmatig. Degene die ik nu bouw zijn drastisch beter, en het verschil komt neer op drie patronen die ik door falen moest leren.
Patroon 1: Specificiteit van Instructies Boven Volume van Instructies
Mijn eerste skills waren 500+ regels aan gedetailleerde instructies. "Als de gebruiker vraagt over X, doe Y. Als ze Z noemen, controleer dan eerst W. In gevallen waarin..." Uitputtend. En verschrikkelijk.
Het probleem: lange skills verbranden contexttokens zelfs na forking, en Claude wordt slechter in het opvolgen van instructies naarmate de instructieset groeit. Er is een sweet spot — en in mijn testen ligt die tussen de 80 en 200 regels markdown voor het instructiegedeelte.
De oplossing was instructies schrijven zoals ik een senior engineer zou briefen, niet een junior. In plaats van elke stap uit te spellen, beschrijf ik het doel, de beperkingen en de kwaliteitslat. Claude's redenering vult de gaten.
Slecht:
1. First, open the file
2. Then find all functions
3. For each function, check if it has a docblock
4. If it doesn't have a docblock, generate one
5. The docblock should include @param tags
6. The @param tags should list the type first, then the name
7. After the @param tags, add a @return tag
...
Goed:
## Task
Add PHPDoc blocks to all public methods missing them.
## Standards
- Follow PSR-5 PHPDoc format
- Infer parameter types from type hints; fall back to mixed
- Include @throws if the method contains throw statements
- Keep descriptions to one sentence — if you need two, the method needs refactoring
De goede versie is 6 regels in plaats van 30+. Het produceert betere output omdat het Claude ruimte geeft om over elk specifiek geval te redeneren in plaats van mechanisch een checklist af te werken.
Patroon 2: Exitcondities, Niet Alleen Entrycondities
De frontmatter van elke skill heeft een beschrijving die Claude vertelt wanneer te activeren. De meeste skill-bouwers stoppen daar. Maar Claude vertellen wanneer de skill klaar is, is even belangrijk.
Zonder expliciete exitcondities hebben skills de neiging om te veel te leveren. Mijn SEO-auditskill bleef maar "nog één ding om te controleren" vinden totdat het 15.000 tokens aan analyse had verbruikt voor een enkele pagina. Het toevoegen van exitcondities loste dit op:
## Completion Criteria
- All five audit categories scored (Performance, Accessibility, SEO, Best Practices, Content)
- Critical issues listed (severity: high only)
- Three specific, actionable recommendations provided
- Total output: under 500 words
Stop when these criteria are met. Do not continue analyzing.
Patroon 3: Foutherstel-instructies
Skills die externe tools aanroepen — API's, shell-commando's, databasequeries — zullen te maken krijgen met fouten. Als je Claude niet vertelt hoe het met fouten moet omgaan, stopt het ofwel onhandig of begint het te improviseren, wat vaak erger is.
Elke capability uplift skill die ik nu bouw bevat een foutsectie:
## When Things Go Wrong
**API returns 401:** The token has expired. Tell the user to run `gh auth refresh` and retry.
**API returns 404:** The repository doesn't exist or is private. Ask the user to verify the repo name.
**Command timeout (>30s):** The network request is hanging. Suggest checking VPN status or retrying with `--timeout 60`.
**Empty results:** This is valid — not every query has results. Report "no data found" rather than guessing.
Never fabricate data if a command fails. Report the failure and suggest a fix.
Dit enkele patroon elimineerde ongeveer 80% van het onvoorspelbare gedrag dat ik in mijn skills zag.
Skill-testen en -evaluatie: Het Deel Dat Iedereen Overslaat
Ik ga hier direct over zijn: als je skills bouwt zonder ze te testen, bouw je skills die zonder waarschuwing zullen falen.
Ik sloeg het testen over voor mijn eerste 20 skills. Toen kreeg Claude een modelupdate, en 6 ervan begonnen slechtere output te produceren. Niet kapot — slechter. Subtiele verslechtering. Mijn code review skill stopte met het detecteren van N+1 queries. Mijn deployment-skill begon de migratiecontrole over te slaan. Ik merkte het een week lang niet omdat de skills nog steeds draaiden — ze draaiden gewoon matig.
Dit is waarom Anthropic de Skill Creator heeft gebouwd.
De Skill Creator: Een Skill Die Andere Skills Bouwt en Test
De Skill Creator is een meta-skill — een skill die de ontwikkeling, het testen en de evaluatie van andere skills automatiseert. Installeer het als een plugin, en je krijgt toegang tot twee kernworkflows:
Eval mode: Definieer testprompts, beschrijf verwachte outputs, en de Skill Creator draait je skill tegen elke prompt en beoordeelt de resultaten. Het evalueert op vijf dimensies: volledigheid van frontmatter, kwaliteit van beschrijving, helderheid van instructies, diepte van uitleg, en slagingspercentage van evals.
eval: Execute skill on test prompts → Grade outputs → Report scores
Improve mode: Alles in eval mode, plus blinde A/B-vergelijkingen, geautomatiseerde analyse en iteratieve verfijning. De Skill Creator draait twee Claude-instanties — één met je skill, één zonder — geeft ze dezelfde prompt en vergelijkt de outputs. Als de skill-versie niet significant beter presteert dan de gewone versie, weet je dat de skill geen waarde toevoegt.
improve: Execute → Grade → Blind A/B compare → Analyze → Iterate
Hoe Ik Mijn Skills Nu Test
Elke skill die ik bouw doorloopt deze pipeline voordat ik hem als klaar beschouw:
Stap 1: Definieer 3-5 testprompts. Deze moeten het happy path van de skill dekken, een randgeval, en minstens één adversarial case (een prompt die dicht bij het domein van de skill ligt maar hem niet zou moeten activeren).
Stap 2: Draai eval mode. Controleer dat alle testprompts de verwachte outputs produceren. Als er eentje faalt, herzie de skill-instructies.
Stap 3: Draai de A/B-test. Dit is de stap die mijn perspectief op skill-bouwen veranderde. Ik had een skill waarvan ik dacht dat hij briljant was — een code review skill met gedetailleerde standaarden. De A/B-test toonde aan dat gewoon Claude (zonder skill) even goede reviews produceerde voor 3 van de 5 testcases. Mijn "briljante" skill voegde alleen waarde toe voor randgevallen met databasequeries en API-foutafhandeling. Ik herschreef hem om uitsluitend op die gebieden te focussen, verkleinde de instructielengte met 60%, en de A/B-scores sloegen om naar 5 van de 5.
Stap 4: Hertest na modelupdates. Ik bewaar mijn testprompts in een tests/-submap binnen elke skill-directory. Na elke Claude-modelupdate draai ik de evals opnieuw. Dit kost ongeveer 10 minuten voor mijn volledige skill-bibliotheek en heeft in de afgelopen twee maanden drie keer verslechtering gedetecteerd.
Het evaluatiesysteem draait elke test parallel, in geïsoleerde contexten, zodat skills elkaar niet kunnen beïnvloeden tijdens het testen. Die isolatie is belangrijk — ik had ooit een skill-test die slaagde wanneer individueel gedraaid maar faalde wanneer naast andere skills gedraaid, vanwege een naamgevingsconflict in de frontmatter.
Deze testdiscipline voelt als overhead totdat het je de eerste keer redt. Daarna voelt het als de enige verantwoorde manier om skills te bouwen.
Echte Integratie: Airtop Cloud Browser-automatisering
Theorie is nuttig. Laat me je zien hoe een volledig geavanceerde skill eruitziet in productie.
De skill waar ik op dit moment het meest trots op ben is mijn Airtop browserautomatiseringsskill. Airtop biedt een echte cloudbrowser — geen headless scraper, geen gesimuleerd DOM, een daadwerkelijke Chromium-instantie die in de cloud draait en JavaScript-zware sites, geauthenticeerde sessies en dynamische content aankan.
Waarom dit belangrijk is: de helft van de automatiseringen die ik Claude wil laten uitvoeren betreft websites die geen API's hebben. Concurrentieprijspagina's. Leveranciersportalen. Overheidscompliance-databases. Vacaturesites. CRM's. Er is geen API om te bevragen — de enige interface is een browser.
De Airtop-skill lost dit op door alle geavanceerde functies te combineren:
---
name: airtop-research
description: Automates web research using a real cloud browser via Airtop
context: fork
model: sonnet
---
Het forkt naar zijn eigen context (omdat browserautomatisering uitgebreide tussenresultaten genereert). Het gebruikt dynamic injection om mijn Airtop API-credentials en de doel-URL's te laden. Het draait Sonnet voor de browserinteractiestappen (kostenefficiënt voor mechanische navigatie) en retourneert gestructureerde resultaten naar mijn Opus-hoofdsessie voor analyse.
Een workflow die ik gisteren draaide: het monitoren van concurrentieprijzen over vijf SaaS-tools. Ik beschreef wat ik nodig had in gewoon Nederlands, de skill compileerde het naar deterministische automatiseringscode, lanceerde cloudbrowsersessies tegen elke site, extraheerde prijstabellen en retourneerde een gestructureerde vergelijking. Totale tijd: ongeveer 90 seconden. Handmatig equivalent: 20-30 minuten tabwisselen en kopiëren-plakken.
De gecompileerde automatisering is het onderdeel dat me het meest verraste. Airtop speelt mijn instructies niet simpelweg af — het genereert daadwerkelijke code ervan, die deterministisch draait bij volgende uitvoeringen. De eerste run is agent-gestuurd en verkennend. Elke run daarna is snel en betrouwbaar. Het is een patroon dat ik niet heb gezien in andere browserautomatiseringstools, en het maakt het verschil tussen "gave demo" en "productie-workflow."
De Samensmelting van Skills en Custom Commands
Een architecturale verschuiving die het vermelden waard is: skills en custom slash commands in Claude Code convergeren. Eerdere versies behandelden ze als aparte systemen — commands waren snelle snelkoppelingen, skills waren diepere kennismodules. Vanaf Claude Code 2.1 is de grens vervaagd.
Een skill kan zichzelf nu registreren als slash command via de frontmatter:
---
name: security-audit
description: Full OWASP-aligned security review of the current project
command: /audit
context: fork
---
Het typen van /audit in Claude Code activeert de volledige skill met al zijn geavanceerde functies — forking, dynamic injection, achtergronduitvoering. Geen noodzaak om aparte commandoconfiguraties te onderhouden.
Deze convergentie is belangrijk omdat het de cognitieve belasting vermindert van het beheren van je toolkit. Ik onderhield vroeger een mentale kaart van "welke dingen zijn skills en welke dingen zijn commands." Nu is alles een skill, waarvan sommige commandosnelkoppelingen hebben. Eén systeem. Eén locatie. Eén testframework.
De claude-skills-guide-decoded-post die ik eerder schreef behandelt het fundamentele SKILL.md-format in detail. Wat er sindsdien is veranderd, is dat het format nu aanzienlijk meer frontmatter-opties ondersteunt — context, model, command, toolbeperkingen en lifecycle hooks — waardoor een eenvoudig markdown-bestand een volledige agentconfiguratie wordt.
Wat Ik Fout Had (En Wat Ik Anders Zou Doen)
Ik wil afsluiten met de fouten, want die zijn nuttiger dan de successen.
Fout 1: Te veel forken. Na het ontdekken van context forking paste ik het op alles toe. Een 3-regelige formatteringsskill die 200 tokens output genereerde? Geforkt. De overhead van het starten van een subagent overtrof de contextkosten van het gewoon inline draaien. Fork skills die 2.000+ tokens aan werkgeheugen genereren. Laat eenvoudige skills in je hoofdsessie draaien.
Fout 2: Dynamic injection zonder caching. Sommige van mijn !command-aanroepen raakten API's bij elke skillactivering. Als je een skill 10 keer per uur activeert, zijn dat 10 identieke API-aanroepen. Ik gebruik nu shell-commando's die eerst controleren op een gecachet resultaat en alleen live bevragen als de cache verouderd is. Simpel patroon, achteraf voor de hand liggend, maar ik had mijn API rate limits al bereikt voordat ik erachter kwam.
Fout 3: Skills bouwen voor dingen die Claude al goed doet. Het A/B testing-framework leerde me dit: als gewoon Claude de taak op 80%+ kwaliteit afhandelt zonder skill, is de skill het onderhoud niet waard. Skills moeten de gaten aanpakken — de projectspecifieke conventies, de externe tool-integraties, de domeinkennis die Claude niet heeft. Een skill bouwen voor "schrijf goede Python-code" is verspilde moeite. Een skill bouwen voor "schrijf Python-code die het decoratorpatroon van ons team volgt voor FastAPI-endpoints met gestructureerde logging" is een echte verbetering.
Fout 4: Het testverhaal negeren tot het te laat was. Zes kapotte skills na een modelupdate. Dat was wat nodig was. Bouw de eval-suite naast de skill, niet erna.
De eerlijke beoordeling van waar skills nu staan: het systeem werkt. De geavanceerde functies — forking, injection, background agents, geautomatiseerde evals — transformeren skills van "slimme prompttemplates" naar echte workflowautomatisering. De tooling is nog vroeg genoeg dat je ruwe randjes zult tegenkomen (foutmeldingen van geforkte skills zouden veel beschrijvender kunnen zijn, en de A/B-testopstelling vereist meer handmatige configuratie dan nodig zou moeten zijn). Maar de architectuur is solide, en het ecosysteem beweegt in een tempo dat ik niet heb gezien sinds de vroege npm-dagen.
Zevenduizend skills op SkillsMP alleen al, en het format werkt in Claude Code, Codex CLI, Gemini CLI en Cursor. Dit is geen Claude-specifieke functie meer. Het is een industriestandaard die zich in realtime vormt.
De vraag is niet of je moet investeren in het leren van de geavanceerde skill-functies. De vraag is of je het je kunt veroorloven om agents te blijven bouwen zonder ze.
Veelgestelde Vragen
Wat is context forking in Claude Code skills?
Context forking start een dedicated subagent met zijn eigen context window om een skill in isolatie uit te voeren. Voeg context: fork toe aan je SKILL.md frontmatter om te voorkomen dat zware skills je hoofdgesprek vervuilen. Zie de sectie over Context Forking hierboven voor de volledige uitleg.
Hoe installeer ik Claude Code skills vanuit de marktplaats?
Voer /plugin install <skill-name>@<marketplace> uit in Claude Code, of voeg een externe marktplaats toe met /plugin marketplace add <repo>. Skills worden geïnstalleerd in .claude/skills/ voor projectgebonden gebruik of ~/.claude/skills/ voor persoonlijk gebruik.
Wat is dynamic context injection in Claude Code?
Dynamic context injection gebruikt !command-syntax in SKILL.md om shell-commando's uit te voeren voordat de skill laadt. De commandouitvoer vervangt de placeholder, zodat Claude live projectdata ontvangt — git branch, omgevingsvariabelen, API-responses — zonder tokens te besteden aan ontdekking.
Hoe test ik Claude Code skills met de Skill Creator?
Installeer de Skill Creator plugin, definieer testprompts met verwachte outputs en draai eval mode. Voor diepere validatie gebruik je improve mode, dat blinde A/B-tests uitvoert die Claude's output vergelijkt met en zonder de skill actief. Zie de sectie Testen en Evaluatie hierboven.
Kunnen Claude Code skills op de achtergrond draaien?
Ja. Skills met context: fork kunnen background agents starten die asynchroon werken terwijl je hoofdsessie responsief blijft. Gebruik /tasks om draaiende achtergrondskills te monitoren, hun status te controleren of ze te annuleren.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
