Wat het bouwen van 30+ Claude Code Skills mij heeft geleerd

Wat het bouwen van 30+ Claude Code Skills mij heeft geleerd

Drie maanden geleden heb ik veertien skills uit mijn Claude Code-setup massaal verwijderd. Niet gearchiveerd. Verwijderd. Dit waren skills waar ik echt tijd in had gestoken — bouwen, testen en itereren. Skills waar ik trots op was.

Ze maakten mijn werk slechter.

Niet dramatisch slechter — dat zou makkelijk te ontdekken zijn geweest. Subtiel slechter. Een contentgeneratie-skill die Claude's verbeterde native schrijfvaardigheid overschreef. Een commit message-skill die stijve, formulematige output produceerde terwijl het model had geleerd om zelf betere te schrijven. Een code review-skill zo voorschrijvend dat Claude vakjes afvinkte in plaats van echt na te denken over codekwaliteit.

De massale verwijdering leerde me iets dat ik in geen enkele documentatie had gelezen: skills bouwen is het makkelijke deel. Skills bouwen die nuttig blijven, die goed samenwerken met elkaar, die je workflow zes maanden later daadwerkelijk verbeteren — dat is een totaal andere discipline. En het is een discipline die ik op de harde manier moest leren.

Ik heb inmiddels meer dan dertig actieve skills gebouwd en onderhouden voor vier verschillende merkwebsites, een contentcreatie-pipeline, een security audit-workflow en mijn dagelijkse ontwikkelomgeving. Sommige van die skills draaien al bijna een jaar. Andere hielden het een week vol voordat ik besefte dat ze het verkeerde probleem oplosten.

Wat volgt is geen tutorial over hoe je je eerste skill maakt. Als je dat nodig hebt, helpen Anthropic's officiële documentatie en hun Skilljar-cursus over Agent Skills je op weg. Dit gaat over wat er gebeurt na je eerste tien skills — de patronen die zich aftekenen, de fouten die zich herhalen, en de architectuurbeslissingen die skills die je jarenlang gebruikt scheiden van skills die je binnen een maand verwijdert.

Dit is de vraag die alles voor mij veranderde: wat voor type skill bouw ik eigenlijk?

Waarom de meeste skills jong sterven — en één mentale verschuiving die het oplost

Ik dacht altijd dat een skill gewoon een skill was. Je schrijft wat markdown-instructies, voegt misschien een script of twee toe, dropt het in .claude/skills/, en gaat verder. Die aanpak werkte prima toen ik drie skills had. Tegen de tijd dat ik er vijftien had, was mijn setup een puinhoop.

Skills conflicteerden met elkaar. Sommige laadden context die 90% van de tijd irrelevant was. Andere waren zo generiek dat ze Claude's output nauwelijks verbeterden. Eén skill — mijn oorspronkelijke "code quality"-skill — was daadwerkelijk in tegenspraak met mijn "testing practices"-skill op manieren die ik wekenlang niet opmerkte.

Het keerpunt kwam toen ik mijn skills begon te categoriseren op basis van wat ze daadwerkelijk doen, niet waar ze over gaan. Na alles in mijn setup te catalogiseren plus te bestuderen hoe Anthropic's interne teams hun eigen skills organiseren (ze hebben hierover publiekelijk gedeeld), merkte ik op dat elke nuttige skill netjes in één van ongeveer negen categorieën past. De verwarrende, moeilijk te onderhouden skills? Die probeerden altijd meerdere categorieën tegelijk te bestrijken.

Dit is de taxonomie die ik nu gebruik voordat ik iets nieuws bouw.

Library- en API Reference-skills leggen uit hoe je een specifiek tool, SDK of interne library correct gebruikt. Mijn Aria-skill valt hier precies in — het codeert merkrichtlijnen, stemregels, SEO-vereisten en contentarchitectuurpatronen voor vier verschillende websites. Zonder deze skill schrijft Claude competente posts die totaal niet klinken als mijn merk.

Product Verification-skills beschrijven hoe je kunt testen of verifiëren dat output daadwerkelijk correct is. Gecombineerd met Playwright, tmux of aangepaste scripts. Hier heb ik maandenlang te weinig in geïnvesteerd. Daar kom ik later op terug.

Data Fetching en Analysis-skills verbinden met je data- en monitoringstacks — Grafana datasource UIDs, dashboard IDs, veelgebruikte querypatronen. Claude stopt met gokken naar kolomnamen en begint queries te schrijven die daadwerkelijk werken.

