Hur många Claude-färdigheter bör du installera?

Färre än du tror. För de flesta som utför normalt arbete i Claude Code är antalet som håller över månader någonstans mellan fem och åtta aktivt använda färdigheter, exklusive det som levereras i ett plugin du inte valde individuellt. Det är ingen absolut gräns. Det är punkten där portföljen du faktiskt använder slutar växa, oavsett hur många fler du installerar.

Anledningen till att det är lågt är inte röran i en mappvy. Varje färdighet du installerar, oavsett om du använder den eller inte, placerar sin triggerbeskrivning framför Claude vid varje förfrågan, för alltid, och varje extra beskrivning är ytterligare en sak Claude måste korrekt ignorera. Efter en viss punkt lägger tillägg av färdigheter inte till kapacitet. Det lägger till brus som de bra färdigheterna måste konkurrera mot.

Denna text förklarar matematiken bakom det antalet: vad en installerad men inaktiv färdighet kostar dig, varför två överlappande färdigheter är sämre än en ensam, och den portföljstruktur vi själva använder efter att ha katalogiserat och testat 73 av dem.

Vad en installerad färdighet faktiskt kostar dig

Färdigheter laddas i två steg. Vid sessionsstart läser Claude endast frontmattern, name och description, för varje färdighet den kan hitta, typiskt 50 till 150 tokens vardera. Denna metadata finns i kontexten under hela sessionen oavsett om färdigheten någonsin aktiveras. Hela kroppen, de faktiska instruktionerna, laddas endast när en förfrågan matchar beskrivningen. Det är progressiv upplysning, och det är anledningen till att färdigheter skalar bättre än inklistrade prompts. Vi täckte mekanismen i vad Claude-färdigheter är.

Den ständigt aktiva delen är den del folk glömmer att räkna med. Anta att du har installerat 30 färdigheter med i genomsnitt 100 tokens frontmatter vardera: 3 000 tokens som står framför varje meddelande, varje tur, varje session, oavsett om någon av dem är relevant. Vid 30 turer i en arbetssession är det 90 000 tokens som spenderas på att läsa om en metadata-lista innan Claude gör något du bett om. Under 22 arbetsdagar, nära 2 miljoner tokens i månaden i ren 'stå-och-vänta'-skatt. Inget av det är dyrt i sig, några cent till Sonnet-priser. Men det konkurrerar om utrymme i kontextfönstret och förstärks med allt annat som följer med: CLAUDE.md, MCP tool schemas, sessionshistorik. Vi gjorde en fullständig genomgång i att minska Claude token-kostnader.

Den större kostnaden är inte pengar. Det är uppmärksamhet. Claude bestämmer vilken färdighet som ska laddas genom att matcha din förfrågan mot en stapel beskrivningar, och den matchningen blir mindre pålitlig när stapeln växer och när beskrivningar börjar överlappa i ordförråd. En färdighet du installerade i mars och inte har använt sedan dess finns fortfarande i den stapeln varje gång du ber om något i april, vilket tyst gör den korrekta matchningen till ett alternativ av 41 istället för ett alternativ av 8.

Kollisionsproblemet: två färdigheter, en förfrågan

Installera tillräckligt många färdigheter och så småningom kommer två av dem att beskriva samma uppgift med olika ord. Detta är inte hypotetiskt. Vi stötte på det när vi byggde vår egen testkatalog: två marknadsföringspaket installerade sida vid sida levererade båda en färdighet för outreach-text, cold-email och email-sequences, med beskrivningar som överlappade tillräckligt för att en enda prompt som "skriv mig ett uppföljningsmejl" plausibelt kunde matcha någon av dem.

