Hvor mange Claude-færdigheder bør du installere?

Færre end du tror. For de fleste, der udfører normalt arbejde i Claude Code, er det antal, der holder i månedsvis, et sted mellem fem og otte aktivt brugte færdigheder, ikke medregnet hvad der følger med i et plugin, du ikke valgte individuelt. Det er ikke et hårdt loft. Det er punktet, hvor den portefølje, du faktisk bruger, holder op med at vokse, uanset hvor mange flere du installerer.

Grunden til, at det er lavt, er ikke rod i en mappevisning. Hver færdighed, du installerer, uanset om du bruger den eller ej, placerer sin triggerbeskrivelse foran Claude ved hver anmodning, for evigt, og hver ekstra beskrivelse er endnu en ting, Claude skal ignorere korrekt. Efter et vist punkt tilføjer tilføjelse af færdigheder ikke kapacitet. Det tilføjer støj, som de gode færdigheder skal konkurrere imod.

Denne artikel er regnestykket bag det tal: hvad en installeret, men inaktiv færdighed koster dig, hvorfor to overlappende færdigheder er værre end en af dem alene, og den porteføljestruktur, vi selv bruger efter at have katalogiseret og testet 73 af dem.

Hvad en installeret færdighed faktisk koster dig

Færdigheder indlæses i to trin. Ved sessionsstart læser Claude kun frontmatter, den name og description, for hver færdighed, den kan finde, typisk 50 til 150 tokens hver. Disse metadata forbliver i kontekst under hele sessionen, uanset om færdigheden nogensinde aktiveres. Den fulde krop, de faktiske instruktioner, indlæses kun, når en anmodning matcher beskrivelsen. Det er progressiv afsløring, og det er grunden til, at færdigheder skalerer bedre end indsatte prompts. Vi dækkede mekanismen i hvad Claude-færdigheder er.

Den altid-aktive del er den del, folk glemmer at tælle. Lad os sige, at du har installeret 30 færdigheder med et gennemsnit på 100 tokens frontmatter hver: 3.000 tokens, der står foran hver besked, hver tur, hver session, uanset om nogen af dem er relevante. Ved 30 ture i en arbejdssession er det 90.000 tokens brugt på at genlæse en metadata-liste, før Claude gør noget, du bad om. Over 22 arbejdsdage, tæt på 2 millioner tokens om måneden i ren 'stå-og-vent'-afgift. Intet af det er dyrt i sig selv, et par cents til Sonnet-priser. Men det konkurrerer om plads i kontekstvinduet og akkumuleres med alt andet, der følger med: CLAUDE.md, MCP tool schemas, sessionshistorik. Vi lavede den fulde opdeling i reducering af Claude token-omkostninger.

Den større omkostning er ikke penge. Det er opmærksomhed. Claude beslutter, hvilken færdighed der skal indlæses ved at matche din anmodning mod en stak beskrivelser, og det match bliver mindre pålideligt, efterhånden som stakken vokser, og beskrivelser begynder at overlappe i ordforråd. En færdighed, du installerede i marts og ikke har brugt siden, er stadig i den stak, hver gang du beder om noget i april, og gør stille og roligt det korrekte match til én mulighed ud af 41 i stedet for én mulighed ud af 8.

Kollisionsproblemet: to færdigheder, én anmodning

Installer nok færdigheder, og til sidst vil to af dem beskrive den samme opgave med forskellige ord. Dette er ikke et hypotetisk problem. Vi stødte på det, da vi byggede vores egen testkatalog: to marketingpakker installeret side om side leverede begge en færdighed til outreach-tekst, cold-email og email-sequences, med beskrivelser, der overlappede nok til, at en enkelt "skriv mig en opfølgende e-mail"-prompt plausibelt kunne matche begge.

Når det sker, indtræffer en af tre ting, og ingen af dem meddeles dig. Claude vælger én, lydløst, baseret på hvilken beskrivelse der læses som et lidt bedre match for din præcise formulering, så den samme prompt stillet på to forskellige måder kan udløse to forskellige færdigheder. Eller en hård kollision på name-feltet betyder, at én færdighed skygger helt for den anden; den anden indlæses simpelthen aldrig, og du får ingen fejlmeddelelse om det. Eller, i værste fald, forsøger Claude at tilfredsstille begge delvise matches på én gang og producerer output, der er sammensat af to sæt instruktioner, der aldrig var designet til at samarbejde: din e-mail-færdighed og din tone-of-voice-færdighed, der begge forsøger at eje den samme sætning.

