När en Skill blir för stor: så modulariserar jag den

En Skill brukar inte bli dålig för att den saknar instruktioner. Den blir dålig när för många olika typer av instruktioner samlas i samma fil. När SKILL.md växer börjar triggerlogik, domänkunskap, exempel, säkerhetsregler och procedurer konkurrera om samma kontext. Min lösning är inte att dela filen på mitten godtyckligt, utan att modularisera efter vilket innehåll som måste vara aktivt vid vilket beslut.

Tecknet på att Skillen är för stor

Jag reagerar när SKILL.md börjar fungera som både manual, databas, policy och cookbook. Andra signaler är att modellen måste läsa långa delar som inte är relevanta för den aktuella uppgiften eller att samma regel förklaras på flera ställen. Det praktiska värdet i att reagera tidigt är spårbarhet: jag vill kunna återvända till beslutet senare och se om systemet fortfarande beter sig som avsett, i stället för att förlita mig på minnet av varför en regel lades till.

SKILL.md ska vara control plane

Entrypointen beskriver arbetsflöde, invarianta regler och hur referenser väljs. Djupa tabeller, långa exempel, domänvarianter och schemas flyttas ut. Då blir huvudfilen lättare att auditera. Jag brukar testa principen med ett negativt fall, inte bara ett lyckat exempel: om flödet ändå passerar när förutsättningen saknas är kontrollen för svag och behöver flyttas uppströms eller göras deterministisk.

Dela efter beslutspunkt, inte filstorlek

Jag skapar referenser för sådant som bara behövs under en viss gren: research-policy, SEO-review, juridisk variant eller API-schema. En god modul motsvarar ett tydligt beslut i workflowet. Det här påverkar också kostnaden — när processen är explicit kan enklare steg köras med enklare verktyg eller modeller och de dyra bedömningarna reserveras för de delar där osäkerheten faktiskt finns.

Scripts för determinism

Om instruktionen beskriver samma mekaniska operation varje gång — validera CSV, skapa hash, kontrollera required fields — flyttar jag den till kod. Skillen behåller när scriptet ska köras och vad resultaten betyder. Det viktiga är att inte göra regeln bredare än problemet. Jag dokumenterar därför scope och undantag samtidigt som jag dokumenterar huvudregeln; annars tenderar en lokal lösning att bli global policy av gammal vana.

Undvik referenslabyrinter

Moduler hjälper bara om modellen kan hitta dem. Jag håller referenser en nivå från SKILL.md och låter huvudfilen säga exakt när varje fil ska läsas. Djupa korslänkar skapar dold kontextkostnad. I ett agentflöde blir ägarskapet centralt: nästa steg ska inte behöva tolka en lång chattlogg för att förstå vad som är godkänt, det ska få ett litet kontrakt med input, evidens, beslut och återstående osäkerhet.

När flera Skills slår en stor Skill

Modularisering behöver inte stanna vid referensfiler inom samma Skill. När en Skill växer till hundratals regler frågar jag om den egentligen innehåller flera olika kompetenser. En mega-Skill kan kännas bekväm — allt finns på ett ställe — men den gör triggerlogik, kontext och testning svårare, och jag föredrar då composition: separata Skills för till exempel research policy, source quality, editorial style och internal linking, där varje agent laddar bara det som behövs för sitt steg. Gränsen går ändå vid gemensamt kontrakt, inte vid filstorlek — om två delar alltid måste användas tillsammans och deras regler inte är meningsfulla separat är en gemensam Skill sannolikt bättre. Min tumregel för när uppdelning i flera Skills är motiverad:

text

separat trigger + separat eval + separat output contract→ stark kandidat för separat Skill

Delade regler behöver en ägare

En säkerhetsregel eller output-standard ska ha ett canonical hem. Kopior i fem referenser driver isär över tid. Övriga filer pekar tillbaka till ägaren i stället för att duplicera texten. Det här är också där jag försöker skilja demo från drift: i en demo räcker det ofta att output ser rimligt ut, men i drift måste samma resultat gå att förklara, validera och vid behov stoppa utan att en människa läser hela resonemanget.

Testa context footprint

Jag testar inte bara om svaret blir rätt utan hur mycket material som måste laddas för en enkel uppgift. En Skill som kräver hela kunskapsbasen för varje anrop fungerar sämre i långa agent-sessioner. En bieffekt är att förbättringar blir enklare att mäta: när samma testfall och artefakter finns kvar kan jag ändra en komponent i taget och se om kvaliteten faktiskt gick upp eller om jag bara flyttade felet.

Min modulariseringsregel

Flytta ut innehåll när det är villkorligt, stort, domänspecifikt eller deterministiskt. Behåll i SKILL.md det som måste vara sant vid nästan varje körning. Jag vill dessutom att en framtida person ska kunna ta över: om metoden bara fungerar när skaparen minns alla muntliga undantag är den inte riktigt produktionsmässig, oavsett hur bra modellen är i dag.

Ett litet exekverbart kontrakt

Jag försöker alltid kondensera metoden till ett kontrakt som går att implementera eller granska, enligt samma mönster som checklistan för prototyp-till-produktion i Min checklista innan ett AI-workflow får gå från prototyp till produktion.

Före och efter: från monolit till laddningsbar struktur

En monolit kan exempelvis innehålla researchregler, outputmall, säkerhetspolicy, fem domänvarianter och tre API-schemas i samma SKILL.md. Jag skulle i stället behålla workflowet och invarianta gates i huvudfilen och skapa separata [research](/blogg/fa-ai-att-lasa-ett-dokument-cover-to-cover)-policy.md, output-contract.md, security.md och domänreferenser. API-schemas som kräver exakt transformation kan kompletteras med scripts. Huvudfilen behöver då bara beskriva vilket material som ska laddas vid respektive gren.

Vinsten är inte bara tokens. Auditen blir enklare eftersom ändringar får mindre blast radius. En uppdatering av SEO-regler behöver inte röra faktakontrollens instruktioner. En ny domänvariant kan läggas till utan att alla användare får den kontexten. Och när något går fel kan jag fråga vilken modul som ägde beslutet i stället för att leta igenom en fil på hundratals rader.

Ett test mot övermodularisering

Det går också att skapa för många filer. Om modellen måste öppna sex referenser för att förstå en enkel kärnregel har jag bara flyttat komplexiteten. Jag försöker därför hålla en enkel princip: en modul ska ha ett tydligt skäl att kunna laddas separat. Om två filer nästan alltid används tillsammans och ändras tillsammans är de sannolikt en modul, inte två. Modularisering ska minska beslutskomplexitet, inte skapa en filesystem-version av mikroservices för sakens skull.

Slutsats

Modularisering handlar alltså inte om att skapa fler filer. Det handlar om att minska mängden irrelevant kontext vid varje beslut och göra ägarskapet tydligt. En liten SKILL.md med välvalda referenser är ofta lättare att förstå, testa och utveckla än en imponerande monolit.