Hvor mange Claude-ferdigheter bør du installere?

Færre enn du tror. For de fleste som utfører vanlig arbeid i Claude Code, er antallet som holder over måneder et sted mellom fem og åtte aktivt brukte ferdigheter, ikke medregnet det som følger med i en plugin du ikke valgte individuelt. Dette er ikke et hardt tak. Det er punktet der porteføljen du faktisk bruker slutter å vokse, uansett hvor mange flere du installerer.

Grunnen til at det er lavt, er ikke rot i en mappeoversikt. Hver ferdighet du installerer, enten du bruker den eller ikke, plasserer sin triggerbeskrivelse foran Claude ved hver forespørsel, for alltid, og hver ekstra beskrivelse er enda en ting Claude må ignorere korrekt. Etter et visst punkt legger ikke det å legge til ferdigheter til kapasitet. Det legger til støy som de gode ferdighetene må konkurrere mot.

Denne artikkelen er regnestykket bak det tallet: hva en installert, men inaktiv ferdighet koster deg, hvorfor to overlappende ferdigheter er verre enn noen av dem alene, og porteføljestrukturen vi selv bruker etter å ha katalogisert og testet 73 av dem.

Hva en installert ferdighet faktisk koster deg

Ferdigheter lastes inn i to trinn. Ved sesjonsstart leser Claude kun frontmatter, name og description, for hver ferdighet den finner, typisk 50 til 150 tokens hver. Disse metadataene ligger i kontekst for hele sesjonen uavhengig av om ferdigheten noensinne utløses. Hele kroppen, de faktiske instruksjonene, lastes kun når en forespørsel samsvarer med beskrivelsen. Dette er progressiv avsløring, og det er grunnen til at ferdigheter skalerer bedre enn innlimte prompter. Vi dekket mekanismen i hva Claude-ferdigheter er.

Den alltid-på-delen er den delen folk glemmer å regne med. Si at du har installert 30 ferdigheter med et gjennomsnitt på 100 tokens frontmatter hver: 3 000 tokens som står foran hver melding, hver tur, hver sesjon, uavhengig av om noen av dem er relevante. Ved 30 turer i en arbeidsøkt er det 90 000 tokens brukt på å lese en metadata-liste på nytt før Claude gjør noe du ba om. Over 22 arbeidsdager, nesten 2 millioner tokens i måneden i ren 'stå-og-vent'-avgift. Ingen av dem er dyre i seg selv, noen få cent til Sonnet-priser. Men det konkurrerer om plass i kontekstvinduet og forsterkes med alt annet som følger med: CLAUDE.md, MCP tool schemas, sesjonshistorikk. Vi gjorde den fulle gjennomgangen i kutte Claude token-kostnader.

Den større kostnaden er ikke penger. Det er oppmerksomhet. Claude bestemmer hvilken ferdighet som skal lastes ved å matche forespørselen din mot en stabel med beskrivelser, og den matchen blir mindre pålitelig etter hvert som stabelen vokser og beskrivelsene begynner å overlappe i vokabular. En ferdighet du installerte i mars og ikke har brukt siden, er fortsatt i den stabelen hver gang du spør om noe i april, og gjør stille den korrekte matchen til ett alternativ av 41 i stedet for ett alternativ av 8.

Kollisjonsproblemet: to ferdigheter, én forespørsel

Installer nok ferdigheter, og til slutt vil to av dem beskrive den samme jobben med forskjellige ord. Dette er ikke hypotetisk. Vi opplevde det da vi bygget vår egen testkatalog: to markedsføringspakker installert side om side leverte begge en ferdighet for utgående kommunikasjon, cold-email og email-sequences, med beskrivelser som overlappet nok til at en enkelt "write me a follow-up email"-prompt plausibelt kunne matche begge.

