Claude Code för team: Standardisering av färdigheter

Sätt fem utvecklare med Claude Code och du får fem olika verktyg. En har en CLAUDE.md-fil med starka åsikter om testning. En har aldrig öppnat skills-katalogen. En installerade en felsökningsfärdighet från en GitHub-tråd för tre veckor sedan och glömde att berätta för någon. Två kör standardinställningarna, vilket innebär att Claude gissar deras konventioner på nytt varje session.

Koden som hamnar i din PR-kö återspeglar den uppdelningen. Vissa diffar kommer med tester skrivna först och en ren commit-historik. Andra kommer med en trovärdig fix för en bugg som ingen faktiskt diagnostiserat. Samma modell, samma repo, samma vecka, fem olika utdatakvaliteter, och granskaren fångar allt för hand.

Detta är ett problem med personlig konfiguration som döljer sig som ett teamproblem. Individuellt är varje utvecklares uppsättning försvarbar. Kollektivt har teamet ingen lägstanivå. Ingen kom överens om hur "bra" ser ut när Claude gör det första utkastet, så ingen kan hålla fast vid det. Denna text handlar om lösningen: färdigheter på projektnivå som lever i repo:t istället för på laptops, samt styrningen och utrullningen som får dem att fastna.

Lösningen är var färdigheten lever, inte vad den gör

Claude Code läser färdigheter från två platser. Personliga färdigheter finns i ~/.claude/skills/, kopplade till en maskin, osynliga för teammedlemmar, borta i samma ögonblick som utvecklaren byter laptop. Projektfärdigheter finns i .claude/skills/ inuti själva repository:t, committade tillsammans med koden de styr.

Den andra platsen är hela tricket. En projektfärdighet är en fil i git: den får en diff, en granskare, ett commit-meddelande som förklarar varför felsökning bör följa en hypotes-först-loop istället för vad som kändes rätt den dagen. När någon förbättrar färdigheten, skickas förbättringen till alla vid nästa pull, på samma sätt som en linter-konfigurationsuppdatering gör.

Jämför det med alternativet de flesta team först väljer: en wiki-sida med titeln "How we use Claude" som tre personer har läst och ingen upprätthåller. En wiki-sida är råd. En projektfärdighet är närmare en beroende: Claude laddar dess beskrivning i början av varje session i det repo:t och tillämpar den automatiskt när en uppgift matchar, utan att någon behöver komma ihåg att den existerar eller förklara den igen i prompt:en.

Det praktiska resultatet är att "vårt teams standard" slutar vara en mening i ett onboarding-dokument och blir något Claude faktiskt gör, identiskt, oavsett om det är tech-ledarens session eller den nyanställdes session på dag ett.

Vad man ska standardisera först

Försök inte att koda in hela din ingenjörskultur i färdigheter på en gång. Tre områden täcker det mesta av den variation vi ser mellan utvecklare i samma team, och var och en har en testad, poängsatt färdighet som du kan peka på som ett konkret exempel på hur "bra" ser ut, även om du slutar med att skriva din egen version anpassad till din stack.

En granskningschecklista. Gapet mellan en granskning som hittar verkliga buggar och en granskning som hittar preferenser för variabelnamngivning är exakt vad en bra granskningsfärdighet stänger. Code Review Checklist får 8.4/10 i våra tester: på en 600-raders PR hittade den ett verkligt off-by-one-fel och två dead-code-vägar, och producerade noll stil-relaterade anmärkningar. Om varje granskare får den kvaliteten på första genomgången innan en människa öppnar diff:en, spenderar seniora ingenjörer granskningstid på arkitektur istället för att fånga det en checklista borde ha fångat.

TDD-disciplin. Test-Driven Development, från Jesse Vincents Superpowers-samling, får 9.6/10. Vi körde den över en session med tre funktioner och Claude skrev det misslyckade testet först varje gång, och vägrade att hoppa över cykeln även med en genväg tillgänglig. Det är en ren beteendefärdighet, inga scripts eller externa verktyg, vilket gör den till det enklaste att göra universell: "skriv testet först" beror inte på ditt framework.

