Hoeveel Claude Skills moet je installeren?

Minder dan je denkt. Voor de meeste mensen die normaal werk doen in Claude Code, ligt het aantal dat maandenlang standhoudt ergens tussen de vijf en acht actief gebruikte skills, exclusief wat gebundeld wordt geleverd in een plugin die je niet individueel hebt gekozen. Dat is geen strikte bovengrens. Het is het punt waarop het portfolio waar je daadwerkelijk naar grijpt, stopt met groeien, ongeacht hoeveel meer je installeert.

De reden dat het laag is, is niet rommel in een mapweergave. Elke skill die je installeert, of je hem nu gebruikt of niet, plaatst zijn trigger description voor Claude bij elk verzoek, voor altijd, en elke extra description is weer iets dat Claude correct moet negeren. Voorbij een bepaald punt voegt het toevoegen van skills geen functionaliteit toe. Het voegt ruis toe waar de goede skills tegen moeten concurreren.

Dit artikel is de rekenkunde achter dat getal: wat een geïnstalleerde maar inactieve skill je kost, waarom twee overlappende skills erger zijn dan één alleen, en de portfoliostructuur die we zelf gebruiken na het catalogiseren en testen van 73 ervan.

Wat een geïnstalleerde skill je daadwerkelijk kost

Skills laden in twee fasen. Bij de start van een sessie leest Claude alleen de frontmatter, de name en description, van elke skill die het kan vinden, typisch 50 tot 150 tokens per stuk. Die metadata blijft gedurende de hele sessie in context, ongeacht of de skill ooit wordt geactiveerd. De volledige body, de daadwerkelijke instructies, wordt alleen geladen wanneer een verzoek overeenkomt met de description. Dat is progressieve openbaarmaking, en het is de reden waarom skills beter schalen dan geplakte prompts. We hebben het mechanisme behandeld in wat Claude skills zijn.

Het 'altijd-aan' gedeelte is het deel dat mensen vergeten mee te tellen. Stel dat je 30 skills hebt geïnstalleerd met gemiddeld 100 tokens aan frontmatter per stuk: 3.000 tokens die voor elk bericht, elke beurt, elke sessie staan, ongeacht of ze relevant zijn. Bij 30 beurten in een werksessie is dat 90.000 tokens die worden besteed aan het herlezen van een metadatalijst voordat Claude iets doet wat je hebt gevraagd. Over 22 werkdagen is dat bijna 2 miljoen tokens per maand aan pure 'wachtbelasting'. Niets hiervan is op zichzelf duur, een paar cent tegen Sonnet tarieven. Maar het concurreert om ruimte in het contextvenster en stapelt zich op met al het andere dat meereist: CLAUDE.md, MCP tool schemas, sessiegeschiedenis. We hebben de volledige uitsplitsing gedaan in Claude token kosten verlagen.

De grotere kosten zijn geen dollars. Het is aandacht. Claude beslist welke skill te laden door je verzoek te matchen met een stapel descriptions, en die match wordt minder betrouwbaar naarmate de stapel groeit en descriptions beginnen te overlappen in vocabulaire. Een skill die je in maart hebt geïnstalleerd en sindsdien niet hebt gebruikt, zit nog steeds in die stapel elke keer dat je in april iets vraagt, waardoor de juiste match stilletjes één optie is uit 41 in plaats van één optie uit 8.

Het botsingsprobleem: twee skills, één verzoek

Installeer genoeg skills en uiteindelijk zullen twee ervan dezelfde taak met verschillende woorden beschrijven. Dit is geen hypothetisch scenario. We kwamen het tegen bij het bouwen van onze eigen testcatalogus: twee naast elkaar geïnstalleerde marketingpakketten leverden beide een skill voor outreach copy, cold-email en email-sequences, met descriptions die voldoende overlapten zodat een enkele "write me a follow-up email" prompt aannemelijk beide kon matchen.

