Claude Code for team: En veiledning for ferdighetsstandardisering

Sett fem utviklere ned med Claude Code, og du får fem forskjellige verktøy. Én har en CLAUDE.md-fil med sterke meninger om testing. Én har aldri åpnet skills-katalogen. Én installerte en feilsøkingsferdighet fra en GitHub-tråd for tre uker siden og glemte å fortelle noen. To kjører standardinnstillingene, noe som betyr at Claude gjetter seg til deres konvensjoner på nytt hver økt.

Koden som havner i PR-køen din, gjenspeiler denne splittelsen. Noen diffs kommer med tester skrevet først og en ren commit-historikk. Andre kommer med en plausibel-utseende fiks for en feil ingen faktisk diagnostiserte. Samme modell, samme repo, samme uke, fem forskjellige utdatakvaliteter, og anmelderen fanger alt for hånd.

Dette er et personlig konfigurasjonsproblem kledd som et teamproblem. Individuelt er hver utviklers oppsett forsvarlig. Samlet sett har teamet ingen bunnlinje. Ingen ble enige om hva "bra" ser ut som når Claude gjør førsteutkastet, så ingen kan holde fast ved det. Denne artikkelen handler om løsningen: ferdigheter på prosjektnivå som lever i repoet i stedet for på laptoper, og styringen og utrullingen som får dem til å feste seg.

Løsningen er hvor ferdigheten lever, ikke hva den gjør

Claude Code leser ferdigheter fra to steder. Personlige ferdigheter ligger i ~/.claude/skills/, knyttet til én maskin, usynlige for teammedlemmer, borte i det øyeblikket utvikleren bytter laptop. Prosjektferdigheter ligger i .claude/skills/ inne i selve depotet, committet sammen med koden de styrer.

Den andre plasseringen er hele trikset. En prosjektferdighet er en fil i git: den får en diff, en anmelder, en commit-melding som forklarer hvorfor feilsøking bør følge en hypotese-først-løkke i stedet for det som føltes riktig den dagen. Når noen forbedrer ferdigheten, sendes forbedringen til alle ved neste pull, på samme måte som en linter-konfigurasjonsoppdatering gjør.

Sammenlign det med alternativet de fleste team først tyr til: en wiki-side med tittelen "Hvordan vi bruker Claude" som tre personer har lest og ingen håndhever. En wiki-side er råd. En prosjektferdighet er nærmere en avhengighet: Claude laster beskrivelsen ved starten av hver økt i det repoet og bruker den automatisk når en oppgave samsvarer, uten at noen trenger å huske at den eksisterer eller forklare den på nytt i prompten.

Det praktiske resultatet er at "teamets standard" slutter å være en setning i et onboarding-dokument og blir noe Claude faktisk gjør, identisk, enten det er teknisk leders økt eller den nyansattes økt på dag én.

Hva du bør standardisere først

Ikke prøv å kode hele ingeniørkulturen din inn i ferdigheter på én gang. Tre områder dekker det meste av variasjonen vi ser mellom utviklere i samme team, og hver har en testet, poengsatt ferdighet du kan peke på som et konkret eksempel på hva "bra" ser ut som, selv om du ender opp med å skrive din egen versjon tilpasset din stack.

En vurderingssjekkliste. Gapet mellom en vurdering som finner reelle feil og en vurdering som finner preferanser for variabelnavngivning er nøyaktig hva en god vurderingsferdighet lukker. Code Review Checklist scorer 8.4/10 i vår testing: på en 600-linjers PR fant den én reell off-by-one-feil og to død-kode-stier, og produserte null stil-bare pirk. Hvis hver anmelder får den kvaliteten på første gjennomgang før et menneske åpner diffen, bruker senioringeniører vurderingstid på arkitektur i stedet for å fange det en sjekkliste burde ha fanget.

TDD-disiplin. Test-Driven Development, fra Jesse Vincents Superpowers-samling, scorer 9.6/10. Vi kjørte den over en tre-funksjonsøkt, og Claude skrev den feilende testen først hver gang, og nektet å hoppe over syklusen selv med en snarvei tilgjengelig. Det er en ren atferdsferdighet, ingen skript eller eksterne verktøy, noe som gjør det til det enkleste å gjøre universelt: "skriv testen først" avhenger ikke av rammeverket ditt.