Når det skjer, inntreffer en av tre ting, og ingen av dem blir annonsert for deg. Claude velger én, stille, basert på hvilken beskrivelse som fremstår som en litt bedre match for din eksakte formulering, slik at den samme prompten stilt på to forskjellige måter kan utløse to forskjellige ferdigheter. Eller en hard kollisjon på name-feltet betyr at én ferdighet overskygger den andre fullstendig; den andre lastes rett og slett aldri, og du får ingen feilmelding som forteller deg det. Eller, i verste fall, prøver Claude å tilfredsstille begge delvise matcher samtidig og produserer utdata som er satt sammen fra to sett med instruksjoner som aldri var designet for å samarbeide: din e-postferdighet og din tone-of-voice-ferdighet som begge prøver å eie den samme setningen.

Løsningen er diagnostisk, ikke forebyggende, fordi du vanligvis ikke vet at to ferdigheter kolliderer før de gjør det. Vi skrev den fulle seks-punkts sjekklisten for dette i Claude-ferdighet utløses ikke, men den korte versjonen for porteføljestørrelse spesifikt: hvis du ikke kan forklare med én setning hvorfor skill A håndterer en forespørsel i stedet for skill B, overlapper de for mye til å begge forbli installert. Slå dem sammen, slett den ene, eller skriv om den svakere beskrivelsen for å skjære ut en smalere, ikke-overlappende del av jobben. Antall kollisjoner i en portefølje skalerer omtrent med kvadratet av størrelsen, som er den matematiske versjonen av "keep it small."

Portefølje-tilnærmingen: ankere, situasjonelle, eksperimenter

Når du aksepterer at hver installert ferdighet har en løpende kostnad, skifter spørsmålet fra "bør jeg installere denne" til "hvilken kategori tilhører den". Vi sorterer våre egne i tre.

Ankere er de to til fem ferdighetene du ville merke innen en dag hvis de forsvant. Dokumentgenerering hvis du skriver rapporter ukentlig. En feilsøkingsdisiplin hvis du skriver kode daglig. En tone- eller redigeringsferdighet hvis jobben din er ord. Disse får et permanent hjem i ~/.claude/skills/, tilgjengelig i hvert prosjekt, og de er den eneste kategorien verdt å installere på tro og ære før du har bevist at triggeren fungerer spesifikt for deg.

Situasjonelle er reelle og nyttige, men avgrenset til én kontekst: en migreringssjekkliste for én kodebase, en klients spesifikke merkevarestemme, en compliance-ferdighet som bare ditt regulerte prosjekt trenger. Disse hører hjemme i et prosjekts .claude/skills/-mappe, ikke din personlige. De reiser med repoet, de er synlige for teammedlemmer som kloner det, og kritisk, deres beskrivelse konkurrerer bare om oppmerksomhet i sesjoner der de faktisk er relevante. Å installere en klientspesifikk ferdighet globalt betyr at beskrivelsen følger med på hvert urelaterte prosjekt du berører også.

Eksperimenter er alt du prøver fordi en kollega anbefalte det eller en katalogoppføring scoret bra. Gi disse en hard to-ukers klokke fra installasjon. Hvis du ikke har brukt en upromptet, naturlig, uten å gå ut av din vei for å teste den, innen utgangen av to uker, slett den. De fleste eksperimenter feiler denne testen, og det er greit; det er det prøveperioden er for. Feilen er ikke å prøve ferdigheter, det er å la utestede ferdigheter stille og rolig gradere til permanent ankerstatus bare fordi det å slette en mappe føles som å innrømme at prøven mislyktes.

Denne strukturen svarer også på "hvor mange"-spørsmålet mer nyttig enn et enkelt tall gjør. Det er ikke "installer 6 ferdigheter totalt." Det er "hold ankrene dine nede til det du genuint ville savne, hold situasjonelle avgrenset til der de betyr noe, og sett en utløpsdato på alt annet."

Hva som overlevde på vår egen benk

Vi tester hver ferdighet i SkillProof-katalogen på en ren installasjon før den får en dom, og separat blir noen av de testede ferdighetene de vi faktisk bruker daglig, måneder etter at anmeldelsen ble publisert. Den andre listen er kort, og den er informativ nettopp fordi den er kort.

DOCX (9.6/10) er den vi ville merke raskest hvis den forsvant. Anthropic sin egen referanseferdighet, og grunnen er kjedelig: vi produserer Word-dokumenter de fleste uker, og den skriver ekte dokumenter, innholdsfortegnelser, sporede endringer, brevpapir intakt, i stedet for markdown vi måtte formatere manuelt.

