Progressive Disclosure i Claude Skills: spar 60-90% tokens

Simpelt koncept. Men de fleste gør det modsatte, og betaler for det. Både i penge og i kvalitet.

Hvorfor mere kontekst giver dårligere svar

Intuitionen siger at mere information er bedre. Hvis Claude har adgang til al dokumentation, alle skabeloner og alle eksempler, burde den give bedre svar. Ikke?

Nej. Det er omvendt.

Når du putter for meget i konteksten, sker der to ting:

1. Claude bliver dårligere til at finde det relevante. Ligesom du bliver dårligere til at finde den rigtige paragraf i et 200-siders dokument end i et 10-siders. AI-modeller har det der hedder et “lost in the middle”-problem. Information midt i en stor kontekst har tendens til at blive overset.

2. Du betaler for tokens du ikke bruger. Hvis din skill sender 12.000 tokens ind i konteksten men Claude kun har brug for 2.000 til opgaven, betaler du 6 gange for meget. Hver gang. Ved 50 kald om dagen er det ikke småpenge.

Der er en tredje effekt der er sværere at måle: en overfyldt kontekst giver Claude for mange instruktioner at holde styr på. Risikoen for at den prioriterer forkert eller modsiger sig selv stiger.

Reglen er den samme som for mennesker: den der bliver bedt om at huske alt, husker ingenting. Fokusér konteksten, og du får fokuserede svar.

Tre lag: Frontmatter, body, filer

Anthropic har designet skills med progressive disclosure som grundprincip. Det virker i tre lag:

Lag 1: YAML-frontmatter (~100 tokens)

Frontmatteren indlæses ALTID. Den er det Claude ser ved starten af hver session for at vurdere om skillen er relevant.

---
name: kundeservice-svar
description: >
  Genererer svar på kundehenvendelser baseret på vores
  produktkatalog, returpolitik og tone of voice.
allowed-tools:
  - Read
  - Grep
---

Det er ca. 50-100 tokens. Claude læser det, og hvis din opgave handler om kundeservice, aktiverer den skillen. Hvis du beder om noget helt andet, “lav en graf over omsætningen”, ignorerer Claude skillen helt, og de 100 tokens er det eneste der er brugt.

Det er første lag. Det koster næsten ingenting og fungerer som filter.

Lag 2: SKILL.md-kroppen (<5.000 tokens)

Kroppen indlæses KUN når skillen aktiveres. Den indeholder de konkrete instruktioner.

## Kundeservice-svar

Når brugeren beder om hjælp med en kundehenvendelse:

1. Identificér type: klage, spørgsmål, returanmodning eller feedback
2. Slå relevante produkter op i `references/produktkatalog.md`
3. Tjek returretten i `references/returpolitik.md`
4. Skriv svar i vores tone of voice (se `references/tone-of-voice.md`)
5. Foreslå emne-linje og svar-tekst

### Regler
- Altid dansk, uformel "du"-form
- Maksimalt 150 ord i svaret
- Tilbyd altid en konkret løsning, ikke bare "vi beklager"
- Eskaler til menneske hvis henvendelsen involverer juridiske krav

Det er typisk 300-2.000 tokens. Kun relevant når Claude faktisk skal lave kundeservice-svar. Alle andre sessioner betaler nul tokens for denne del.

Lag 3: Linkede filer (on-demand)

De filer der refereres til i kroppen indlæses KUN når Claude har brug for dem. Og kun de specifikke filer, ikke alle.

.claude/skills/kundeservice-svar/
├── SKILL.md                           (~500 tokens)
├── references/
│   ├── produktkatalog.md              (~8.000 tokens)
│   ├── returpolitik.md               (~1.200 tokens)
│   ├── tone-of-voice.md              (~600 tokens)
│   └── faq-data.md                   (~4.000 tokens)
└── templates/
    ├── svar-klage.md                  (~300 tokens)
    ├── svar-retur.md                  (~300 tokens)
    └── svar-spoergsmaal.md            (~300 tokens)

Hvis en kunde spørger om en retur, læser Claude returpolitik.md og svar-retur.md. Den har ikke brug for hele produktkataloget eller FAQ-databasen til den opgave.

Total kontekst for den specifikke opgave: ~100 (frontmatter) + ~500 (body) + ~1.200 (returpolitik) + ~300 (skabelon) = ~2.100 tokens.

Uden progressive disclosure, med alt i én stor fil: ~15.200 tokens. For den samme opgave.

Hvad det koster, og hvad du sparer

Lad os tage regnestykket.