När det händer inträffar en av tre saker, och ingen av dem meddelas dig. Claude väljer en, tyst, baserat på vilken beskrivning som läses som en något bättre matchning för din exakta formulering, så samma prompt ställd på två olika sätt kan trigga två olika färdigheter. Eller en hård kollision på name-fältet innebär att en färdighet helt överskuggar den andra; den andra laddas helt enkelt aldrig, och du får inget felmeddelande som talar om det. Eller, i värsta fall, försöker Claude tillfredsställa båda partiella matchningarna samtidigt och producerar utdata som är sammansatt från två uppsättningar instruktioner som aldrig var avsedda att samarbeta: din e-postfärdighet och din tonfallsfärdighet som båda försöker äga samma mening.

Lösningen är diagnostisk, inte förebyggande, eftersom du generellt inte vet att två färdigheter kolliderar förrän de gör det. Vi skrev den fullständiga sexpunkts-checklistan för detta i Claude-färdighet triggar inte, men den korta versionen för portföljstorlek specifikt: om du inte kan förklara i en mening varför färdighet A hanterar en förfrågan istället för färdighet B, överlappar de för mycket för att båda ska förbli installerade. Slå ihop dem, ta bort en, eller skriv om den svagare beskrivningen för att skapa en smalare, icke-överlappande del av uppgiften. Antalet kollisioner i en portfölj skalar ungefär med kvadraten på dess storlek, vilket är den matematiska versionen av "håll det litet".

Portföljstrategin: ankare, situationsspecifika, experiment

När du väl accepterar att varje installerad färdighet har en löpande kostnad, skiftar frågan från "ska jag installera detta" till "vilken kategori tillhör det." Vi sorterar våra egna i tre.

Ankare är de två till fem färdigheter du skulle märka inom en dag om de försvann. Dokumentgenerering om du skriver rapporter varje vecka. En felsökningsdisciplin om du skriver kod dagligen. En ton- eller redigeringsfärdighet om ditt jobb är ord. Dessa får en permanent plats i ~/.claude/skills/, tillgängliga i varje projekt, och de är den enda kategorin värd att installera på förhand innan du har bevisat att triggern fungerar specifikt för dig.

Situationsspecifika är verkliga och användbara men avgränsade till en kontext: en migreringschecklista för en kodbas, en klients specifika varumärkesröst, en efterlevnadsfärdighet som bara ditt reglerade projekt behöver. Dessa hör hemma i ett projekts .claude/skills/-mapp, inte din personliga. De följer med repot, de är synliga för teammedlemmar som klonar det, och kritiskt, deras beskrivning konkurrerar bara om uppmärksamhet inom sessioner där de faktiskt är relevanta. Att installera en klientspecifik färdighet globalt innebär att dess beskrivning följer med varje orelaterat projekt du rör vid också.

Experiment är allt du provar för att en kollega rekommenderade det eller en katalogpost fick bra betyg. Ge dessa en strikt tvåveckorsklocka från installationen. Om du inte har använt en oombedd, naturligt, utan att anstränga dig för att testa den, vid slutet av två veckor, ta bort den. De flesta experiment misslyckas med detta test, och det är okej; det är vad provperioden är till för. Misstaget är inte att prova färdigheter, det är att låta otestade färdigheter tyst avancera till permanent-ankare-status bara för att det känns som att erkänna att försöket misslyckades att radera en mapp.

Denna struktur svarar också på frågan "hur många" mer användbart än ett enda nummer gör. Det är inte "installera totalt 6 färdigheter." Det är "håll dina ankare nere till vad du verkligen skulle sakna, håll situationsspecifika färdigheter avgränsade till där de är relevanta, och sätt ett utgångsdatum på allt annat."

Vad som överlevde på vår egen bänk

Vi testar varje färdighet i SkillProof-katalogen på en ren installation innan den får ett omdöme, och separat blir några av de testade färdigheterna de vi faktiskt använder dagligen, månader efter att recensionen publicerades. Den andra listan är kort, och den är informativ just för att den är kort.

DOCX (9.6/10) är den vi skulle märka snabbast om den försvann. Anthropic's egen referensfärdighet, och anledningen är tråkig: vi producerar Word-dokument de flesta veckor, och den skriver riktiga sådana, innehållsförteckningar, spårade ändringar, brevhuvuden intakta, istället för markdown som vi skulle behöva omformatera för hand.