Systematic Debugging (9.6/10) og Test-Driven Development (9.6/10), begge fra Superpowers-samlingen, er paret som endret hvordan våre egne sesjoner kjører, snarere enn hva de produserer. Ingen skript, ingen eksterne verktøy, ren atferdsendring: rød-grønn-refaktor håndheves hver gang, en feilsøkingsdisiplin som ikke lar Claude gjette på en løsning før feilen er reprodusert. Dette er det klareste tilfellet i vår katalog for en ferdighet som oppnår ankerstatus basert på utdata alene.

Memory Management (9.2/10) fortjener sin plass ved å være usynlig på den beste måten: den forhindrer at kontekst fordamper mellom sesjoner uten at vi manuelt må administrere en notatfil.

Legg merke til hva som mangler. Vår katalog inneholder 73 ferdigheter; 35 har en ren 'pass'-dom. Vi bruker kanskje åtte av disse 35 som ekte daglige ankere. De andre 27 er gode, testede og ærlige om hva de gjør, og de fleste sitter fortsatt i situasjonell eller eksperimentell status for oss, fordi "testet og god" og "hører hjemme i dine permanente fem til åtte" er forskjellige standarder. En ferdighet kan score 9/10 i anmeldelse og likevel være feil å holde globalt installert hvis du berører bruksområdet to ganger i kvartalet.

Det månedlige beskjæringsritualet

Porteføljer driver. En ferdighet installert for ett prosjekt overlever prosjektet. Et eksperiment overlever sin to-ukers klokke fordi det å slette ting ikke er noens favorittoppgave. Løsningen er en tilbakevendende ti-minutters gjennomgang, ikke en engangsrydding.

En gang i måneden, kjør gjennom dette:

1. List opp hva som faktisk er installert. ls ~/.claude/skills/ og ls .claude/skills/ for ethvert prosjekt du er i. Hvis du ikke gjenkjenner et mappenavn, er det allerede svaret ditt.
2. Spør når hver enkelt sist ble utløst. Hvis du ikke kan huske å ha brukt den den siste måneden, og det ikke er et anker du bruker i perioder (skattesesong, kvartalsrapporter), er det en kandidat for beskjæring.
3. Sjekk for overlapping. Les description-feltet for hver ferdighet side om side. To som plausibelt kunne svare på den samme prompten er en kollisjon som venter på å skje; se avsnittet ovenfor.
4. Bekreft at prosjektspesifikke ferdigheter faktisk er prosjektspesifikke. Alt som er spesifikt for én klient eller ett repo har ingenting å gjøre i din personlige mappe, og følger med på hvert urelaterte prosjekt.
5. Slett, ikke arkiver. En ferdighet som er deaktivert et sted, må fortsatt ikke forveksles med en aktiv. Hvis den ikke fortjener sin plass, fjern mappen.
6. Test ankrene dine på nytt. Be om noe hvert anker skal håndtere, uten å navngi det, slik vi tester triggere for katalogen. Hvis det ikke utløses rent, er det sannsynligvis noe som er lagt til siden som overskygger det.

Ti minutter, en gang i måneden, og porteføljen holder seg til en størrelse som er nyttig i stedet for å drive mot en størrelse som bare akkumuleres.

Kvalitet slår kvantitet

Dette er hele tesen til SkillProof komprimert til ett avsnitt, og det er verdt å si det tydelig her fordi "hvor mange ferdigheter" egentlig er en stedfortreder for et annet spørsmål: hva er den marginale verdien av den neste du er i ferd med å installere?

Av de 45 ferdighetene vi har kjørt gjennom full testing, besto 35 rent og 10 trengte ekstra oppsett for å fungere i det hele tatt. Det er ikke en kritikk av økosystemet, formatet er bevisst åpent, hvem som helst kan publisere uten en gjennomgangsport, noe som er nettopp grunnen til at det vokste raskt. Men det betyr også at den gjennomsnittlige ferdigheten på GitHub er uverifisert, og å installere ti middelmådige legger ikke opp til én god. Det legger opp til ti triggerbeskrivelser som konkurrerer med dine gode om den samme matchen, ti inaktive metadata-blokker ved hver forespørsel, og et økende antall par som stille kan tråkke på hverandre. Vi gikk dypt inn i de spesifikke feilmønstrene, vage beskrivelser som aldri utløses, utdata som ikke er bedre enn Claudes standard, manglende oppsettstrinn, i hvorfor halvparten av Claude-ferdighetene ikke fungerer.