En feilsøkingsprotokoll. Systematic Debugging, også 9.6/10, erstatter standard "prøv en plausibel fiks"-løkke med reproduser, hypotesiser, instrumenter, verifiser. I vår test fant den rotårsaken til en race condition som allerede hadde overlevd tre gjetningsbaserte fikser. Dette er ferdigheten som betyr mest i et team, fordi gjetnings- og sjekk-feilsøking er der den høyeste variansen i utdata kommer fra, og en delt protokoll reduserer det gapet.

Tre ferdigheter. Ikke de tjue du vil bli fristet til å legge til når de tre første fungerer.

Hvem godkjenner en ny ferdighet

Når ferdigheter lever i repoet, må noen bestemme hva som legges til, og dette er den delen team hopper over til det biter dem. En ferdighet er instruksjoner Claude følger automatisk og noen ganger skript Claude vil utføre, noe som plasserer den i samme tillitskategori som en ny npm-pakke eller CI-handling. Ingen ville latt en utvikler legge til en vilkårlig avhengighet i package.json uten en PR-vurdering. En ferdighet fortjener den samme porten.

Mekanikken er enkel når du forplikter deg til å behandle det slik. En ny ferdighet kommer inn i repoet via en vanlig pull request, med samme grenbeskyttelse som enhver annen endring. Anmelderen leser hele SKILL.md, og sjekker for instruksjoner som er urelaterte til det angitte formålet og eventuelle nettverkskall hvis årsak ikke er åpenbar. Hvis ferdigheten inkluderer skript, åpner noen dem faktisk. Dette er den samme to-minutters revisjonen vi går gjennom i vår sikkerhetsguide.

Tildel en eier, én person i stedet for en komité, vanligvis den som foreslo ferdigheten eller en roterende teknisk leder, ansvarlig for at ferdighetens beskrivelse forblir nøyaktig og instruksjonene forblir oppdaterte. Når en ferdighets triggerfrase begynner å utløses på feil oppgaver, eller instruksjonene avviker fra arbeidsflyten den ble skrevet for, fikser eieren det eller trekker den.

Versjoner den som alt annet i repoet. Hvis en ferdighet endrer atferd betydelig, er det verdt en merknad i PR-beskrivelsen og, for alt med reell atferdsmessig vekt, en omtale i standup slik at folk vet at øktene deres vil oppføre seg annerledes fra i dag.

Onboarding er den virkelige killer-funksjonen

Her er delen som er lett å undervurdere når du presenterer dette for en skeptisk teamleder: en nyansatt kloner repoet på dag én og får den samme vurderingsdisiplinen, den samme test-først-vanen og den samme feilsøkingsprotokollen som personen som har vært der i to år. Ikke fordi de leste et 40-siders onboarding-dokument nøye. Fordi ferdighetene allerede ligger i .claude/skills/, og Claude plukker dem opp i det øyeblikket den nyansatte åpner prosjektet.

Tenk på hvordan onboarding vanligvis ser ut uten dette. En senioringeniør forklarer teamets testfilosofi i en 1:1, den nyansatte nikker, og tre uker senere har halvparten av det fordampet under tidsfrister, fordi vaner dannet under press som standard blir det som er raskest. Med prosjektferdigheter er disiplinen ikke et minne den nyansatte må opprettholde. Det er infrastruktur, håndhevet på deres første PR like mye som deres hundrede.

Det lukker også gapet på tvers av ansiennitetsnivåer. En juniorutviklers økt som kjører den samme feilsøkingsferdigheten som en staff-ingeniørs, produserer utdata på et mye nærmere kvalitetsnivå enn de to ville oppnådd uten assistanse, fordi mye av det som skiller en god feilsøkingsøkt fra en dårlig, er prosedyre, ikke erfaring.

Hvis du ikke har satt opp resten av Claude Code-laget ennå, er det verdt å gjøre det før eller sammen med dette. Vår oppsettguide dekker CLAUDE.md- og tillatelseslagene som prosjektferdigheter bygger på.

Hvordan vite om det faktisk fungerer

Motstå fristelsen til å finne opp et dashbord for dette. Signalet du ønsker, flyter allerede gjennom verktøy du har.