Systematic Debugging (9.6/10) och Test-Driven Development (9.6/10), båda från Superpowers-samlingen, är paret som förändrade hur våra egna sessioner körs snarare än vad de producerar. Inga skript, inga externa verktyg, ren beteendeförändring: red-green-refactor tillämpas varje gång, en felsökningsdisciplin som inte låter Claude gissa en lösning innan buggen reproduceras. Dessa är det tydligaste fallet i vår katalog för en färdighet som förtjänar ankarstatus enbart baserat på utdata.

Memory Management (9.2/10) förtjänar sin plats genom att vara osynlig på bästa sätt: den förhindrar att kontext försvinner mellan sessioner utan att vi behöver hantera en anteckningsfil manuellt.

Lägg märke till vad som saknas. Vår katalog innehåller 73 färdigheter; 35 har ett rent godkänt omdöme. Vi använder kanske åtta av dessa 35 som äkta dagliga ankare. De andra 27 är bra, testade och ärliga om vad de gör, och de flesta befinner sig fortfarande i situationsspecifik eller experimentell status för oss, eftersom "testad och bra" och "hör hemma bland dina permanenta fem till åtta" är olika krav. En färdighet kan få 9/10 i recension och ändå vara fel att ha globalt installerad om du använder dess användningsfall två gånger per kvartal.

Den månatliga rensningsritualen

Portföljer driver iväg. En färdighet installerad för ett projekt överlever projektet. Ett experiment överlever sin tvåveckorsklocka eftersom att radera saker inte är någons favoritsyssla. Lösningen är en återkommande tio minuters genomgång, inte en engångsstädning.

En gång i månaden, gå igenom detta:

1. Lista vad som faktiskt är installerat. ls ~/.claude/skills/ och ls .claude/skills/ för alla projekt du befinner dig i. Om du inte känner igen ett mappnamn, är det redan ditt svar.
2. Fråga när varje senast aktiverades. Om du inte kan komma ihåg att ha använt den den senaste månaden, och det inte är ett ankare du använder i skurar (skattesäsong, kvartalsrapporter), är det en kandidat för rensning.
3. Kontrollera efter överlappning. Läs description-fältet för varje färdighet sida vid sida. Två som plausibelt skulle kunna svara på samma prompt är en kollision som väntar på att hända; se avsnittet ovan.
4. Bekräfta att projektavgränsade färdigheter faktiskt är projektavgränsade. Allt som är specifikt för en klient eller ett repo har inget att göra i din personliga mapp, där det följer med varje orelaterat projekt.
5. Radera, arkivera inte. En färdighet som ligger inaktiverad någonstans måste fortfarande inte förväxlas med en aktiv. Om den inte förtjänar sin plats, ta bort mappen.
6. Testa dina ankare igen. Be om något som varje ankare borde hantera, utan att nämna det, på samma sätt som vi testar triggers för katalogen. Om det inte aktiveras rent, är det troligt att något som lagts till sedan dess skuggar det.

Tio minuter, en gång i månaden, och portföljen förblir den storlek som är användbar istället för att driva mot den storlek som bara ackumuleras.

Kvalitet slår kvantitet

Detta är hela SkillProofs tes komprimerad till ett avsnitt, och det är värt att säga rakt ut här eftersom "hur många färdigheter" egentligen är en proxy för en annan fråga: vad är marginalvärdet av nästa du är på väg att installera?

Av de 45 färdigheter vi har genomfört fullständiga tester på, klarade 35 sig rent och 10 krävde extra installation för att fungera överhuvudtaget. Det är ingen kritik mot ekosystemet, formatet är medvetet öppet, vem som helst kan publicera utan granskning, vilket är precis varför det växte snabbt. Men det betyder också att den genomsnittliga färdigheten på GitHub är overifierad, och att installera tio medelmåttiga lägger inte ihop till en bra. Det lägger ihop till tio triggerbeskrivningar som konkurrerar med dina bra för samma matchning, tio inaktiva metadata-block vid varje förfrågan, och ett växande antal par som tyst kan störa varandra. Vi gick djupt in på de specifika felmönstren, vaga beskrivningar som aldrig triggar, utdata som inte är bättre än Claudes standard, saknade installationssteg, i varför hälften av Claude-färdigheterna inte fungerar.