Business Process en Team Automation-skills automatiseren repetitieve workflows. Mijn standup-post-skill aggregeert GitHub-activiteit, ticket-updates en Slack-berichten in een geformateerde dagelijkse update. Eenvoudige instructies, groeiende waarde.

Code Scaffolding en Template-skills genereren boilerplate voor specifieke patronen in je codebase. Een Laravel "nieuwe migratie"-skill met de conventies en valkuilen van je team bespaart elke keer dertig minuten.

Code Quality en Review-skills handhaven standaarden. Mijn adversarial-review-setup start een sub-agent om code te bekritiseren, implementeert fixes, en itereert totdat bevindingen degraderen tot muggenzifterij.

CI/CD en Deployment-skills helpen bij fetchen, pushen en deployen. Mijn babysit-pr-skill monitort PR's, probeert flaky CI opnieuw, lost merge-conflicten op en schakelt auto-merge in.

Runbook-skills nemen een symptoom en doorlopen een multi-tool onderzoek om een gestructureerd rapport te produceren. Goudmijnen voor on-call rotaties.

Infrastructure Operations-skills behandelen routinematig onderhoud met vangrails — dependency-workflows, kostenonderzoek, opruiming van verweesd resources met verplichte bevestiging voor destructieve acties.

Het moment dat ik begon te vragen "in welke categorie hoort dit?" voordat ik één regel markdown schreef, werden mijn skills scherper. Als een skill probeert zowel een codekwaliteitscontroleur ALS een scaffolding-template te zijn, splits ik het in tweeën. Als het in geen enkele categorie netjes past, vraag ik me af of het überhaupt zou moeten bestaan.

Maar het categoriseren van skills is slechts het startpunt. Het echte vakmanschap zit in hoe je ze schrijft.

De gotchas-sectie is meer waard dan de rest van de skill bij elkaar

Ik ga een bewering doen die misschien extreem klinkt: het meest waardevolle deel van elke skill is de gotchas-sectie. Niet de instructies. Niet de voorbeelden. Niet de configuratie. De gotchas.

Dit is waarom. Claude weet al veel. Het weet hoe het Python moet schrijven, hoe het een React-component moet structureren, hoe het een REST API moet bouwen. Wanneer je een skill schrijft die het basisgebruik uitlegt van iets dat Claude al begrijpt, verspil je tokens en beperk je de flexibiliteit van het model. Maar wanneer je de specifieke faalwijzen documenteert — de randgevallen waar Claude herhaaldelijk tegenaan loopt, de aannames die het maakt die verkeerd zijn in jouw specifieke context, de subtiele bugs die alleen in productie verschijnen — dát is waar skills hun waarde bewijzen.

Mijn Aria content-skill heeft een "Verboden Zinnen"-sectie die meer dan vijftig items lang is. Dingen als "In today's fast-paced world" en "Let's dive in" en "Furthermore" — zinnen die onmiddellijk AI-gegenereerde content signaleren. Ik heb die lijst niet in één keer geschreven. Ik heb het opgebouwd over drie maanden door Claude te betrappen op terugvallen in AI-taal, elke overtreder aan de gotchas-lijst toe te voegen, en de outputkwaliteit te zien verbeteren bij elke toevoeging.

Hetzelfde patroon bij mijn Laravel migratie-skill. De daadwerkelijke migratiesyntax? Dat kent Claude uit het hoofd. Maar de gotchas — "gebruik nooit ->change() op een kolom die een index heeft in MySQL 5.7," "voeg altijd ->after('column_name') toe om kolomvolgorde te behouden," "onze staging-database gebruikt een andere collation dan productie" — die vermeldingen voorkomen bugs die anders uren zouden kosten om te debuggen.

De praktische les: begin elke nieuwe skill met een minimale instructieset en een lege gotchas-sectie. Gebruik de skill een week. Elke keer dat Claude iets fout of onverwachts doet, voeg het toe aan gotchas. Na een maand zal je gotchas-sectie het meest verfijnde, beproefde deel van de skill zijn. Het zal ook het deel zijn dat je de meeste tijd bespaart.

Ik review mijn gotchas-secties nu maandelijks. Sommige vermeldingen worden gepromoveerd naar de hoofdinstructies omdat ze zo fundamenteel zijn. Andere worden verwijderd omdat Claude is verbeterd en die fout niet meer native maakt. Deze onderhoudscyclus is saai, maar het is het verschil tussen een skill die scherp blijft en een die langzaam wegrot.

Die maandelijkse review-gewoonte leidt direct naar een andere les die ik gênant lang nodig had om te leren.

Skills zijn mappen, geen bestanden — en dat verandert alles

