Git-distribuerade skills: arv och team

En skill på en persons maskin är en personlig vana. I det ögonblick ett team förlitar sig på skills ändras frågan från "är det här en bra skill?" till "vems skill, vilken version, och vem får ändra den?" Det är styrning, och det börjar med hur skills distribueras.

Gapet du stänger

Föreställ dig ett team några månader in i att använda AI på allvar. En ingenjör använder skills noggrant, med skyddsräcken. En annan vibe-kodar en funktion med en skill de skrev på fem minuter. En tredje har kopplat ihop ett arbetsflöde ingen annan vet finns. Var för sig kan var och en vara okej. Tillsammans har organisationen ingen aning om vad dess standard är — och den får inte veta det förrän något ojämnt når produktion.

Det är det individuella adoptionsgapet, och det är just ett styrningsproblem. Svaret är inte mer entusiasm eller mer utbildning ensamt. Det är att göra skills delade, versionshanterade och granskningsbara — att förvandla privata vanor till en teamstandard du faktiskt kan se.

Distribution: committa den till repot

Den enklaste mekanismen är den mest välbekanta: en skill som committats till ett projekts skills-katalog följer med repot, under versionshantering, tillgänglig för alla som arbetar i det. Den är delad och versionerad genom exakt samma mekanism som din kod — pulla repot, få skillsen. Så här gör ett produktionsbibliotek: klona, bootstrappa, och teamets skills finns på plats.

Utöver git per projekt utökar två mekanismer räckvidden. Plugins och marketplaces låter dig paketera skills (tillsammans med relaterad verktygsuppsättning) och distribuera dem genom ett register, med versionslåsning och tillåt-/neka-listor — användbart när många team bör dela en uppsättning. Centralt hanterade inställningar trycker ut skills organisationsövergripande som framtvingad, skrivskyddad konfiguration. Vilken du väljer beror på skala; principen är konstant — en granskad källa, distribuerad, inte kopierad.

Arv: låt inte varje skill upprepa sig

Ett teambibliotek som kopierar samma standarder in i varje skill är en underhållsfälla som väntar på att slå igen. Mönstret som skalar är arv, och det har två delar.

En bas-skill håller de delade standarderna och vokabulären — prioriteringarna, statusarna, konventionerna som varje domän-skill bör följa. Domän-skills ärver den och lägger bara till det som är unikt för dem. Basen är bakgrundskunskap, inte ett kommando du anropar; den informerar de andra i tysthet.

Lagrad konfiguration hanterar de värden som skiljer sig per miljö: ett projektlager åsidosätter ett organisationslager, som faller tillbaka på bas-standarder — första träffen vinner. Organisationsspecifik konfiguration bor på sin egen plats och utökar den generiska kärnan i stället för att forka den. Och de lokala fakta som är specifika för en uppsättning stannar i CLAUDE.md som enda sanningskälla, medan skillsen bär generisk procedur.

Resultatet: en delad standard ändras på ett ställe, och varje skill håller fokus på det som gör den distinkt. Det är vad som gör att ett bibliotek överlever ett växande team.

Scope-företräde: vilken skill som faktiskt vinner

När samma skill kan finnas på flera nivåer behöver du veta vilken som gäller. Ordningen, högst till lägst: centralt hanterade inställningar, sedan användarnivå, sedan projektnivå, sedan plugin-tillhandahållna. Högre scope åsidosätter lägre.

Det här är inte en fotnot — det är styrningens hävstång. Det är så en organisation garanterar att dess granskade, standardversion av en skill är den som körs, oavsett vad en individ råkar ha lokalt. Utan att känna till företrädet är "vi har en standard-skill" en förhoppning. Med det är det möjligt att framtvinga.

Vad som kommer härnäst

Distribution gör en skill delad. Det gör den inte pålitlig. Nästa del tar upp att behandla skills som kod: granskning innan en skill kommer in i biblioteket, versionering, och tydligt ägarskap över vad var och en gör.

Nästa i den här serien: Del 2 — Versionering, granskning och revision