Wanneer dat gebeurt, vindt een van de drie dingen plaats, en geen ervan wordt aan jou bekendgemaakt. Claude kiest er één, geruisloos, gebaseerd op welke description als een iets betere match leest voor jouw exacte formulering, zodat dezelfde prompt op twee verschillende manieren gevraagd twee verschillende skills kan activeren. Of een harde botsing op het name veld betekent dat de ene skill de andere volledig overschaduwt; de tweede wordt dan simpelweg nooit geladen, en je krijgt geen foutmelding die je dat vertelt. Of, in het ergste geval, probeert Claude beide gedeeltelijke matches tegelijkertijd te bevredigen en produceert output die is samengesteld uit twee sets instructies die nooit waren ontworpen om samen te werken: je e-mail skill en je tone-of-voice skill die beide proberen dezelfde zin te 'bezitten'.

De oplossing is diagnostisch, niet preventief, omdat je over het algemeen niet weet dat twee skills botsen totdat het gebeurt. We hebben de volledige zes-punten checklist hiervoor geschreven in Claude skill activeert niet, maar de korte versie specifiek voor portfoliogrootte: als je niet in één zin kunt uitleggen waarom skill A een verzoek afhandelt in plaats van skill B, overlappen ze te veel om beide geïnstalleerd te blijven. Voeg ze samen, verwijder er één, of herschrijf de zwakkere description om een smaller, niet-overlappend deel van de taak uit te snijden. Het aantal botsingen in een portfolio schaalt ruwweg met het kwadraat van de grootte, wat de wiskundige versie is van "houd het klein".

De portfoliobenadering: ankers, situationals, experimenten

Zodra je accepteert dat elke geïnstalleerde skill doorlopende kosten met zich meebrengt, verschuift de vraag van "moet ik dit installeren" naar "in welke categorie hoort het thuis". Wij sorteren de onze in drieën.

Ankers zijn de twee tot vijf skills die je binnen een dag zou missen als ze verdwenen. Documentgeneratie als je wekelijks rapporten schrijft. Een debugging discipline als je dagelijks code schrijft. Een toon- of bewerkingsskill als je werk uit woorden bestaat. Deze verdienen een permanente plek in ~/.claude/skills/, beschikbaar in elk project, en het is de enige categorie die de moeite waard is om op goed vertrouwen te installeren voordat je hebt bewezen dat de trigger specifiek voor jou werkt.

Situationals zijn reëel en nuttig, maar beperkt tot één context: een migratiechecklist voor één codebase, de specifieke merkstem van een klant, een compliance skill die alleen jouw gereguleerde project nodig heeft. Deze horen thuis in de .claude/skills/ map van een project, niet in je persoonlijke map. Ze reizen mee met de repo, ze zijn zichtbaar voor teamgenoten die deze klonen, en cruciaal is dat hun description alleen concurreert om aandacht binnen sessies waar ze daadwerkelijk relevant zijn. Het globaal installeren van een klantspecifieke skill betekent dat de description ook meereist met elk ongerelateerd project dat je aanraakt.

Experimenten zijn alles wat je probeert omdat een collega het aanbeval of een catalogusitem goed scoorde. Geef deze een strikte deadline van twee weken vanaf de installatie. Als je er na twee weken geen ongevraagd, natuurlijk, zonder moeite te doen om het te testen, hebt gebruikt, verwijder het dan. De meeste experimenten slagen niet voor deze test, en dat is prima; daar is de proefperiode voor. De fout is niet het proberen van skills, het is het laten uitgroeien van ongeteste skills tot permanente ankerstatus, alleen maar omdat het verwijderen van een map voelt als toegeven dat de proef mislukt is.

Deze structuur beantwoordt ook de "hoeveel" vraag nuttiger dan een enkel getal. Het is niet "installeer in totaal 6 skills." Het is "houd je ankers beperkt tot wat je echt zou missen, houd situationals afgebakend tot waar ze ertoe doen, en geef al het andere een vervaldatum."

Wat op onze eigen bank overleefde

We testen elke skill in de SkillProof catalogus op een schone installatie voordat deze een oordeel krijgt, en afzonderlijk worden sommige van die geteste skills degenen waar we dagelijks naar grijpen, maanden nadat de review is gepubliceerd. Die tweede lijst is kort, en het is informatief juist omdat hij kort is.

DOCX (9.6/10) is degene die we het snelst zouden missen als hij verdween. Anthropic's eigen referentie skill, en de reden is saai: we produceren de meeste weken Word-documenten, en het schrijft echte, met inhoudsopgaven, bijgehouden wijzigingen, briefhoofden intact, in plaats van markdown die we handmatig zouden moeten herformatteren.