Scenarie: Alt i én fil (ingen progressive disclosure)

Du har en SKILL.md på 15.000 tokens med produktkatalog, returpolitik, FAQ og skabeloner. Den indlæses HVER gang skillen aktiveres, uanset opgavens type.

• 50 kundeservice-opgaver om dagen
• 15.000 tokens per opgave
• 750.000 tokens om dagen

Scenarie: Progressive disclosure med tre lag

Samme skill, men struktureret i lag. Gennemsnitligt token-forbrug per opgave: ~2.500 tokens (varierer efter type).

• 50 kundeservice-opgaver om dagen
• 2.500 tokens per opgave
• 125.000 tokens om dagen

Besparelse: 83%. Og det er et forsigtigt estimat. Flere kilder, fra Anthropics egen dokumentation til folk der har målt det i produktion, rapporterer besparelser på 60-96% afhængigt af skill-kompleksiteten.

For en virksomhed der bruger Claude dagligt, er det forskellen mellem en token-regning der vokser frit og en der er forudsigelig.

Tommelfingerregel: Hold SKILL.md-kroppen under 2.000 tokens. Alt der kræver mere plads hører hjemme i en fil under references/ eller templates/.

Dit filsystem ER context engineering

Thariq Shihipar fra Anthropic formulerede det skarpt: “Think of the entire file system as a form of context engineering and progressive disclosure.”

Du behøver ikke bygge et system til at styre hvad Claude ser og hvornår. Filsystemet gør det allerede.

Når du skriver i din SKILL.md: “Se references/returpolitik.md for detaljer om returret,” fortæller du Claude at filen eksisterer og hvad den indeholder, uden at indlæse den. Claude kan selv beslutte hvornår den har brug for den.

Det er præcis som at sige til en medarbejder: “Returpolitikken ligger i den blå mappe i skabet.” Medarbejderen skriver det ikke ned. Men hun ved hvor hun finder den når en kunde spørger.

Mappestruktur som informationsarkitektur

Den måde du organiserer dine skill-mapper er informationsdesign i praksis. Her er et mønster der virker:

.claude/skills/din-skill/
├── SKILL.md              ← Instruktionerne (lag 2)
├── references/           ← Dokumentation Claude kan slå op
│   ├── api-docs.md
│   └── business-rules.md
├── templates/            ← Skabeloner for output
│   ├── rapport.md
│   └── email.md
├── examples/             ← Eksempler på godt output
│   ├── godt-eksempel.md
│   └── daarligt-eksempel.md
└── scripts/              ← Scripts Claude kan køre
    └── hent-data.sh

Hver undermappe har en rolle:

• references/: det Claude slår op for at forstå konteksten
• templates/: det Claude bruger som skabelon for output
• examples/: det Claude bruger til at kalibrere kvaliteten
• scripts/: det Claude kan køre for at hente data eller udføre handlinger

Claude læser kun de filer den har brug for. Hvis opgaven er en simpel returnering, åbner den references/business-rules.md og templates/email.md. Hvis opgaven kræver data fra et eksternt system, kører den scripts/hent-data.sh først.

Komplet eksempel: Ugentlig rapport-skill

Her er en komplet skill med progressive disclosure. Opgaven: generér en ugentlig rapport til ledelsen.

Lag 1: Frontmatter

---
name: ugentlig-rapport
description: >
  Genererer ugentlig ledelsesrapport med omsætning, pipeline,
  kundetilfredshed og vigtigste begivenheder.
allowed-tools:
  - Read
  - Bash
  - Grep
---

~80 tokens. Indlæses altid. Claude ved nu at denne skill eksisterer og hvornår den er relevant.

Lag 2: Body

## Ugentlig ledelsesrapport

Når brugeren beder om ugentlig rapport eller mandagsrapport:

1. Kør `scripts/hent-ugetal.sh` for at hente nøgletal
2. Læs output-filen `data/ugetal.json`
3. Sammenlign med forrige uges tal i `data/forrige-uge.json`
4. Identificér de 3 vigtigste ændringer (positive eller negative)
5. Skriv rapporten efter skabelonen i `templates/ugerapport.md`

### Regler
- Rapporten skal være max 500 ord
- Brug procent-ændringer, ikke absolutte tal alene
- Fremhæv handlinger: hvad skal der gøres, ikke bare hvad der skete
- Se `references/kpi-definitioner.md` for præcise definitioner

### Eskaler hvis
- Omsætning er faldet >15% uge over uge
- NPS er under 30
- Pipeline er tom for næste måned

~400 tokens. Indlæses kun når du beder om rapporten.