Een veelvoorkomende misvatting die ik veel te lang had: een skill is "gewoon een markdown-bestand." Technisch gezien is een SKILL.md-bestand alles wat je nodig hebt. Maar het moment dat je skills als mappen behandelt — met scripts, referentiebestanden, templates en data — vermenigvuldigt hun kracht zich.

Dit is de structuur van mijn Aria content-skill zoals die er vandaag uitziet:

aria/
  SKILL.md              # Core instructions, loaded on trigger
  aria-system-prompt.md # Full brand guidelines, loaded on demand
  references/
    banned-phrases.md   # AI detection trigger phrases
    footer-templates.md # Brand-specific CTA footers
    headline-formulas.md # Proven header structures by brand
  assets/
    post-template.md    # Skeleton for new blog posts
  scripts/
    word-count.sh       # Validates 3,000-5,000 word requirement

Het SKILL.md-bestand wordt onder 500 regels gehouden. Het bevat de kernidentiteit, de schrijffilosofie en verwijzingen naar referentiebestanden. Wanneer Claude een post genereert voor mejba.me, leest het de merkspecifieke secties uit de systeemprompt. Wanneer het een kop moet controleren tegen bewezen formules, haalt het uit references/headline-formulas.md. De lijst met verboden zinnen staat in een eigen bestand omdat het vaak verandert en ik niet wil dat bewerkingen eraan mijn kerninstructies vervuilen.

Dit is progressive disclosure in actie. Claude laadt niet alles tegelijk. De YAML-frontmatter — naam en beschrijving — komt in de prompt bij het starten van de sessie. Dat zijn ruwweg 100 tokens. De SKILL.md-body laadt wanneer Claude bepaalt dat de skill relevant is. De referentiebestanden laden alleen wanneer SKILL.md Claude expliciet opdraagt om ze te lezen.

Waarom is dit belangrijk? Omdat context window-beheer een echte beperking is. Elk token aan skill-instructies is een token dat niet kan worden gebruikt voor de eigenlijke taak. Als ik mijn hele Aria-systeem — merkrichtlijnen voor vier websites, vijftig verboden zinnen, footer-templates, koppen-formules, de volledige contentarchitectuur-blauwdruk — in één enkel SKILL.md-bestand zou dumpen, zou dat duizenden tokens zijn die voor elk gesprek geladen worden, zelfs als ik Claude alleen maar vraag om een typfout te corrigeren.

De mappenstructuur maakt onderhoud ook drastisch makkelijker. Wanneer ik verboden zinnen moet bijwerken, bewerk ik één bestand. Wanneer ik een nieuw merk toevoeg, update ik de systeemprompt zonder de kern-skilllogica aan te raken. Wanneer een teamgenoot wil begrijpen wat de skill doet, lezen ze SKILL.md. Wanneer ze de diepgaande merkrichtlijnen willen begrijpen, lezen ze de referentiebestanden.

Een patroon dat ik recent ben gaan gebruiken: template-bestanden opnemen in assets/ die Claude kopieert en invult in plaats van van scratch te genereren. Mijn blogpost-template bevat het metadata-blok, de fasestructuurmarkers en de verplichte footer. Claude hoeft het exacte formaat niet te onthouden — het kopieert gewoon de template en vult de lege plekken in. Minder formaatfouten, consistentere output.

Als je liever iemand hebt die dit soort skill-architectuur voor jouw workflows bouwt, neem ik aangepaste Claude Code-setups en integraties aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Er is hier echter een subtiliteit die ik bijna had gemist — en het gaat over wat je niet in de skill stopt.

Wat ik leerde over Claude niet op rails zetten

Mijn eerste generatie skills waren dictators. Elke stap voorgeschreven. Elk outputformaat vastgelegd. Elke beslissing van tevoren genomen.

De resultaten waren consistent. Ze waren ook middelmatig.

Het probleem met het overspecificeren van een skill is dat je Claude's vermogen om zich aan te passen verliest. Je converteert in feite een intelligente redeneermotor naar een template-invuller. En template-invullers kunnen niet omgaan met randgevallen. Ze verrassen je niet met een betere aanpak dan degene die je had gepland. Ze vangen geen fouten op in je eigen instructies.

Ik leerde deze les met mijn code review-skill. Versie één was een checklist van twintig stappen: controleer op ongebruikte imports, verifieer foutafhandeling, bevestig testdekking, valideer naamgevingsconventies... Claude zou methodisch elk item doorlopen en een perfect geformatteerde review produceren. Maar de reviews misten de dingen die er echt toe deden — architectuuroverwegingen, prestatie-implicaties, beveiligingskwetsbaarheden die niet netjes in een checklistitem pasten.