Den praktiske versjonen: før du installerer noe, spør om det ville overleve den to-ukers eksperimentklokken, og om det gjør noe meningsfullt bedre enn Claude ville gjort upromptet. Hvis du ikke kan svare ja på begge, koster det deg ikke mye å hoppe over det, men det hjelper deg heller ikke. Våre effektivitetsrangeringer sorterer testede ferdigheter spesifikt etter den utdata-over-baseline-standarden, som er et raskere filter enn å lese tjue READMEs selv.

FAQ

Er det en hard grense for hvor mange Claude-ferdigheter jeg kan installere?

Ingen teknisk grense vi har støtt på i testing. Claude skanner hver ferdighetsmappe den finner og laster all deres frontmatter ved sesjonsstart, enten det er 5 ferdigheter eller 150. Grensen som betyr noe er ikke en vegg Claude håndhever, det er punktet der den alltid-på metadata-avgiften og de økende sjansene for beskrivelsesoverlapping begynner å koste mer enn en ny ferdighet legger til. Det punktet pleier å ligge rundt 30 til 40 installerte ferdigheter for de fleste, godt før noe formatnivåtak.

Sakker inaktive ferdigheter Claude ned eller koster de bare tokens?

Mest tokens og matchingsnøyaktighet, ikke rå latens på noen dramatisk måte. En inaktiv ferdighets frontmatter ligger i kontekst ved hver tur, noe som legger til en liten, reell kostnad som akkumuleres over en måned, og det er enda en beskrivelse Claude må vurdere når den bestemmer hva som skal utløses. En håndfull inaktive ferdigheter er genuint ufarlig. Førti av dem er en annen historie, hovedsakelig fordi sjansene for at en utdatert overskygger eller delvis matcher en forespørsel du bryr deg om, øker med antallet.

Hvordan vet jeg om en ferdighet jeg har installert faktisk blir brukt?

Be om noe den skal håndtere uten å navngi den, den samme triggertesten vi kjører for hver katalogoppføring. Hvis Claudes oppførsel synlig endres, for eksempel at den produserer en ekte .docx i stedet for innlimt markdown, ble den utløst. Hvis ingenting endres, enten samsvarer ikke beskrivelsen med hvordan du faktisk formulerer forespørsler, eller en annen ferdighet vinner matchen først. Vår guide for ferdighet som ikke utløses har den fulle seks-sjekk-prosessen for å skille disse to fra hverandre.

Bør personlige og prosjektferdigheter telle mot den samme grensen?

Behandle dem separat. Personlige ferdigheter i ~/.claude/skills/ følger med på hvert prosjekt du berører, så de bør være den korte ankerlisten du ville savnet daglig uavhengig av kontekst. Prosjektferdigheter i .claude/skills/ laster kun sin frontmatter i sesjoner innenfor det depotet, så et prosjekt kan rimeligvis bære flere situasjonelle ferdigheter uten å belaste ditt andre arbeid i det hele tatt. Feilen vi ser mest er å plassere klientspesifikke eller repo-spesifikke ferdigheter i den personlige mappen, hvor de belaster hvert urelaterte prosjekt for alltid.

Hva er den raskeste måten å redusere en overgrodd ferdighetsliste på?

Kjør det månedlige beskjæringsritualet én gang, umiddelbart, i stedet for å vente på neste planlagte gjennomgang. List opp alt som er installert, fjern alt du ikke kan huske å ha utløst den siste måneden som ikke er et kjent, periodisk anker, sjekk de overlevende for beskrivelsesoverlapping, og flytt alt klient- eller prosjektspesifikt ut av din personlige mappe. De fleste overgrodde oppsett faller fra over 30 ferdigheter til under ti i første omgang, fordi hoveddelen av listen er eksperimenter ingen fikk slettet.