Lag 3: Filer (indlæses on-demand)

references/kpi-definitioner.md      (~800 tokens)
templates/ugerapport.md             (~400 tokens)
scripts/hent-ugetal.sh              (~200 tokens)
data/ugetal.json                    (varierer)
data/forrige-uge.json               (varierer)
examples/god-rapport.md             (~600 tokens)

Til en normal uge indlæser Claude: body (400) + scriptet (200) + data (varierer) + skabelonen (400) = ca. 1.000 tokens plus data. KPI-definitionerne og eksemplerne indlæses kun hvis Claude er i tvivl om noget.

Uden progressive disclosure, alt i én fil, ville det være 2.400+ tokens PLUS data, hver eneste gang.

Best practices for progressive disclosure

Baseret på Anthropics anbefalinger og erfaringer fra folk der kører skills i produktion:

1. Hold SKILL.md-kroppen under 2.000 tokens

Hvis din body overstiger 2.000 tokens, har du sandsynligvis detaljer der hører hjemme i references/. Kroppen skal fortælle Claude hvad den skal gøre. Ikke alt den skal vide.

2. Skriv description-feltet som en trigger

Frontmatter-beskrivelsen er det der afgør om skillen aktiveres. Skriv den som et svar på: “Hvornår skal denne skill bruges?” Ikke som en forklaring af hvad den kan.

Godt: “Genererer svar på kundehenvendelser baseret på vores produktkatalog og returpolitik.”

Dårligt: “En skill der bruger vores interne systemer til diverse kundeservice-relaterede opgaver med AI.”

3. Fortæl Claude hvad filerne indeholder

Du behøver ikke indlæse en fil for at Claude ved den eksisterer. Skriv i din body: “Se references/returpolitik.md for detaljer om vores 30-dages returret.” Nu ved Claude at filen eksisterer OG hvad den indeholder, og kan selv vurdere hvornår den skal læse den.

4. Brug examples/ til kalibrering

Et par eksempler på godt output slår lange instruktioner. Læg dem i examples/ og referér til dem fra body: “For et eksempel på den rigtige tone, se examples/godt-svar.md.” Claude læser dem når den er usikker.

5. Strukturér references/ efter emne, ikke type

Organisér dine filer efter hvad de handler om, ikke hvad de er.

Godt:

references/
├── returpolitik.md
├── leveringsbetingelser.md
└── produktkatalog.md

Dårligt:

references/
├── dokumentation.md     ← for bredt
├── regler.md            ← for bredt
└── data.md              ← for bredt

Jo mere præcise filnavne, jo bedre kan Claude vurdere hvilke den har brug for.

Bonuspointe: Stop med at proppe alt i CLAUDE.md

Progressive disclosure gælder ikke kun for skills. Det gælder hele dit setup.

En typisk fejl er at putte ALT i CLAUDE.md: kodestandarder, API-dokumentation, forretningsregler, skabeloner, eksempler, liste over alle filer i projektet. Filen vokser til 10.000+ tokens, og Claude læser den ved HVER session. Uanset om du beder den om at rette en stavefejl eller bygge en ny feature.

Løsningen: CLAUDE.md skal indeholde det der er relevant for ALLE opgaver. Specifik viden hører hjemme i skills.

Tænk på det sådan: CLAUDE.md er det du fortæller en ny medarbejder på dag 1. Skills er de proceduremanualer de slår op når de har brug for dem.

Hvad du ved nu

Progressive disclosure er tre lag:

1. Frontmatter (~100 tokens): altid indlæst, bruges som filter
2. SKILL.md body (<2.000 tokens): indlæst ved aktivering, giver instruktioner
3. Filer i undermapper (on-demand): indlæst når Claude har brug for dem

Det sparer 60-90% tokens. Det giver bedre output fordi Claude fokuserer på det relevante. Og det skalerer. Du kan have hundredvis af skills uden at konteksten eksploderer.

Kernen: dit filsystem er allerede et context engineering-værktøj. Brug mappestrukturen til at fortælle Claude hvad der findes. Lad Claude selv beslutte hvornår den læser det.

Næste kapitel handler om det felt der styrer det hele: description. De 1-2 sætninger Claude bruger til at afgøre om en skill er relevant for din opgave. Skriv dem forkert, og dine skills aktiveres aldrig. Skriv dem rigtigt, og Claude opfører sig som en kollega der kender din virksomhed.

Serien og begreberne

Dette kapitel er en del af guiden til Claude Code Skills. Se alle kapitler der, hvis du vil følge forløbet fra start.