Systematic Debugging (9.6/10) en Test-Driven Development (9.6/10), beide uit de Superpowers collectie, zijn het paar dat veranderde hoe onze eigen sessies verlopen in plaats van wat ze produceren. Geen scripts, geen externe tools, pure gedragsverandering: red-green-refactor elke keer afgedwongen, een debugging discipline die Claude niet laat gissen naar een oplossing voordat de bug is gereproduceerd. Dit zijn de duidelijkste gevallen in onze catalogus voor een skill die ankerstatus verdient op basis van output alleen.

Memory Management (9.2/10) verdient zijn plek door op de beste manier onzichtbaar te zijn: het voorkomt dat context vervliegt tussen sessies zonder dat wij handmatig een notitiebestand hoeven te beheren.

Merk op wat afwezig is. Onze catalogus bevat 73 skills; 35 hebben een schone 'pass' beoordeling. We gebruiken misschien acht van die 35 als echte dagelijkse ankers. De andere 27 zijn goed, getest en eerlijk over wat ze doen, en de meeste bevinden zich voor ons nog steeds in een situationele of experimentele status, omdat "getest en goed" en "hoort in je permanente vijf tot acht" verschillende maatstaven zijn. Een skill kan 9/10 scoren in een review en toch verkeerd zijn om globaal geïnstalleerd te houden als je de use case ervan twee keer per kwartaal aanraakt.

Het maandelijkse snoeiritueel

Portfolio's drijven af. Een skill die voor één project is geïnstalleerd, overleeft het project. Een experiment overleeft zijn twee weken durende klok omdat het verwijderen van dingen niemands favoriete klus is. De oplossing is een terugkerende tien-minuten 'pass', geen eenmalige opruiming.

Once a month, run through this:

1. Lijst op wat er daadwerkelijk is geïnstalleerd. ls ~/.claude/skills/ en ls .claude/skills/ voor elk project waarin je werkt. Als je een mapnaam niet herkent, is dat al je antwoord.
2. Vraag wanneer elk voor het laatst is geactiveerd. Als je je niet kunt herinneren dat je het de afgelopen maand hebt gebruikt, en het is geen anker dat je in vlagen gebruikt (belastingseizoen, kwartaalrapporten), dan is het een snoeikandidaat.
3. Controleer op overlap. Lees het description veld van elke skill naast elkaar. Twee die aannemelijk dezelfde prompt zouden kunnen beantwoorden, zijn een botsing die staat te gebeuren; zie de sectie hierboven.
4. Bevestig dat project-scoped skills daadwerkelijk project-scoped zijn. Alles wat specifiek is voor één klant of repo hoort niet in je persoonlijke map thuis, meereizend met elk ongerelateerd project.
5. Verwijder, archiveer niet. Een skill die ergens is uitgeschakeld, moet nog steeds niet worden verward met een actieve. Als het zijn plek niet verdient, verwijder dan de map.
6. Hertest je ankers. Vraag om iets wat elk anker zou moeten afhandelen, zonder het te benoemen, op de manier waarop we triggers testen voor de catalogus. Als het niet schoon activeert, overschaduwt iets dat sindsdien is toegevoegd het waarschijnlijk.

Tien minuten, eens per maand, en het portfolio blijft de grootte die nuttig is in plaats van af te drijven naar de grootte die zich alleen maar ophoopt.

Kwaliteit boven kwantiteit

Dit is de hele thesis van SkillProof samengevat in één sectie, en het is de moeite waard om het hier duidelijk te zeggen, want "hoeveel skills" is eigenlijk een proxy voor een andere vraag: wat is de marginale waarde van de volgende die je gaat installeren?

Van de 45 skills die we volledig hebben getest, zijn er 35 'pass' geslaagd en 10 hadden extra 'setup' nodig om überhaupt te werken. Dat is geen kritiek op het ecosysteem, het formaat is opzettelijk open, iedereen kan publiceren zonder review gate, en dat is precies waarom het snel groeide. Maar het betekent ook dat de gemiddelde skill op GitHub ongeverifieerd is, en het installeren van tien middelmatige skills levert geen goede op. Het levert tien trigger descriptions op die concurreren met je goede voor dezelfde match, tien inactieve metadata blokken bij elk verzoek, en een groeiend aantal paren die elkaar stilletjes kunnen dwarszitten. We zijn dieper ingegaan op de specifieke faalpatronen, vage descriptions die nooit activeren, output die niet beter is dan Claude's standaard, ontbrekende 'setup' stappen, in waarom de helft van Claude skills niet werkt.