Versie twee stripte de checklist terug naar vijf principes en een gotchas-sectie. In plaats van "controleer op ongebruikte imports" stond er "prioriteer bevindingen op daadwerkelijke impact op productiebetrouwbaarheid." In plaats van het outputformaat voor te schrijven, stond er "structureer je review zodat de auteur begrijpt waarom achter elke bevinding."

De reviews werden dramatisch beter. Claude begon dingen te vangen die de checklist nooit had gedekt — race conditions, API-contractschendingen, subtiele state management-bugs. Het dacht na over de code in plaats van vakjes af te vinken.

Het principe dat ik nu volg: geef Claude de informatie die het nodig heeft en de flexibiliteit om zich aan de situatie aan te passen. Vertel wat belangrijk is, niet precies wat het moet doen. Neem je gotchas en beperkingen op, maar laat ruimte voor het model om zijn eigen oordeel toe te passen.

Er is een concrete manier om te testen of je hebt overgespecificeerd: voer dezelfde taak drie keer uit met je skill. Als de outputs bijna identiek zijn in structuur en inhoud, is je skill waarschijnlijk te rigide. Als ze consistent zijn in kwaliteit maar gevarieerd in aanpak, heb je de sweet spot gevonden.

Dit flexibiliteitsprincipe geldt ook voor skill-triggers — en dat is waar het description-veld cruciaal wordt.

Het description-veld is marketing naar het model, niet naar mensen

Wanneer Claude Code een sessie start, bouwt het een overzicht van elke beschikbare skill met zijn beschrijving. Dit overzicht is wat Claude scant om te beslissen "is er een skill voor dit verzoek?" Het description-veld is geen samenvatting voor menselijke lezers. Het is een triggerspecificatie voor het model.

Ik maakte deze fout met mijn eerste batch skills. Mijn commit message-skill had een beschrijving als: "Helpt betere commit messages te schrijven." Vaag. Generiek. Claude triggerde het voor alles dat ook maar enigszins met git te maken had, inclusief momenten waarop ik alleen een log of diff wilde bekijken.

De herziene beschrijving: "Gebruik wanneer de gebruiker vraagt om een commit te maken, een commit message te schrijven, of /commit zegt. Trigger niet voor git log, git diff, git status, of andere alleen-lezen git-operaties."

Dag en nacht verschil. Claude triggert de skill nu precies wanneer ik het nodig heb en blijft uit de weg wanneer ik dat niet doe.

Een paar patronen die ik effectief vind voor beschrijvingen:

Positieve triggers — wat de skill moet activeren: "Gebruik wanneer de gebruiker vraagt om een blogpost te maken, een artikel te schrijven, content te genereren, of een van deze merken noemt: mejba.me, ramlit.com, colorpark.io, xcybersecurity.io."

Negatieve triggers — wat het NIET moet activeren: "Trigger niet voor code reviews, bugfixes of technische documentatie."

Contextcondities — wanneer de skill van toepassing is: "Alleen relevant bij het werken in repositories die Laravel 11+ met Livewire gebruiken."

Dit goed krijgen voorkomt een probleem dat grotere skill-collecties plaagt: triggerconflicten. Wanneer twee skills allebei beweren "schrijftaken" af te handelen, moet Claude raden welke je wilt. Specifieke, goed afgebakende beschrijvingen elimineren het giswerk.

Dit wordt nog belangrijker wanneer je skills gaat combineren, en dat is waar de echte kracht zich toont.

Skills combineren: waar het multipliereffect begint

Individuele skills zijn nuttig. Skills die naar elkaar verwijzen en op elkaar voortbouwen zijn transformatief.

Mijn contentpipeline werkt als volgt: de Aria-skill behandelt contentgeneratie. Het verwijst naar een SEO toolkit-skill voor zoekwoordenonderzoek en optimalisatie. De SEO-skill verwijst op zijn beurt naar een data-analyse-skill die verkeersgegevens en Search Console-metrics kan ophalen. Wanneer ik Claude vraag om "een post te maken voor mejba.me over Docker networking," coördineren deze drie skills automatisch.

De compositie wordt niet beheerd door een dependency-systeem — Claude Code heeft nog geen native dependency management voor skills. In plaats daarvan verwijs ik naar andere skills bij naam in mijn SKILL.md-bestanden: "Voor SEO-analyse, roep de seo-toolkit-skill aan." Claude leest deze instructie en roept de verwezen skill aan als die geïnstalleerd is.