Løsningen er diagnostisk, ikke forebyggende, fordi du generelt ikke ved, at to færdigheder kolliderer, før de gør det. Vi skrev den fulde seks-punkts tjekliste for dette i Claude-færdighed udløses ikke, men den korte version specifikt for porteføljestørrelse: hvis du ikke kan forklare i én sætning, hvorfor færdighed A håndterer en anmodning i stedet for færdighed B, overlapper de for meget til at begge kan forblive installeret. Flet dem, slet den ene, eller omskriv den svagere beskrivelse for at udskære en smallere, ikke-overlappende del af opgaven. Antallet af kollisioner i en portefølje skalerer omtrent med kvadratet af dens størrelse, hvilket er den matematiske version af "hold det lille."

Portefølje-tilgangen: ankre, situationelle, eksperimenter

Når du accepterer, at hver installeret færdighed har en løbende omkostning, skifter spørgsmålet fra "skal jeg installere denne" til "hvilken kategori tilhører den." Vi sorterer vores egne i tre.

Ankre er de to til fem færdigheder, du ville bemærke inden for en dag, hvis de forsvandt. Dokumentgenerering, hvis du skriver rapporter ugentligt. En debugging-disciplin, hvis du skriver kode dagligt. En tone- eller redigeringsfærdighed, hvis dit job er ord. Disse får et permanent hjem i ~/.claude/skills/, tilgængelige i hvert projekt, og de er den eneste kategori, der er værd at installere på tro, før du har bevist, at triggeren virker specifikt for dig.

Situationelle er reelle og nyttige, men afgrænset til én kontekst: en migrations-tjekliste for én kodebase, en klients specifikke brand-stemme, en compliance-færdighed, som kun dit regulerede projekt har brug for. Disse hører hjemme i et projekts .claude/skills/-mappe, ikke din personlige. De rejser med repoet, de er synlige for teammedlemmer, der kloner det, og kritisk set konkurrerer deres beskrivelse kun om opmærksomhed inden for sessioner, hvor de faktisk er relevante. At installere en klientspecifik færdighed globalt betyder, at dens beskrivelse også følger med på hvert urelateret projekt, du rører ved.

Eksperimenter er alt, hvad du prøver, fordi en kollega anbefalede det, eller en katalogpost scorede godt. Giv disse en hård to-ugers tidsfrist fra installation. Hvis du ikke har brugt en uopfordret, naturligt, uden at gøre dig umage for at teste den, inden udgangen af to uger, så slet den. De fleste eksperimenter dumper denne test, og det er fint; det er det, prøveperioden er til for. Fejlen er ikke at prøve færdigheder, det er at lade utestede færdigheder stille og roligt opgradere til permanent-anker-status, blot fordi sletning af en mappe føles som at indrømme, at forsøget mislykkedes.

Denne struktur besvarer også spørgsmålet "hvor mange" mere nyttigt, end et enkelt tal gør. Det er ikke "installer 6 færdigheder i alt." Det er "hold dine ankre nede på det, du virkelig ville savne, hold situationelle afgrænset til, hvor de betyder noget, og sæt en udløbsdato på alt andet."

Hvad der overlevede på vores egen bænk

Vi tester hver færdighed i SkillProof-kataloget på en ren installation, før den får en dom, og separat bliver nogle af de testede færdigheder dem, vi faktisk bruger dagligt, måneder efter anmeldelsen blev offentliggjort. Den anden liste er kort, og den er informativ netop fordi den er kort.

DOCX (9.6/10) er den, vi hurtigst ville bemærke, hvis den forsvandt. Anthropic's egen referencefærdighed, og grunden er kedelig: vi producerer Word-dokumenter de fleste uger, og den skriver rigtige, med indholdsfortegnelser, sporede ændringer, intakte brevpapirer, i stedet for markdown, vi skulle omformatere i hånden.