Overvåk volumet av PR-vurderingskommentarer og, viktigere, kommentartypen. Hvis anmeldere begynner å legge igjen færre "testet du dette" og "dette håndterer ikke null-tilfellet"-kommentarer og flere kommentarer om faktiske designavveininger, gjør vurderings- og TDD-ferdighetene jobben sin. Hvis antall kommentarer synker, men kommentarene som gjenstår fortsatt fanger opp korrekthetsfeil ferdigheten burde ha fanget, er ferdigheten ikke justert riktig ennå, ikke teamet.

Overvåk regresjonsraten. En feilsøkingsferdighet som håndhever hypotese-verifiseringsdisiplin bør bety færre "fiksete" feil som dukker opp igjen en uke senere, siden gjetnings- og sjekk-fikser er akkurat den typen som kommer tilbake. Dette er et tregere signal, vanligvis synlig over en måned eller to snarere enn en sprint, men det betyr mest for et team som har blitt brent av "fiksete" feil før.

Overvåk tid til første godkjenning på PR-er, behandle ett datapunkt som et hint og et vedvarende skifte over flere sprinter som et reelt signal. Og snakk med folk: om utviklere føler at Claudes utdata har blitt mer konsistente, om en nyansatt sier at kodebasen føltes lesbar raskere enn i deres forrige jobb, er verdt mer enn noe av det ovennevnte den første måneden.

En fire-ukers utrulling for et team på ti personer

Uke 1. Velg ett repo, ikke alle, og én ferdighet; vurderingssjekklisten er vanligvis den enkleste å selge fordi anmeldere ser fordelen umiddelbart. Legg den til .claude/skills/ via en vanlig PR. Få to eller tre frivillige til å bruke den på sine neste få vurderinger og rapporter tilbake i en kort tråd, ikke et møte.

Uke 2. Legg til TDD-ferdigheten i samme repo. Dette er den som møter mest motstand, siden den endrer hvordan folk skriver kode i stedet for hvordan de vurderer den. Forvent friksjon og behandle det som data. Hold feilsøkingsferdigheten ute for nå, og samle spesifikke klager ("den utløses på oppgaver der jeg ikke vil ha den") for å fikse ferdighetens beskrivelse før du prøver å fikse folks atferd.

Uke 3. Legg til feilsøkingsferdigheten. Nå har teamet en følelse av hvordan prosjektferdigheter oppfører seg, så dette tillegget bør gå raskere. Gjør en kort retro på de to ukene med data: endrer vurderingskommentarer seg, unngår noen stille ferdighetene, hvorfor. Juster triggerbeskrivelser hvis en ferdighet utløses for ofte eller ikke nok.

Uke 4. Rull ut de samme tre ferdighetene til resten av teamets repoer. Skriv en kort merknad i hver repos README som sier hva som er i .claude/skills/ og hvorfor, slik at den neste nyansatte ikke trenger å spørre. Sett godkjenningsprosessen fra seksjonen ovenfor som en stående regel, siden den virkelige testen på styring er hva som skjer med den fjerde ferdigheten noen foreslår, ikke de tre første.

Fire uker, tre ferdigheter, ett repo skalert til resten av organisasjonen. Motstå å komprimere dette; friksjonen i uke 2 er informasjon du ønsker før du kjører fem ferdigheter på tvers av ti repoer.

Plugin-alternativet for multi-repo organisasjoner

Prosjektferdigheter løser standardisering innenfor et repo, men de fleste ingeniørorganisasjoner er ikke ett repo. Hvis dine ti utviklere jobber på tvers av femten tjenester, blir det å kopiere .claude/skills/ inn i hver enkelt og holde dem synkronisert manuelt til sin egen vedlikeholdsjobb, den typen som stille slutter å skje etter andre kvartal.

Claude Code-plugins løser det laget. En plugin pakker et sett med ferdigheter, pluss kommandoer og annen konfigurasjon, inn i en installerbar enhet som ikke er knyttet til et enkelt repos git-historikk. I stedet for femten kopier av de samme tre ferdighetene som driver uavhengig, vedlikeholder organisasjonen én plugin, versjonert én gang, og hvert repo installerer fra den. En oppdatering av feilsøkingsferdigheten sprer seg deretter overalt hvor plugin-en er installert, i stedet for å kreve femten separate PR-er.

