Versionering, granskning och revision
När en skill väl är delad har något stilla hänt: en bit text skriver nu arbete för hela ditt team. Det är en annan kategori av objekt än en personlig anteckning. Den förtjänar den disciplin du ger kod som körs i produktion — eftersom det i praktiken är vad den är.
Granska innan den landar
Den första regeln är den enklaste och den oftast hoppade över: en delad skill granskas innan den kommer in i biblioteket, inte efteråt. Att granska efteråt innebär att en brist redan formar arbete över hela teamet innan någon tittar på den.
Behandla skillen som du behandlar en pull request. Någon annan än författaren läser den. Triggar beskrivningen den vid rätt tidpunkter och endast dessa? Är instruktionerna stående regler, inte engångssteg? Bär den sina skyddsräcken — "gör aldrig detta", verifiera innan du muterar, självkontrollen? En ogranskad skill i ett delat bibliotek är en ogranskad standard, och kostnaden för en brist multipliceras med alla som använder den.
Versionera den på riktigt
I Track 2 var regeln "när du ändrar en skill ändrar du varje framtida resultat". I teamskala är det inte en varning — det är hela skälet till att versionering spelar roll. Redigera ett dokument och du har ändrat ett dokument. Ändra en delad skill och du har ändrat formen på allt den kommer att producera, för alla, från och med nu. Påverkanszonen är allt efterföljande arbete.
Så versionera skills medvetet. Meningsfulla versionsnummer, en changelog som säger vad som ändrades och varför, och disciplinen att behandla en skill-redigering som att ändra en standard snarare än att justera en fil. Ett produktionsbibliotek bär sin version explicit och registrerar ändringar — kopiera det. När någon frågar "ändrades status-rapport-skillen förra veckan?" ska svaret finnas i historiken, inte i någons minne.
Ägarskap: någon svarar för den
Varje delad skill behöver en ägare — en person som svarar för vad den gör och godkänner ändringar av den. Det är inte byråkrati; det är Grunden tillämpad på en delad artefakt. Personligt ansvar avdunstar inte för att en skill nu används av tio personer. Det koncentreras: ägaren är ansvarig för den standard skillen kodifierar, på samma sätt som en författare är ansvarig för kod de mergar.
Utan en ägare driver en delad skill — patchad av vem som helst, betrodd av alla, ansvarig inför ingen. Med en ägare finns det en person att granska mot, att fråga, och som håller linjen för kvalitet.
Granska vad den kan nå
Den granskning som betyder mest handlar inte om prosa — den handlar om räckvidd. En skill som bara producerar text är relativt lågrisk. En skill kopplad till dina verktyg och data kan ändra poster, anropa tjänster, läsa känslig information. Det är där revisionen hör hemma: vad kan den här skillen komma åt, och vad kan den göra?
Låna produktionsmönstren direkt. En skill med räckvidd bör bära sitt explicita "gör aldrig detta"-kontrakt och sina verifiera innan du muterar-kontroller, och de blir styrningsprimitiver — det som en granskare bekräftar finns på plats innan skillen tillåts nära verkliga system. Skills med förmågan att ändra saker är privilegierad automatisering, och de får den granskning privilegierad automatisering får.
Vad som kommer härnäst
Granskning, versionering, ägarskap och revision styr ett skill-bibliotek inom ett team. Den sista delen skalar upp det: bibliotek på organisationsnivå, åtkomstkontroll, framtvingade standarder, och punkten där en skill slutar vara en bekvämlighet och blir policy som organisationen är ansvarig för.
Nästa i den här serien: Del 3 — Organisationens skill-bibliotek och styrning