Dit werkt verrassend goed in de praktijk. Maar er is een valkuil: circulaire verwijzingen. Als skill A zegt "check bij skill B" en skill B zegt "verifieer bij skill A," komt Claude in een lus terecht. Dit overkwam me met mijn code review- en testing-skills — de review-skill zei "verifieer dat tests bestaan" en de testing-skill zei "controleer code review-bevindingen." De oplossing was de afhankelijkheid eenrichting maken: code review kan testing practices aanroepen, maar niet andersom.

Een ander compositiepatroon dat vruchten heeft afgeworpen: het gebruik van een eenvoudige "orchestrator"-skill die weet van al je andere skills en taken naar de juiste doorstuurt. Mijn development workflow-skill doet zelf geen echt werk — het weet alleen dat code scaffolding naar de scaffolding-skill gaat, reviews naar de review-skill en deployments naar de CI/CD-skill. Het is een dispatcher, en het voorkomt dat ik moet onthouden welke skill wat afhandelt.

Het orchestrator-patroon maakt het onboarden van nieuwe teamleden ook triviaal. Ze installeren één skill, en het routeert automatisch naar alles wat ze verder nodig hebben. Wat de vraag oproept hoe je skills überhaupt deelt binnen een team.

Hoe ik skills distribueer zonder chaos te creëren

Skills delen klinkt eenvoudig. Check ze in je repo in onder .claude/skills/ en iedereen heeft ze. Klaar.

Behalve dat het niet klaar is. Want elke skill die in de repo is ingecheckt voegt toe aan de context die Claude laadt voor elk teamlid, of ze die skill nu nodig hebben of niet. Een team van vijf met elk tien skills betekent vijftig skills in context. Dat is veel ruis.

De aanpak waar ik op ben uitgekomen gebruikt twee niveaus.

Niveau één: repo-niveau skills gaan in .claude/skills/ en worden ingecheckt in de repository. Dit zijn skills die elke bijdrager nodig heeft — codestijlhandhaving, testconventies, deploymentprocedures. Als je aan deze codebase werkt, heb je deze skills nodig. Punt. Ik houd deze lijst bewust klein: drie tot vijf skills per repo, maximaal.

Niveau twee: persoonlijke en rolspecifieke skills worden gedistribueerd als plugins via een gedeelde map. Mijn contentskills, mijn SEO-tools, mijn design system-referenties — die worden per gebruiker geïnstalleerd. Ontwikkelaars in het team hebben mijn Aria content-skill niet nodig. Ik heb hun databasemigratie-skill niet nodig. Iedereen installeert wat relevant is voor hun werk.

Voor teams groter dan ongeveer tien mensen zou ik aanraden om een interne plugin-marktplaats te bouwen — een gedeelde GitHub-repo waar mensen beschikbare skills kunnen doorbladeren, beschrijvingen kunnen lezen en installeren wat ze nodig hebben. Anthropic's interne teams doen iets vergelijkbaars: skills beginnen in een sandbox-map, mensen delen ze via Slack, en zodra een skill tractie heeft, dient de eigenaar een PR in om het naar de officiële marktplaats te verplaatsen.

De curatiestap is belangrijker dan je zou denken. Ongecontroleerd groeien skill-collecties snel. Mensen maken skills voor elk klein irritatiepuntje, en binnen een paar maanden heb je veertig skills waar tien zouden volstaan. Voordat ik iets toevoeg aan een gedeelde marktplaats, vraag ik: "Zouden minstens drie mensen in dit team deze skill minstens één keer per week gebruiken?" Als het antwoord nee is, blijft het persoonlijk.

Nog een distributieles die ik op de harde manier heb geleerd — die ook toevallig een van de krachtigste features is die de meeste mensen niet kennen.

On-demand hooks veranderden hoe ik over veiligheid denk

Skills kunnen hooks registreren die alleen actief worden wanneer de skill wordt aangeroepen, en die duren voor de hele sessie. Dit is anders dan globale hooks die altijd draaien. On-demand hooks zijn contextuele vangrails.

Mijn /careful-skill is het beste voorbeeld. Wanneer ik op het punt sta om aan productie-infrastructuur te werken, roep ik het aan. De skill registreert PreToolUse-hooks die rm -rf, DROP TABLE, force-push en kubectl delete blokkeren. Deze hooks onderscheppen elk Bash-commando dat Claude probeert uit te voeren en weigeren alles dat overeenkomt met de gevaarlijke patronen.