Dette er et steg opp i operasjonell kompleksitet, og det er ikke verdt å ta før du har følt smerten ved å holde flere repoer synkronisert. For et team på ti personer på ett eller to repoer, er prosjektferdighets-tilnærmingen i denne artikkelen det rette stoppepunktet. For en organisasjon som kjører de samme standardene på tvers av mange kodebaser, dekker vår pluginsguide pakkings- og distribusjonsmekanikken.

Feilmodusen: å pålegge tjue ferdigheter på dag én

Den vanligste måten dette går galt på er ikke teknisk, det er en utrullingsfeil. En teknisk leder leser om prosjektferdigheter, blir begeistret og committer tjue av dem på én ettermiddag: vurdering, TDD, feilsøking, pluss et dusin til for loggingskonvensjoner, commit-meldingsformat, API-design, tilgjengelighet, og hva enn annet som virket rimelig klokken 16.00 på en torsdag.

To ting bryter sammen. Først begynner overlappende beskrivelser å utløses på feil oppgaver, eller på hverandre, fordi ingen sjekket om ferdighet tre sin triggerfrase kolliderer med ferdighet elleve sin; disse konfliktene er en av de vanligste defektene vi ser i testing, og de blir verre etter hvert som antallet stiger. For det andre, og mer skadelig, utvikler teamet aldri tillit til ferdighetene, fordi en uke under tjue nye regler føles som en compliance-øvelse, og folk begynner å jobbe rundt Claude i stedet for med den.

Tre ferdigheter, tatt i bruk over en måned, med reell tilbakemelding som former hver enkelt før den neste kommer, bygger tillit som tjue ferdigheter sluppet på én gang aldri vil gjøre. Hvis teamet ditt fortsatt bestemmer seg for hvor de skal starte, er våre rangeringer av kodeferdigheter sortert etter testet poengsum, noe som er et rimelig filter for å velge den neste etter de tre første.

Ofte stilte spørsmål

Fungerer prosjektnivåferdigheter på samme måte som personlige?

Ja, formatet er identisk. Den eneste forskjellen er plasseringen: .claude/skills/ i repoet i stedet for ~/.claude/skills/ på en laptop. Claude Code laster begge på samme måte. Hvis en ferdighet eksisterer begge steder med samme navn, har prosjektversjonen vanligvis forrang for det repoet, noe som er nøyaktig den atferden du ønsker for en teamstandard.

Vil dette senke Claude for alle i teamet?

Knapt. Hver installerte ferdighet koster omtrent 100 tokens med alltid-lastet metadata. Tre prosjektferdigheter på tvers av et team legger til mindre stående kontekst enn en enkelt tilkoblet MCP-server vanligvis gjør. Den virkelige kostnaden ved å gjøre dette feil er ikke hastighet, det er triggerforvirring fra overlappende beskrivelser, og det er derfor utrullingsplanen ovenfor legger til ferdigheter én om gangen.

Hva om en utvikler er uenig i teamets TDD- eller feilsøkingsstandard?

Det er en samtale å ha før ferdigheten merges, i PR-vurderingen, samme sted du ville hatt den om en linter-regel. Når den er i repoet, gjelder den for alle, men "alle" bør bety at alle hadde en sjanse til å komme med innspill under vurderingen, ikke at én person bestemte seg ensidig og pushet til main.

Bør vi kreve ferdigheter eller la dem være valgfrie?

Prosjektferdigheter lastes automatisk for alle som har repoet, så det er ingen separat "krav"-trinn, de er bare en del av kodebasen. Det du kan gjøre valgfritt er bidrag: ikke alle utviklere trenger å foreslå nye ferdigheter, men hver utviklers økt kjører de som er merget. Behandle merge-beslutningen som porten.

Hvordan skiller dette seg fra å bare skrive en lang CLAUDE.md?

Lastingsatferd. CLAUDE.md lastes inn i hver økt uavhengig av hva utvikleren gjør den dagen, noe som gjør den riktig for fakta som alltid gjelder: byggekommandoer, arkitektur, navnekonvensjoner. En ferdighet lastes bare når en oppgave samsvarer med beskrivelsen, noe som gjør den riktig for en prosedyre du trenger noen ganger: hvordan teamet feilsøker, hvordan teamet vurderer. Hvis din CLAUDE.md har en lang seksjon som beskriver hvordan man skriver tester eller strukturerer en vurdering, ønsker den seksjonen å bli en ferdighet i stedet.