Skill-frontmatter

context: fork kører skillen i en isoleret kontekst, der er forgrenet fra et fælles punkt, og returnerer derefter kun resultatet til hovedsamtalen. Det udførlige, mellemliggende output bliver i forgreningen og forstyrrer aldrig dit primære vindue.

Det er det samme isoleringsprincip, som ligger bag en Explore-subagent: undersøgelsesarbejde skaber meget støj, så du isolerer det og afleverer et rent resumé. Skills gør dette mønster deklarativt — med én linje frontmatter.

Kontekstvinduer er ikke uendelige, og modeller er mere opmærksomme på begyndelsen og slutningen af en lang kontekst end på midten (»lost-in-the-middle«). En skill, der søger i hundredvis af filer eller indsætter lange build-logfiler i hovedsessionen, skubber din egentlige opgave ind i dette svage midterområde.

context: fork holder denne mængde ude. Du bevarer opmærksomheden på det vigtige og undgår at bruge tokens på midlertidig værktøjsstøj, som du aldrig får brug for igen.

Fork, når skill'et producerer omfattende output, du ikke har brug for at gemme: afhængighedsscanninger, loganalyse, bred udforskning af kodebasen og kørsel af testsuiter.

Du skal ikke bruge fork, når skill'ets fulde output er det resultat, du vil have direkte i hovedsamtalen — for eksempel en kort refaktorering af én fil, som du skal til at diskutere. Forking tilføjer i så fald blot en ekstra rundtur og skjuler detaljer, du faktisk havde brug for.

• Fork: støjende informationsindsamling, returnerer et resumé.
• Ingen fork: små, målrettede ændringer, som du arbejder videre med.

allowed-tools begrænser skill'et til et navngivet sæt af værktøjer. Det er princippet om mindste privilegium anvendt på en arbejdsgang: et skrivebeskyttet revisionsskill bør aldrig have Write eller Edit.

Det afspejler, hvordan du afgrænser en agents allowed_tools efter dens rolle. Begrænset værktøjsadgang reducerer skadeomfanget og gør samtidig udvælgelsen skarpere — færre, velafgrænsede værktøjer vælges mere pålideligt end en stor blandet samling.

Vær præcis om, hvad allowed-tools garanterer. Det begrænser den menu af værktøjer, som skill'et kan vælge fra — en nyttig, deterministisk grænse for funktionaliteten.

Men det kan ikke erstatte et hook, når en forretningsregel skal overholdes med sikkerhed. Hvis "refunder aldrig over 500 $" eller "push aldrig til main" har økonomiske, juridiske eller sikkerhedsmæssige konsekvenser, skal du håndhæve det med et deterministisk hook (f.eks. PostToolUse eller blokering af udgående kald) i stedet for at håbe på, at skill'ets prompt og værktøjsliste opfører sig korrekt. Prompts er ~90 % sandsynlige; hooks er 100 %.

argument-hint beskriver de argumenter, som skill'et forventer. Det viser brugen for den, der kalder det, og dokumenterer hensigten — vinkelparentes- og firkantparentes-konventionen angiver påkrævede og valgfrie parametre.

Inde i brødteksten modtages argumenterne via $ARGUMENTS (eller positionelt via $1, $2). Hintet er beregnet til mennesker og værktøjer; det fortolker eller validerer ikke — det er skill'ets brødtekst, der afgør, hvordan inputtet skal fortolkes.

Et godt hint følger samme disciplin som en god værktøjsbeskrivelse: angiv inputformatet, vis den forventede form, og gør det tydeligt, hvilke dele der er valgfrie.

• Brug <required> til obligatoriske argumenter.
• Brug [optional] til flag og ekstra argumenter.
• Placér positionsargumenterne i den rækkefølge, som brødteksten læser dem i.

Et tvetydigt hint fører til forkert brug på samme måde, som en tvetydig værktøjsbeskrivelse fører til forkert dirigering — klarhed ved grænsen forhindrer fejl længere nede i forløbet.

Nøglerne kombineres til én sammenhængende kontrakt. Et korrekt udformet skill siger: her er det, jeg modtager (argument-hint), her er det, jeg må røre (allowed-tools), og her er, hvordan jeg holder din session ryddelig (context: fork).

Læst samlet gør frontmatter det muligt for en kollega at forstå skill'ets adfærd og sikkerhedsgrænse uden at læse brødteksten — præcis det, som en delt, versionsstyret konfiguration bør tilbyde.

Hvor skill-filen ligger, afgør, hvem der får adgang til den. Et skill i projektets .claude/skills/ gemmes i VCS og deles med hele teamet. Et skill under ~/.claude/skills/ er personligt — en ny kollega, der kloner repositoriet, vil aldrig se det.

Det er den samme afvejning som mellem CLAUDE.md på brugerniveau og projektniveau. Hvis et skill indeholder en teamstandard, skal du gemme det i projektets afgrænsning, så kontrakten følger med koden.

Skill-frontmatter er en kompakt kontrakt for sikkerhed og klarhed, bygget op omkring tre nøgler:

• context: fork — isolér omfattende output, returnér et rent resumé, og beskyt hovedkontekstvinduet mod fortynding som følge af information, der går tabt midt i konteksten.
• allowed-tools — en kapabilitetsgrænse baseret på mindste privilegium; begrænser værktøjsmenuen, men håndhæver IKKE forretningsregler — brug et deterministisk hook til politikker med økonomiske, juridiske eller sikkerhedsmæssige konsekvenser.
• argument-hint — dokumenterer det forventede input (<required> kontra [optional]); ligesom en god værktøjsbeskrivelse forhindrer klarhed her forkert brug. Det validerer ikke.

Gem teamets skills i projektets .claude/skills/, så kontrakten følger med koden; gem personlige skills i ~/.claude/.