Ik wil niet dat deze hooks altijd draaien — ze zouden waanzinnig irritant zijn tijdens normale ontwikkeling. Maar wanneer ik aan productiedatabases of live Kubernetes-clusters werk, zijn ze niet-onderhandelbaar. De skill geeft me een schakelaar: maximale veiligheid wanneer ik het nodig heb, nul overhead wanneer ik dat niet doe.

Een andere on-demand hook die ik gebruik: /freeze, die elke Edit- of Write-operatie buiten een specifieke map blokkeert. Wanneer ik een productieprobleem debug, wil ik dat Claude vrij kan lezen en analyseren maar niet per ongeluk iets wijzigt. De freeze-skill vergrendelt het bestandssysteem terwijl leestoegang open blijft.

Het hook-systeem maakt ook meting mogelijk. Ik draai een PreToolUse-hook die elke skill-aanroep logt — welke skill, wanneer het triggerde, in welke context het draaide. Na een maand aan data kan ik zien welke skills populair zijn, welke te weinig triggeren (wat betekent dat hun beschrijvingen werk nodig hebben), en welke te veel triggeren (wat betekent dat hun scope te breed is).

Dit soort instrumentatie klinkt als overkill totdat je dertig skills beheert en probeert uit te zoeken waarom je Claude Code-sessie langzamer is dan zou moeten. De loggingdata vertelt je precies waar het contextbudget naartoe gaat.

Over contextbudgetten gesproken — er is een geheugenpatroon dat ik wou dat ik vanaf dag één had gebruikt.

Je skills leren onthouden

Sommige van mijn meest effectieve skills behouden staat tussen sessies door. Niet via een ingewikkelde database — via platte tekstbestanden.

Mijn standup-post-skill houdt een standups.log-bestand bij. Elke keer dat het een standup genereert, voegt het de output toe. De volgende ochtend leest Claude zijn eigen geschiedenis en weet precies wat er sinds gisteren is veranderd. De standups gingen van generieke samenvattingen naar precieze deltarapporten: "De auth-refactor PR die sinds dinsdag blokkeerde is gemerged. Drie nieuwe tickets geopend, allemaal getriaged naar de huidige sprint."

Mijn contentpipeline-skill houdt bij welke onderwerpen ik heb behandeld, welke zoekwoorden ik heb getarget, en welke interne links ik heb geplaatst. Wanneer ik om een nieuwe post vraag, controleert Claude het logboek en vermijdt het dupliceren van invalshoeken die ik al heb gepubliceerd. Het kan ook interne links naar bestaande content suggereren omdat het weet wat er al is.

De implementatie is doodeenvoudig. Een JSON-bestand of een append-only log in een stabiele map. Claude Code biedt ${CLAUDE_PLUGIN_DATA} als een stabiele map per plugin specifiek voor dit doel — data die hier wordt opgeslagen blijft behouden zelfs wanneer je de skill upgradet.

// ${CLAUDE_PLUGIN_DATA}/content-history.json
{
  "posts": [
    {
      "date": "2026-03-10",
      "brand": "mejba.me",
      "slug": "opus-4-6-hands-on-review",
      "primary_keyword": "Claude Opus 4.6 review",
      "internal_links": ["claude-sonnet-5-agentic-coding", "claude-agent-teams-guide"]
    }
  ],
  "keywords_used": ["Claude Opus 4.6", "agentic coding", "agent teams"],
  "next_suggested": ["Claude Code skills deep dive", "hook development patterns"]
}

Eén waarschuwing: sla geheugendata niet op in de skill-map zelf. Wanneer je een skill upgradet, kan de map worden overschreven. Ik verloor twee maanden standup-geschiedenis door deze les te leren. Gebruik altijd een stabiel extern pad.

Het geheugenpatroon opent ook iets krachtigs — skills die zichzelf in de loop van de tijd verbeteren. Elke keer dat Claude een nieuw randgeval tegenkomt en ik het toevoeg aan de gotchas-sectie, is dat handmatige verbetering. Maar een skill die zijn eigen fouten logt en ze ter review presenteert? Dat komt in de buurt van zelfverbetering. Ik heb deze cyclus nog niet volledig geautomatiseerd, maar de logging-infrastructuur maakt het mogelijk.

Goed — dat dekt de principes. Hoe ziet dit er in de praktijk uit als je alles samenvoegt?

Hoe mijn daadwerkelijke workflow eruitziet in maart 2026

Dit is een typische maandagochtend. Ik open Claude Code en start een sessie. Drie repo-niveau skills laden automatisch vanuit .claude/skills/: codestijlhandhaving, testconventies en onze deployment-checklist. Mijn persoonlijke plugins laden ook: Aria (content), SEO toolkit, commit-conventies, code review, TDD-workflow, en een paar utility-skills.