Ett felsökningsprotokoll. Systematic Debugging, också 9.6/10, ersätter standardloopen "prova en plausibel fix" med reproducera, hypotetisera, instrumentera, verifiera. I vårt test hittade den grundorsaken till en race condition som redan hade överlevt tre gissningsbaserade fixar. Detta är den färdighet som betyder mest i ett team, eftersom gissa-och-kontrollera-felsökning är där den högsta variansen i utdata kommer ifrån, och ett delat protokoll minskar det gapet.

Tre färdigheter. Inte de tjugo du kommer att frestas att lägga till när de första tre fungerar.

Vem godkänner en ny färdighet

När färdigheter väl finns i repo:t måste någon bestämma vad som läggs till, och detta är den del team hoppar över tills det biter dem. En färdighet är instruktioner som Claude följer automatiskt och ibland scripts som Claude kommer att exekvera, vilket placerar den i samma förtroendekategori som ett nytt npm-paket eller en CI-åtgärd. Ingen skulle låta en utvecklare lägga till ett godtyckligt beroende i package.json utan en PR-granskning. En färdighet förtjänar samma grind.

Mekaniken är enkel när du väl bestämmer dig för att behandla det på det sättet. En ny färdighet kommer in i repo:t via en vanlig pull request, med samma branch protection som vilken annan ändring som helst. Granskaren läser hela SKILL.md och kontrollerar efter instruktioner som är orelaterade till det angivna syftet och eventuella nätverksanrop vars anledning inte är uppenbar. Om färdigheten innehåller scripts, öppnar någon dem faktiskt. Detta är samma tvåminutersrevision vi går igenom i vår säkerhetsguide.

Tilldela en ägare, en person snarare än en kommitté, vanligtvis den som föreslog färdigheten eller en roterande tech lead, ansvarig för att färdighetens beskrivning förblir korrekt och dess instruktioner aktuella. När en färdighets trigger phrase börjar aktiveras på fel uppgifter, eller dess instruktioner avviker från det arbetsflöde den skrevs för, fixar den ägaren det eller tar bort den.

Versionshantera den som allt annat i repo:t. Om en färdighet ändrar beteende betydligt, är det värt en notering i PR-beskrivningen och, för allt med verklig beteendevikt, ett omnämnande i standup så att folk vet att deras sessioner kommer att agera annorlunda från och med idag.

Onboarding är den verkliga "killer feature"

Här är den del som är lätt att underskatta när du presenterar detta för en skeptisk team lead: en nyanställd klonar repo:t på dag ett och får samma granskningsdisciplin, samma test-först-vana och samma felsökningsprotokoll som den person som har varit där i två år. Inte för att de läste ett 40-sidigt onboarding-dokument noggrant. Utan för att färdigheterna redan finns i .claude/skills/, och Claude plockar upp dem i samma ögonblick som den nyanställde öppnar projektet.

Tänk på hur onboarding vanligtvis ser ut utan detta. En senior ingenjör förklarar teamets testfilosofi i ett 1:1-möte, den nyanställde nickar, och tre veckor senare har hälften av det försvunnit under tidsbrist, eftersom vanor som bildas under press tenderar att bli det som är snabbast. Med projektfärdigheter är disciplinen inte ett minne den nyanställde måste upprätthålla. Det är infrastruktur, som tillämpas på deras första PR lika mycket som på deras hundrade.

Det minskar också gapet mellan senioritetsnivåer. En junior utvecklares session som kör samma felsökningsfärdighet som en staff engineers producerar utdata på en mycket närmare kvalitetsnivå än de två skulle uppnå utan hjälp, eftersom mycket av det som skiljer en bra felsökningssession från en dålig är procedur, inte erfarenhet.

Om du inte har satt upp resten av Claude Code-lagret ännu, är det värt att göra före eller parallellt med detta. Vår installationsguide täcker CLAUDE.md och behörighetslagren som projektfärdigheter bygger på.

Hur man vet om det faktiskt fungerar

Motstå frestelsen att uppfinna en dashboard för detta. Signalen du vill ha flödar redan genom verktyg du har.