Systematic Debugging (9.6/10) og Test-Driven Development (9.6/10), begge fra Superpowers-samlingen, er parret, der ændrede, hvordan vores egne sessioner kører, snarere end hvad de producerer. Ingen scripts, ingen eksterne værktøjer, ren adfærdsændring: red-green-refactor håndhævet hver gang, en debugging-disciplin, der ikke lader Claude gætte på en løsning, før fejlen er reproduceret. Disse er det tydeligste tilfælde i vores katalog for en færdighed, der opnår ankerstatus alene baseret på output.

Memory Management (9.2/10) fortjener sin plads ved at være usynlig på den bedste måde: den forhindrer kontekst i at forsvinde mellem sessioner, uden at vi manuelt skal administrere en notefil.

Bemærk, hvad der mangler. Vores katalog indeholder 73 færdigheder; 35 har en ren "pass"-dom. Vi bruger måske otte af disse 35 som ægte daglige ankre. De andre 27 er gode, testede og ærlige om, hvad de gør, og de fleste sidder stadig i situationel eller eksperimentel status for os, fordi "testet og god" og "hører hjemme i dine permanente fem til otte" er forskellige standarder. En færdighed kan score 9/10 i en anmeldelse og stadig være forkert at holde globalt installeret, hvis du kun rører dens brugssituation to gange i kvartalet.

Det månedlige oprydningsritual

Porteføljer driver. En færdighed installeret til ét projekt overlever projektet. Et eksperiment overlever sin to-ugers frist, fordi sletning af ting ikke er nogens foretrukne opgave. Løsningen er en tilbagevendende ti-minutters gennemgang, ikke en engangsoprydning.

En gang om måneden, gennemgå dette:

1. List hvad der faktisk er installeret. ls ~/.claude/skills/ og ls .claude/skills/ for ethvert projekt, du er i. Hvis du ikke genkender et mappenavn, er det allerede dit svar.
2. Spørg hvornår hver enkelt sidst blev aktiveret. Hvis du ikke kan huske at have brugt den inden for den sidste måned, og det ikke er et anker, du bruger i perioder (skattesæson, kvartalsrapporter), er det en kandidat til oprydning.
3. Tjek for overlap. Læs description-feltet for hver færdighed side om side. To, der plausibelt kunne besvare den samme prompt, er en kollision, der venter på at ske; se afsnittet ovenfor.
4. Bekræft at projekt-afgrænsede færdigheder faktisk er projekt-afgrænsede. Alt specifikt for en klient eller et repo har intet at gøre i din personlige mappe, hvor det følger med på hvert urelateret projekt.
5. Slet, arkiver ikke. En færdighed, der sidder deaktiveret et sted, skal stadig ikke forveksles med en aktiv. Hvis den ikke fortjener sin plads, fjern mappen.
6. Gentest dine ankre. Bed om noget, som hvert anker burde håndtere, uden at nævne det, på samme måde som vi tester triggere til kataloget. Hvis den ikke aktiveres rent, skygger noget, der er tilføjet siden, sandsynligvis for den.

Ti minutter, en gang om måneden, og porteføljen forbliver den størrelse, der er nyttig, i stedet for at drive mod den størrelse, der bare akkumuleres.

Kvalitet slår kvantitet

Dette er hele SkillProofs tese komprimeret i ét afsnit, og det er værd at sige det ligeud her, fordi "hvor mange færdigheder" i virkeligheden er en stedfortræder for et andet spørgsmål: hvad er den marginale værdi af den næste, du er ved at installere?

Af de 45 færdigheder, vi har gennemført fuld test af, bestod 35 rent, og 10 krævede ekstra opsætning for overhovedet at virke. Det er ikke en kritik af økosystemet; formatet er bevidst åbent, alle kan udgive uden en anmeldelsesport, hvilket netop er grunden til, at det voksede hurtigt. Men det betyder også, at den gennemsnitlige færdighed på GitHub er ubekræftet, og at installere ti middelmådige svarer ikke til én god. Det svarer til ti triggerbeskrivelser, der konkurrerer med dine gode om det samme match, ti inaktive metadata-blokke ved hver anmodning og et stigende antal par, der lydløst kan træde hinanden over tæerne. Vi dykkede ned i de specifikke fejltyper, vage beskrivelser, der aldrig udløses, output der ikke er bedre end Claudes standard, manglende opsætningstrin, i hvorfor halvdelen af Claude-færdigheder ikke virker.