Totale context-overhead bij sessiestart: ruwweg 600 tokens voor alle skill-beschrijvingen. De daadwerkelijke skill-body's zijn nog niet geladen — ze wachten op relevantie.

Ik typ: "Maak een post voor mejba.me over Docker networking best practices."

Claude scant de skill-beschrijvingen, identificeert Aria als relevant en laadt de SKILL.md-body. Aria's instructies vertellen Claude om het contentgeschiedenislog te controleren, dat zich bevindt in ${CLAUDE_PLUGIN_DATA}. Claude leest de geschiedenis, bevestigt dat ik deze specifieke invalshoek nog niet eerder heb behandeld, en identificeert twee bestaande posts die intern gelinkt moeten worden.

De Aria-skill verwijst naar de SEO toolkit. Claude laadt die skill ook, voert zoekwoordanalyse uit en bepaalt primaire en secundaire zoekwoorden. Beide skills zijn nu actief en werken samen.

Claude genereert het volledige contentpakket — metadata, artikel van 3.500 woorden, merkgeschikte footer. Het woordtelscript in aria/scripts/ valideert de lengte. Als het onder de 3.000 of boven de 5.000 woorden is, past Claude het aan. Het contentgeschiedenislog wordt bijgewerkt met de nieuwe postdetails.

Totale tijd: ongeveer acht minuten. Hetzelfde werk zonder skills — merkrichtlijnen uitleggen, SEO-vereisten, contentarchitectuur, verboden zinnen, footerformaat, interne linkstrategie — zou veertig minuten prompt engineering kosten voordat Claude zelfs maar begint met schrijven.

Dat is geen productiviteitshack. Dat is een fundamentele verschuiving in hoe ik met AI werk.

De drie fouten die ik steeds zie (en soms nog steeds maak)

Na een dozijn ontwikkelaars te hebben geholpen hun eigen skill-systemen op te zetten, verschijnen dezelfde drie fouten steeds opnieuw.

Fout één: skills bouwen voor dingen die Claude al goed doet. Als je een skill schrijft die Claude vertelt hoe het een for-lus moet schrijven of een JSON-response moet structureren, verspil je moeite. Skills moeten kennis coderen die Claude niet heeft — jouw specifieke conventies, jouw interne API's, de faalwijzen van je team. Test dit door de taak eerst zonder de skill uit te voeren. Als de output al 80% is van wat je wilt, heb je waarschijnlijk geen skill nodig. Je hebt een zin nodig in je CLAUDE.md-bestand.

Fout twee: skills nooit bijwerken na creatie. Skills zijn geen eenmalige artefacten. Claude verbetert bij elke modelupdate. Je codebase evolueert. Je teamconventies veranderen. Een skill die drie maanden geleden perfect was, kan vandaag actief schadelijk zijn. Ik plan een maandelijkse "skill audit" — dertig minuten waarin ik elke skill review, verouderde gotchas snoei, en test of de skill de output nog meetbaar verbetert vergeleken met draaien zonder.

Fout drie: skills te breed maken. Een "development helper"-skill die codestijl, testen, deployment en documentatie behandelt, zijn vier skills in een trenchcoat die doen alsof ze er één zijn. Splits het. Elke skill moet een enkel, duidelijk doel hebben dat je in één zin kunt formuleren. Als je het woord "en" nodig hebt om te beschrijven wat een skill doet, zijn het waarschijnlijk twee skills.

Er is een vierde fout die subtieler is en moeilijker te detecteren: niet investeren in verificatie-skills. Ik heb maanden besteed aan het bouwen van generatie-skills — skills die Claude helpen dingen te maken. Maar ik investeerde nauwelijks in skills die Claude helpen zijn eigen output te verifiëren. Verificatie-skills zijn saai om te bouwen maar ze vangen fouten voordat ze productie bereiken. Een signup flow-driver die de volledige gebruikersreis test. Een checkout-verificator die Stripe-testkaarten uitprobeert. Een deployment smoke test die bevestigt dat health checks slagen. Deze skills produceren geen indrukwekkende outputs. Ze voorkomen gênante fouten. Als ik terug zou kunnen gaan en mijn skill-bouwtijd zou herverdelen, zou verificatie 40% van het budget krijgen in plaats van de 10% die het daadwerkelijk kreeg.

Wat er hierna komt voor skills (en waar ik naartoe bouw)