Den praktiska versionen: innan du installerar något, fråga om det skulle överleva den två veckor långa experimentperioden, och om det gör något betydligt bättre än vad Claude skulle göra oombedd. Om du inte kan svara ja på båda, kostar det dig inte mycket att hoppa över det, men det hjälper dig inte heller. Våra effektivitetsrankningar sorterar testade färdigheter specifikt efter den utdata-över-baslinje-nivån, vilket är ett snabbare filter än att läsa tjugo READMEs själv.

Vanliga frågor

Finns det en hård gräns för hur många Claude-färdigheter jag kan installera?

Ingen teknisk gräns som vi har stött på i tester. Claude skannar varje färdighetsmapp den hittar och laddar all deras frontmatter vid sessionsstart, oavsett om det är 5 färdigheter eller 150. Gränsen som spelar roll är inte en vägg Claude upprätthåller, det är punkten där den ständigt aktiva metadata-skatten och de ökande oddsen för beskrivningsöverlappning börjar kosta mer än en ny färdighet tillför. Den punkten tenderar att ligga runt 30 till 40 installerade färdigheter för de flesta, långt före någon taknivå för formatet.

Gör inaktiva färdigheter Claude långsammare eller kostar de bara tokens?

Mest tokens och matchningsnoggrannhet, inte rå latens på något dramatiskt sätt. En inaktiv färdighets frontmatter finns i kontexten vid varje tur, vilket lägger till en liten, verklig kostnad som ackumuleras över en månad, och det är ytterligare en beskrivning Claude måste väga när den bestämmer vad som ska triggas. En handfull inaktiva färdigheter är genuint ofarliga. Fyrtio av dem är en annan historia, främst för att oddsen för att en föråldrad skuggar eller delvis matchar en förfrågan du bryr dig om ökar med antalet.

Hur vet jag om en färdighet jag installerat faktiskt används?

Be om något den borde hantera utan att nämna den, samma trigger-test vi kör för varje katalogpost. Om Claudes beteende synligt ändras, till exempel att den producerar en riktig .docx istället för inklistrad markdown, så aktiverades den. Om inget ändras, matchar antingen beskrivningen inte hur du faktiskt formulerar förfrågningar, eller så vinner en annan färdighet matchningen först. Vår guide för färdighet som inte triggar har den fullständiga sexpunkts-processen för att skilja dessa två åt.

Ska personliga och projektfärdigheter räknas mot samma gräns?

Behandla dem separat. Personliga färdigheter i ~/.claude/skills/ följer med varje projekt du rör vid, så de bör vara den korta ankarlistan du skulle sakna dagligen oavsett kontext. Projektfärdigheter i .claude/skills/ laddar bara sin frontmatter i sessioner inom det arkivet, så ett projekt kan rimligen bära fler situationsspecifika färdigheter utan att belasta ditt övriga arbete alls. Misstaget vi ser oftast är att placera klientspecifika eller repo-specifika färdigheter i den personliga mappen, där de belastar varje orelaterat projekt för alltid.

Vad är det snabbaste sättet att minska en övervuxen färdighetslista?

Kör den månatliga rensningsritualen en gång, omedelbart, istället för att vänta på nästa schemalagda genomgång. Lista allt installerat, ta bort allt du inte kan komma ihåg att ha aktiverat den senaste månaden som inte är ett känt "bursty" ankare, kontrollera de överlevande för beskrivningsöverlappning, och flytta allt klient- eller projektspecifikt ur din personliga mapp. De flesta övervuxna installationer minskar från över 30 färdigheter till under tio vid första genomgången, eftersom huvuddelen av listan är experiment som ingen hann ta bort.