Titta på volymen av PR-granskningskommentarer och, viktigare, kommentarstypen. Om granskare börjar lämna färre kommentarer som "testade du detta" och "detta hanterar inte null-fallet" och fler kommentarer om faktiska designavvägningar, gör gransknings- och TDD-färdigheterna sitt jobb. Om antalet kommentarer minskar men de återstående kommentarerna fortfarande fångar korrekthetsbuggar som färdigheten borde ha fångat, är färdigheten inte rätt inställd ännu, inte teamet.

Titta på regressionsfrekvensen. En felsökningsfärdighet som upprätthåller hypotes-verifieringsdisciplin bör innebära färre "fixade" buggar som dyker upp igen en vecka senare, eftersom gissa-och-kontrollera-fixar är precis den typen som kommer tillbaka. Detta är en långsammare signal, vanligtvis synlig över en månad eller två snarare än en sprint, men den är viktigast för ett team som har bränts av "fixade" buggar tidigare.

Titta på tiden till första godkännande på PR:er, behandla en datapunkt som en ledtråd och en ihållande förändring över flera sprintar som en verklig signal. Och prata med folk: om utvecklare känner att Claudes utdata har blivit mer konsekvent, om en nyanställd säger att kodbasen kändes läsbar snabbare än deras förra jobb, är värt mer än något av ovanstående under den första månaden.

En fyraveckors utrullning för ett tiomannateam

Vecka 1. Välj ett repo, inte alla, och en färdighet; granskningschecklistan är vanligtvis den enklaste att sälja in eftersom granskare ser fördelen omedelbart. Lägg till den i .claude/skills/ via en vanlig PR. Få två eller tre frivilliga att använda den på sina nästa granskningar och rapportera tillbaka i en kort tråd, inte ett möte.

Vecka 2. Lägg till TDD-färdigheten till samma repo. Detta är den som möter mest motstånd, eftersom den ändrar hur folk skriver kod snarare än hur de granskar den. Förvänta dig friktion och behandla det som data. Håll felsökningsfärdigheten utanför för nu, och samla in specifika klagomål ("den aktiveras på uppgifter där jag inte vill att den ska göra det") för att fixa färdighetens beskrivning innan du försöker fixa människors beteende.

Vecka 3. Lägg till felsökningsfärdigheten. Nu har teamet en känsla för hur projektfärdigheter fungerar, så detta tillägg bör gå snabbare. Gör en kort retro på de två veckornas data: ändras granskningskommentarerna, undviker någon tyst färdigheterna, varför. Justera trigger-beskrivningar om en färdighet aktiveras för ofta eller inte tillräckligt.

Vecka 4. Rulla ut samma tre färdigheter till resten av teamets repos. Skriv en kort notering i varje repos README som säger vad som finns i .claude/skills/ och varför, så att nästa nyanställd inte behöver fråga. Sätt godkännandeprocessen från avsnittet ovan som en stående regel, eftersom det verkliga testet av styrning är vad som händer med den fjärde färdigheten någon föreslår, inte de första tre.

Fyra veckor, tre färdigheter, ett repo skalat till resten av organisationen. Motstå att komprimera detta; friktionen i vecka 2 är information du vill ha innan du kör fem färdigheter över tio repos.

Plugin-alternativet för organisationer med flera repos

Projektfärdigheter löser standardisering inom ett repo, men de flesta ingenjörsorganisationer är inte ett repo. Om dina tio utvecklare arbetar över femton tjänster, blir kopiering av .claude/skills/ till var och en och att hålla dem synkroniserade för hand ett eget underhållsjobb, den typ som tyst slutar hända efter andra kvartalet.

Claude Code plugins löser det lagret. Ett plugin paketerar en uppsättning färdigheter, plus commands och annan konfiguration, till en installerbar enhet som inte är kopplad till ett enskilt repos git-historik. Istället för femton kopior av samma tre färdigheter som driver isär oberoende, underhåller organisationen ett plugin, versionshanterat en gång, och varje repo installerar från det. En uppdatering av felsökningsfärdigheten sprids sedan överallt där plugin:et är installerat, istället för att kräva femton separata PR:er.