Den praktiske version: før du installerer noget, spørg om det ville overleve den to-ugers eksperiment-frist, og om det gør noget markant bedre, end Claude ville gøre uopfordret. Hvis du ikke kan svare ja til begge, koster det dig ikke meget at springe det over, men det hjælper dig heller ikke. Vores effektivitetsrangeringer sorterer testede færdigheder specifikt efter den output-over-baseline-standard, hvilket er et hurtigere filter end at læse tyve READMEs selv.

Ofte stillede spørgsmål

Er der en hård grænse for, hvor mange Claude-færdigheder jeg kan installere?

Ingen teknisk grænse, som vi har ramt i test. Claude scanner hver færdighedsmappe, den finder, og indlæser al deres frontmatter ved sessionsstart, uanset om det er 5 færdigheder eller 150. Den grænse, der betyder noget, er ikke en mur, Claude håndhæver, det er punktet, hvor den altid-aktive metadata-afgift og de stigende chancer for beskrivelsesoverlap begynder at koste mere, end en ny færdighed tilføjer. Det punkt lander typisk omkring 30 til 40 installerede færdigheder for de fleste mennesker, langt før et loft på formatniveau.

Bremser inaktive færdigheder Claude, eller koster de bare tokens?

Mest tokens og matchningsnøjagtighed, ikke rå latenstid på nogen dramatisk måde. En inaktiv færdigheds frontmatter sidder i kontekst ved hver tur, hvilket tilføjer en lille, reel omkostning, der akkumuleres over en måned, og det er endnu en beskrivelse, Claude skal vurdere, når den beslutter, hvad den skal udløse. En håndfuld inaktive færdigheder er oprigtigt harmløse. Fyrre af dem er en anden historie, primært fordi sandsynligheden for, at en forældet skygger for eller delvist matcher en anmodning, du holder af, stiger med antallet.

Hvordan ved jeg, om en færdighed, jeg har installeret, faktisk bliver brugt?

Bed om noget, den burde håndtere, uden at nævne den, den samme trigger-test, vi kører for hver katalogpost. Hvis Claudes adfærd synligt ændrer sig, for eksempel, den producerer en rigtig .docx i stedet for indsat markdown, så blev den udløst. Hvis intet ændrer sig, matcher beskrivelsen enten ikke, hvordan du faktisk formulerer anmodninger, eller også vinder en anden færdighed matchet først. Vores vejledning til ikke-udløsende færdigheder har den fulde seks-punkts proces til at skelne de to fra hinanden.

Skal personlige og projektfærdigheder tælle med i samme grænse?

Behandl dem separat. Personlige færdigheder i ~/.claude/skills/ følger med på hvert projekt, du rører ved, så de bør være den korte ankerliste, du ville savne dagligt uanset kontekst. Projektfærdigheder i .claude/skills/ indlæser kun deres frontmatter i sessioner inden for det pågældende repository, så et projekt kan med rimelighed bære flere situationelle færdigheder uden at belaste dit andet arbejde overhovedet. Den fejl, vi ser mest, er at placere klientspecifikke eller repo-specifikke færdigheder i den personlige mappe, hvor de belaster hvert urelateret projekt for evigt.

Hvad er den hurtigste måde at reducere en overgroet færdighedsliste på?

Kør det månedlige oprydningsritual én gang, med det samme, i stedet for at vente på den næste planlagte gennemgang. List alt installeret, fjern alt, du ikke kan huske at have aktiveret inden for den sidste måned, som ikke er et kendt, periodevis brugt anker, tjek de overlevende for beskrivelsesoverlap, og flyt alt klient- eller projektspecifikt ud af din personlige mappe. De fleste overgroede opsætninger falder fra 30-plus færdigheder til under ti i den første gennemgang, fordi størstedelen af listen er eksperimenter, som ingen fik slettet.