Het skills-ecosysteem per maart 2026 rijpt snel. Anthropic's officiële skill-marktplaats heeft explosieve groei doorgemaakt — de frontend-design-skill alleen al heeft meer dan 277.000 installaties. Communityplatforms zoals skills.sh bieden doorzoekbare directory's georganiseerd op categorie, auteur en aantal installaties. Het npx skills add-commando heeft installatie triviaal eenvoudig gemaakt.

Maar de echte evolutie zit in hoe skills samenstellen en communiceren. Op dit moment wordt skill-compositie afgehandeld via naamverwijzingen in markdown — "roep de X-skill aan." Het werkt, maar het is handmatig en fragiel. Ik verwacht native dependency management binnen het komende jaar, waarbij de frontmatter van een skill vereisten kan declareren die automatisch worden geladen.

Ik volg ook de kruising van skills en hooks nauwlettend. On-demand hooks die per skill activeren zijn al krachtig. De volgende stap is hooks die coördineren tussen skills — een code review-skill die automatisch een testing-skill triggert, die een deployment readiness check triggert, allemaal in een geverifieerde pipeline. Nu bedraad ik deze handmatig. Binnenkort zullen ze declaratief zijn.

De meest interessante grens zijn skills die leren — niet door training, maar door gestructureerde logging en zelfreflectie. Ik heb een prototype draaien met mijn contentpipeline waar Claude zijn geschiedenislog wekelijks reviewt, patronen identificeert in de bewerkingen die ik heb gemaakt, en toevoegingen aan de lijst met verboden zinnen voorstelt. We zijn nog niet bij autonome zelfverbetering. Maar de bouwstenen zijn er allemaal.

De skills die over een jaar het meest zullen uitmaken zijn niet de meest opvallende. Het zijn degene die stilletjes je dagelijks werk verbeteren en elke maand een beetje scherper worden omdat iemand dertig minuten nam om de gotchas te reviewen.

Begin daar. Bouw deze week één skill voor de taak die je het vaakst doet. Houd de instructies minimaal en de gotchas-sectie leeg. Gebruik het een maand. Voeg elke fout toe aan gotchas. Aan het einde van de maand heb je iets echt nuttigs. En je zult begrijpen, op een manier die geen documentatie kan leren, waarom skills de krachtigste extensiemogelijkheid in Claude Code zijn.

Wat is die ene workflow die je elke dag herhaalt en die nog steeds handmatige prompting vereist? Dat is je eerste skill. Ga het bouwen.

Veelgestelde vragen

Hoeveel Claude Code-skills moet ik tegelijk geïnstalleerd hebben?

Houd repo-niveau skills op drie tot vijf per repository en persoonlijke skills onder vijftien totaal. Daarboven verbruiken skill-beschrijvingen merkbare context en worden triggerconflicten moeilijker te beheren. Kwaliteit en specificiteit winnen het van kwantiteit — elke keer.

Wat is het verschil tussen een Claude Code-skill en een CLAUDE.md-bestand?

CLAUDE.md laadt bij elk gesprek in een project en dekt algemene codebase-context. Skills laden alleen wanneer ze worden getriggerd door relevante verzoeken, kunnen scripts en referentiebestanden bevatten, en ondersteunen hooks. Gebruik CLAUDE.md voor universele projectfeiten; gebruik skills voor specifieke workflows.

Hoe vaak moet ik mijn Claude Code-skills bijwerken?

Maandelijkse reviews werken goed voor de meeste teams. Controleer elke skill tegen Claude's huidige native mogelijkheden, snoei verouderde gotchas, en test of de skill de output nog meetbaar verbetert vergeleken met draaien zonder. Modelupdates kunnen capability-uplift-skills snel overbodig maken.

Kunnen Claude Code-skills andere skills aanroepen?

Ja, via naamverwijzingen in je SKILL.md-instructies. Schrijf "roep de [skill-naam]-skill aan voor deze stap" en Claude zal het triggeren als het geïnstalleerd is. Native dependency management is er nog niet, dus houd verwijzingen eenrichting om circulaire lussen te voorkomen.

Waar moet ik data opslaan die mijn skills genereren tussen sessies door?

Gebruik de ${CLAUDE_PLUGIN_DATA}-omgevingsvariabele, die een stabiele per-plugin map biedt die behouden blijft bij skill-upgrades. Sla nooit persistente data op in de skill-map zelf — deze kan worden overschreven bij updates.

Laten we samenwerken

Op zoek naar hulp bij het bouwen van AI-systemen, automatiseren van workflows, of opschalen van je technische infrastructuur? 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