Detta är ett steg upp i operationell komplexitet, och det är inte värt att ta förrän du har känt smärtan av att hålla flera repos synkroniserade. För ett tiomannateam på ett eller två repos är projektfärdighetsmetoden i denna text rätt stoppunkt. För en organisation som kör samma standarder över många kodbaser, täcker vår plugins guide paketerings- och distributionsmekaniken.

Felläget: att påbjuda tjugo färdigheter på dag ett

Det vanligaste sättet detta går fel är inte tekniskt, det är ett utrullningsmisstag. En tech lead läser om projektfärdigheter, blir entusiastisk och committar tjugo av dem på en eftermiddag: granskning, TDD, felsökning, plus ett dussin till för loggningskonventioner, commit message-format, API-design, tillgänglighet och vad som helst annat som verkade rimligt klockan 16 på en torsdag.

Två saker går sönder. För det första börjar överlappande beskrivningar aktiveras på fel uppgifter, eller på varandra, eftersom ingen kontrollerade om färdighet tre:s trigger phrase kolliderar med färdighet elvas; dessa konflikter är en av de vanligaste defekterna vi ser i testning, och de blir värre när antalet ökar. För det andra, och mer skadligt, utvecklar teamet aldrig förtroende för färdigheterna, eftersom en vecka under tjugo nya regler känns som en efterlevnadsövning, och folk börjar arbeta runt Claude istället för med den.

Tre färdigheter, antagna under en månad, med verklig feedback som formar varje innan nästa anländer, bygger förtroende som tjugo färdigheter som släpps på en gång aldrig kommer att göra. Om ditt team fortfarande bestämmer var de ska börja, är våra rankningar av kodningsfärdigheter ordnade efter testad poäng, vilket är ett rimligt filter för att välja nästa efter dina första tre.

FAQ

Fungerar färdigheter på projektnivå på samma sätt som personliga?

Ja, formatet är identiskt. Den enda skillnaden är platsen: .claude/skills/ i repo:t istället för ~/.claude/skills/ på en laptop. Claude Code laddar båda på samma sätt. Om en färdighet finns på båda platserna med samma namn, tar projektversionen generellt företräde för det repo:t, vilket är exakt det beteende du vill ha för en teamstandard.

Kommer detta att sakta ner Claude för alla i teamet?

Knappt. Varje installerad färdighet kostar ungefär 100 tokens av alltid-laddad metadata. Tre projektfärdigheter över ett team lägger till mindre stående kontext än vad en enda ansluten MCP-server typiskt gör. Den verkliga kostnaden för att göra detta fel är inte hastighet, det är trigger-förvirring från överlappande beskrivningar, vilket är anledningen till att utrullningsplanen ovan lägger till färdigheter en i taget.

Vad händer om en utvecklare inte håller med teamets TDD- eller felsökningsstandard?

Det är en konversation att ha innan färdigheten slås ihop, i PR-granskningen, samma plats du skulle ha den om en linter-regel. När den väl är i repo:t gäller den för alla, men "alla" bör betyda att alla hade en chans att yttra sig under granskningen, inte att en person bestämde ensidigt och pushade till main.

Ska vi kräva färdigheter eller lämna dem valfria?

Projektfärdigheter laddas automatiskt för alla som har repo:t, så det finns inget separat "kräva"-steg, de är bara en del av kodbasen. Vad du kan göra valfritt är bidrag: inte varje utvecklare behöver föreslå nya färdigheter, men varje utvecklares session kör de som är sammanslagna. Behandla sammanslagningsbeslutet som grinden.

Hur skiljer sig detta från att bara skriva en lång CLAUDE.md?

Laddningsbeteende. CLAUDE.md laddas in i varje session oavsett vad utvecklaren gör den dagen, vilket gör den lämplig för fakta som alltid gäller: build commands, arkitektur, namngivningskonventioner. En färdighet laddas endast när en uppgift matchar dess beskrivning, vilket gör den lämplig för en procedur du ibland behöver: hur teamet felsöker, hur teamet granskar. Om din CLAUDE.md har ett långt avsnitt som beskriver hur man skriver tester eller strukturerar en granskning, vill det avsnittet istället bli en färdighet.