De praktische versie: voordat je iets installeert, vraag je af of het de twee weken durende experimentklok zou overleven, en of het iets significant beters doet dan Claude ongevraagd zou doen. Als je op beide geen ja kunt antwoorden, kost het je niet veel om het over te slaan, maar het helpt je ook niet. Onze efficiëntieranglijsten sorteren geteste skills specifiek op die output-boven-baseline maatstaf, wat een snellere filter is dan zelf twintig READMEs lezen.

Veelgestelde vragen

Is er een harde limiet aan het aantal Claude skills dat ik kan installeren?

Geen technische limiet die we bij het testen zijn tegengekomen. Claude scant elke skill map die het vindt en laadt al hun frontmatter bij de start van de sessie, of dat nu 5 skills zijn of 150. De limiet die ertoe doet, is geen grens die Claude afdwingt, het is het punt waarop de 'altijd-aan' metadata belasting en de toenemende kans op description overlap meer beginnen te kosten dan een nieuwe skill toevoegt. Dat punt ligt voor de meeste mensen rond de 30 tot 40 geïnstalleerde skills, ruim vóór een plafond op formaatniveau.

Vertragen inactieve skills Claude of kosten ze alleen tokens?

Voornamelijk tokens en matchingsnauwkeurigheid, niet op een dramatische manier ruwe latentie. De frontmatter van een inactieve skill zit bij elke beurt in context, wat een kleine, reële kostenpost toevoegt die zich over een maand opstapelt, en het is weer een description die Claude moet afwegen bij het beslissen wat te activeren. Een handvol inactieve skills is oprecht onschadelijk. Veertig ervan is een ander verhaal, voornamelijk omdat de kans dat een verouderde skill een verzoek dat je belangrijk vindt overschaduwt of half matcht, toeneemt met het aantal.

Hoe weet ik of een skill die ik heb geïnstalleerd daadwerkelijk wordt gebruikt?

Vraag om iets wat het zou moeten afhandelen zonder het te benoemen, dezelfde triggertest die we uitvoeren voor elke catalogusvermelding. Als Claude's gedrag zichtbaar verandert, bijvoorbeeld, het produceert een echte .docx in plaats van geplakte markdown, dan is het geactiveerd. Als er niets verandert, komt de description niet overeen met hoe je verzoeken daadwerkelijk formuleert, of een andere skill wint de match eerst. Onze handleiding voor niet-activerende skills heeft het volledige zes-stappen proces om die twee uit elkaar te houden.

Moeten persoonlijke en project skills meetellen voor dezelfde limiet?

Behandel ze afzonderlijk. Persoonlijke skills in ~/.claude/skills/ reizen mee met elk project dat je aanraakt, dus dit zou de korte ankerlijst moeten zijn die je dagelijks zou missen, ongeacht de context. Project skills in .claude/skills/ laden hun frontmatter alleen in sessies binnen die repository, dus een project kan redelijkerwijs meer situationele skills bevatten zonder je andere werk te belasten. De fout die we het meest zien, is het plaatsen van klant-specifieke of repo-specifieke skills in de persoonlijke map, waar ze elk ongerelateerd project voor altijd belasten.

Wat is de snelste manier om een overwoekerde skill-lijst in te korten?

Voer het maandelijkse snoeiritueel één keer uit, onmiddellijk, in plaats van te wachten op de volgende geplande 'pass'. Lijst alles op wat is geïnstalleerd, verwijder alles waarvan je je niet kunt herinneren dat het de afgelopen maand is geactiveerd en wat geen bekend 'bursty' anker is, controleer de overlevenden op description overlap, en verplaats alles wat klant- of projectspecifiek is uit je persoonlijke map. De meeste overwoekerde setups dalen van 30-plus skills naar minder dan tien in de eerste 'pass', omdat het grootste deel van de lijst experimenten zijn die niemand heeft verwijderd.