Produktions-skills: ett riktigt bibliotek

Allt hittills har varit princip. Den här delen är bevis. Mönstren som gör skills värda att förlita sig på är inte teoretiska — de är synliga i ett skill-bibliotek som körs varje dag i produktion. Vi går igenom det biblioteket (core-skills) och plockar ut mönstren som är värda att kopiera.

Poängen är inte de specifika skillsen. Det är vad som gör dem produktionsklass snarare än bara funktionella.

Enkelsyftes, och du kan bevisa det

Biblioteket är en uppsättning fokuserade skills — transkriptextraktion, livscykel för ändringsförfrågningar, standup-bearbetning, dashboard-generering, verktygen som underhåller biblioteket självt. Var och en gör ett jobb du kan ange i en mening. Ingen försöker vara en plattform.

Det är den första produktionsdisciplinen, och det är den från Del 1 gjord verklig: om du inte kan beskriva en skill i en mening och validera den på egen hand gör den för mycket. Ett bibliotek av enkelsyftes-skills är ett du kan lita på bit för bit. Ett bibliotek av vidlyftiga skills är ett du hoppas om.

Ett explicit "gör aldrig detta"-kontrakt

Den starkaste skillen i biblioteket — den som hanterar de andra skillsen, med kraften att hämta och länka och modifiera — inleds med en uppsättning säkerhetsregler som alltid framtvingas. Saker som: ta aldrig bort något utan att fråga, agera aldrig på ett smutsigt arbetsträd, framtvinga aldrig en destruktiv operation, hoppa över det som är onåbart snarare än att misslyckas högljutt.

Det här är ett mönster värt att kopiera direkt. En skill som kan ändra saker bör ange, i förväg och som stående instruktioner, de saker den aldrig får göra. Förbuden fångar de felsätt du redan känner till, varje gång skillen körs, utan att du behöver titta på. Ju mer kraft en skill har, desto mer behöver den ett explicit golv under sig.

Verifiera innan du muterar

Samma skill gör något subtilt innan den ändrar något: den kontrollerar om ändringen ens är säker att göra. Konkret, innan den hämtar uppdateringar verifierar den att commit-historiken är en ren fast-forward och tolkar resultatet precist — säkert, efter, eller onåbart — och fortsätter först därefter.

Generaliserat är mönstret verifiera innan du muterar: en produktions-skill bekräftar att tillståndet är det den förväntar sig innan den agerar, snarare än att agera och hoppas. Bygg in kontrollen som ett stående steg, inte som något du kommer ihåg att göra.

Självgranskning: bekräfta resultatet, anta det inte

Ändringsförfrågnings-skillen har en audit-operation som söker efter integritetsproblem, rapporterar dem efter allvarlighetsgrad, åtgärdar det den kan — och kör sedan om granskningen för att bekräfta att resultatet är rent. Den antar inte att åtgärden fungerade. Den kontrollerar.

Den omkörningen är idempotens i praktiken, och den är skillnaden mellan "skillen gjorde något" och "skillen verifierade utfallet." En produktions-skill som rör viktigt tillstånd bör kunna kontrollera sitt eget arbete och tala om för dig, ärligt, om resultatet är rent. Kombinerat med strikta invarianter — sekventiella identifierare aldrig överhoppade eller återanvända, konsekvent namngivning, en post per fil — polisar skillen sig själv så att du inte behöver.

Arv och konfiguration: upprepa inte standarderna

Biblioteket delar standarder — prioriteringar, statusar, mötesformat, en arkiveringspolicy — över många skills. Det kopierar dem inte in i var och en. En bas-skill håller den delade vokabulären, och domän-skillsen ärver den, och lägger bara till det som är unikt för dem. Bas-skillen är markerad som bakgrundskunskap snarare än ett kommando, så att den informerar de andra utan att vara något du anropar direkt.

Miljöspecifika värden ligger i lagrad konfiguration: ett projektlager åsidosätter ett organisationslager, som faller tillbaka på basstandarder. Och de lokala fakta som är specifika för en uppsättning stannar i CLAUDE.md, den enda sanningskällan, medan skillsen tillhandahåller generisk procedur. Resultatet är ett bibliotek där en delad standard ändras på exakt ett ställe, och varje skill anger bara det som gör den annorlunda.

När platt är rätt, och när man bryter ut filer

En rättvis fråga efter Del 3: den guiden sa att skjuta detaljer till separata referensfiler, men det här biblioteket håller varje skills instruktioner inuti sin egen kropp, platt, utan medföljande filer. Båda är korrekta, och försoningen är lärdomen.

Referensfiler är verktyget för när en skills material växer ur en mager kropp — en lång uppslagstabell, en stor exempelsamling, detaljerad dokumentation. Det här biblioteket behöver dem inte eftersom varje skill genuint är mager och enkelsyftes; instruktionerna får plats bekvämt i kroppen. Bedöm efter storlek och tydlighet, inte efter dogm. Håll det platt så länge det förblir magert; bryt ut referensfiler när det att förbli magert annars skulle tvinga dig att skära bort verkligt innehåll. Målet är detsamma hur som helst: en kropp som inte bär mer än den behöver.

Vad detta bevisar

Det här är påståendet "byggt i produktion" gjort påtagligt. Skillsen är inte demos. De körs, de bevakar sig själva, de granskar sitt eget arbete, och de ärver delade standarder i stället för att dubblera dem. Varje mönster här är ett du kan tillämpa på ditt eget bibliotek — och tillsammans är de vad som skiljer en skill som imponerar en gång från en du kan lämna över nycklarna till.

Vart detta går härnäst

Produktionsklassiga enskilda skills är en sak. Att köra ett delat skill-bibliotek över ett team — säkert, med versionshantering, granskning och tydligt ägarskap — är en annan. Det är Track 4: skills som styrning.

Detta avslutar Skills in Production. Fortsätt med Skills as Governance för att ta ett skill-bibliotek teamomfattande.