Anatomien i en design-skill

De sektioner, vores endte med, i den rækkefølge de tjener sig hjem: palette som hexværdier med én linje om hver farves formål · typografi med faktiske størrelser og minimum · layout med margener og sikkert tekstområde · dekoration med geometriske betingelser · tekstmekanik · en smal aldrig-liste · vedlagte aktiver · to-tre gennemarbejdede eksempler, heriblandt et dårligt.

Om aktiverne, ét trick frem for alle: skriv logoets SVG-path-data direkte ind i skill-teksten i stedet for kun at vedlægge en .svg — så kan modellen emittere geometrien direkte i kode uden filopslag. Og beskriv ydre kontur og indre delsti hver for sig — ellers stanser fill-reglen et hul i formen, den dag mærket skaleres op som baggrund.

Skrevet ned fylder det mindre end guidelinen, det afløste. Forskellen er, at det her bliver bedre for hver præsentation — ti minutter ad gangen.

Vi ville have en model til at lave præsentationer, der ser ud som om et menneske med smag havde lavet dem. Det begyndte først at virke den dag, vi holdt op med at rette slides og begyndte at rette reglerne.

Vi byggede to skills til Claude: én der koger en mødetransskription ned til struktureret indhold, én der designer slides efter brandets regler. Vægten her ligger på designdelen — det var den, der var svær.

En skill er ikke et dokument

Der skal være én kilde, og det er designguidelinen. Skillen er bygget efter den — retter man noget, rettes det i guidelinen, og skillen opdateres derefter. Vedligehold aldrig de to hver for sig i hånden: driver de fra hinanden, følger modellen skillen, ikke dokumentet.

Formen er ikke valgfri: uden YAML-frontmatter med navn og beskrivelse bliver filen afvist ved upload. Sådan åbner vores:

---
name: design-a-slide
description: The brand's design system for presentations — the colour palette
  and product colours, typography, the logo with its proportions and inline SVG,
  cover and inner-slide graphics, and how to structure a deck. Use when designing,
  building or reviewing any slide, deck, PowerPoint or presentation. Version 1.1.
---

# Slide design

**Version 1.1** · 26 August 2026

Versionslinjen er frivillig — og uundværlig. Skills synkroniserer ikke mellem overflader (desktop, CLI, web og API har hver deres kopi), så før eller siden kører nogen en tre uger gammel version og melder en fejl, der for længst er rettet. Derfor står instruksen i selve skillen: "Keep the version line current". Tallet i teksten gør det diagnosticerbart på et minut i stedet for en time.

Del op efter verbet, ikke efter emnet

Byg ikke én skill, der dækker hele vejen fra transskription til færdigt slide. Del efter verbet: én skill udtrækker, én skill designer. To verber, to skills — og to beskrivelser, der hver gør tre ting: nævner indholdet, lister triggerne, bærer versionsnummeret:

description: Turns a meeting transcript, recording or interview into a slide
  plan, extracting what matters and discarding the rest. Use for transcripts,
  meeting recordings, minutes, interviews, workshops, customer calls. Version 1.0.

description: The brand's design system for presentations — palette, typography,
  logo geometry, cover and inner-slide graphics. Use when designing, building
  or reviewing any slide, deck or presentation. Version 1.1.

Beskrivelsen er det eneste, modellen ser, når den vælger skill — "Use for …"-listen er ikke dokumentation, den er udløsermekanismen. En skill, der gør to ting, får en upræcis beskrivelse og bliver kaldt forkert. Og en skill læses ind i turen: skal man kun designe, er en hel udtræksmetode dødvægt. Opdelingen halverer prisen for de fleste opgaver.

Prisen er en kontrakt imellem dem: et defineret slideformat, som den ene skriver og den anden læser. Hver post er key-value, klar til layout:

SLIDE 03 · What it costs today
Type: figure
Eyebrow: WHAT IT COSTS TODAY
Title: Checking the time data by hand costs a working day every month
Figure: 8 hours
Figure label: Per payroll run, every month
Quote: "she just made a printout and typed it in"
Source: SAID

Ændrer man formatet i den ene skill, knækker den anden stille, uden fejlmeddelelse. Til gengæld tager designskillen imod alt, der taler formatet: en rapport, en roadmap, tre bullets skrevet i hånden.

Skriv reglen, ikke rettelsen

Den mest værdifulde instruks undervejs: ret ikke slidet — ret guidelinen, så den er rigtig næste gang.

En afvisning, der kun rettes i det ene slide, kommer igen i den næste præsentation. Den eneste varige rettelse er reglen.

Rutinen: efter hver præsentation gennemgås rettelserne. Er en rettelse specifik for netop dette slide, eller er den en regel? Er den en regel, går den i skillen, og versionsnummeret ryger op. Ti minutter — og det eneste, der gør, at en skill bliver bedre i stedet for bare ældre.

Regler skal kunne tjekkes

Sammenlign: "Brug smagfuld baggrundsgrafik" mod "En radial glød skal ligge på en form, der er større end selve slidet, ellers ses dens egen cirkelkant." Den anden kan efterprøves ved at se på resultatet. Den første kan man kun diskutere.

Hver regel bør have et tal i sig: farvefordelingen 60/30/10, en margin på 96 px, footeren ved 30 % opacitet. Ingen af tallene er interessante i sig selv — men hver fejl, de dækker, gentog sig, indtil den stod skrevet.

Selv horeunge-reglen — aldrig et enkelt ord alene på sidste linje — blev tre rangordnede indgreb: kort titlen, bind de sidste to ord med non-breaking space (U+00A0), eller sæt linjeskiftet selv. Aldrig ved at krympe typografien.

Én størrelses-regel er vigtigere, end den ser ud: 16:9 renderes som 960 × 540 punkter, så brødtekst tegnet i 22 px bliver 11 pt — ulæseligt projiceret. Skillen bærer sin egen typeskala til præsentationsbrug (brødtekst aldrig under 18 pt) i stedet for at arve brand-canvassens.

Og den negative liste skal være smal: en negativ regel siger præcis, hvad den forbyder, og hvor. Generalisér aldrig en enkelt indvending til et princip, ingen har bedt om — skriv reglen på samme niveau som klagen.

Gør geometrien eksplicit

Den overraskelse, der batter mest. Visuel retning ankommer som et billede: "lav noget der ligner dette". Under billedet ligger næsten altid en geometrisk betingelse, som billedet skjuler — og indtil man har fundet den, itererer man i blinde.

Eksempel: en ring, der skal indramme en overskrift. Den skjulte betingelse: ringens tykkelse er en fast andel af dens radius, så skaleret op flader kurven ud, og tonerne vaskes ud. Find det vindue, hvor formen faktisk virker, og skriv det ind i skillen som to tal — diameter og synlig del. Så er diskussionen lukket.

// Buens nedhæng: radius for at falde s px over en halv bredde w
r = (w² + s²) / 2s
// 120 px over 960 px  →  r ≈ 3.900 px

// Når buen ud til rammens kant? (dybde d, radius R)
rækkevidde = √(R² − (R − d)²)   // skal være ≥ halv rammebredde

Gætter man radius, gætter man altid for lille — de rolige sweeps i god keynote-grafik er udsnit af enorme cirkler.

Den mest genbrugelige regel, vi fandt: hvilken vej buen krummer, afgør om dekorationen slås med overskriften. En form med massen midt på kanten støder ind i teksten — for det er præcis dér, teksten er. En form med massen i hjørnerne indrammer den. Samme form, samme størrelse, modsat resultat.

Gradienter har et koordinatsystem

Transformationsmatricerne lærer man udenad, ellers går der tid på hver eneste:

// vandret, venstre mod højre
gradientTransform: [[1, 0, 0], [0, 1, 0]]

// lodret, top mod bund
gradientTransform: [[0, 1, 0], [-1, 0, 1]]

Den lodrette er ikke intuitiv og er langt den hyppigste årsag til "hvorfor ligger min gradient på tværs". Og roterer man en form en halv omdrejning, roterer fyldet med, så gradienten spejles — stops forfattes i formens eget koordinatsystem, ikke i rammens.

En radial glød har sin egen fælde: på en form mindre end slidet ses dens egen cirkelkant, uanset hvor blødt sidste stop er. Reglen i skillen: ellipsen får en diameter på cirka to gange slidebredden, så kanten falder uden for canvasset — og fire stops i stedet for to, ellers banding:

gradientStops: [
  { position: 0,    color: { ...accent, a: 1    } },  // peak i centrum
  { position: 0.20, color: { ...mid,    a: 0.33 } },  // en tredjedel
  { position: 0.42, color: { ...deep,   a: 0.05 } },  // næsten intet
  { position: 1,    color: { ...ground, a: 0    } }   // nul — i bundens kulør
]

Slutter man på en anden kulør end bunden, får man en grå glorie.

Indholdsskillen, kort

Fire regler bærer den. Den vigtigste: arbejd i to gennemløb. Første gennemløb læser transskriptionen én gang og bygger en påstandsliste, intet andet. Andet gennemløb skriver slideplanen ud fra listen — og går aldrig tilbage i transskriptionen efter formuleringer, for det er dér, fejlene i egennavne og tal opstår. Hver påstand får en type:

SAID      · stated as fact               → may appear on a slide
AGREED    · both sides accepted it        → may appear on a slide
ASKED     · raised and left unanswered    → the open questions slide
DISPUTED  · pushed back on, contradicted  → must appear somewhere
OBSERVED  · your inference, nobody said it → appendix only, labelled

DISPUTED er den, der bliver droppet — og at droppe den er det, der gør et referat misvisende. Var nogen tilbageholdende, sagde nej eller modsagde stille en kollega, skal det med: en opsummering, der læses glattere end mødet føltes, er en opsummering, ingen stoler på.

De to sidste: sene rettelser vinder — et tal nævnt i første minut og præciseret i det fyrretyvende gælder i den sene version. Og ét ordret citat pr. deck, sætningen der siger problemet med modpartens egne ord: det billigste bevis på, at man lyttede, og det overlever at blive videresendt.

Test ved at bruge den, ikke ved at læse den

Gennemlæsning finder ingen huller — kun brug gør. Lav to færdige præsentationer med skillen: alt det, den ikke har svar på (diagrammer, taltabeller, slides uden indhold men med et udsagn), bliver en ny sektion.

For alt visuelt: rendér og se på resultatet, hver gang — kode, der kører uden fejl, kan sagtens producere noget helt andet end tilsigtet. Det er menneskets kontrol. Modellens kontrol er en anden: lad build-scriptet regne efter, om betingelserne holder, og returnere svaret som tal:

return { mutatedNodeIds: [...], notes: [
  'D=' + D + ' dybde=' + DEPTH + ' rækkevidde=±' + reach + ' (kræver 960)',
  'tekst ' + y + '..' + (y + h)
]};

Tallene er ikke til mennesker — ingen ser design sådan. De er til Claude, som læser dem i samme tur og selv fanger, at buen ikke nåede kanten, uden at skulle bede om et screenshot.

Et skelet at starte fra

Til sidst: skelettet til en design-manual-skill, klar til at fylde ud. Sektionerne er de samme som i anatomien øverst — her som fil:

---
name: design-manual
description: [Brandets designsystem for præsentationer — hvad den dækker.]
  Use when [triggerne: designing, building or reviewing slides ...]. Version 1.0.
---

# [Brand] design manual
**Version 1.0** · [dato] — hold versionslinjen opdateret

## Palette
Hexværdier + én linje om hver farves formål. Fordeling (fx 60/30/10).

## Typografi
Fonte og vægte. Faktiske størrelser — og et minimum til projektion.

## Layout
Margener, sikkert tekstområde, grid.

## Dekoration
Geometriske betingelser som tal. Gradient-retninger som matricer.

## Tekstmekanik
Linjebrud, horeunger, trunkering — rangordnede indgreb.

## Aldrig
Smal liste. Præcis hvad og hvor — generalisér ikke.

## Aktiver
Logoets SVG-path-data inline. Fonte vedlagt.

## Eksempler
To-tre gennemarbejdede — heriblandt et dårligt.

Fyld den ud med jeres egne tal, lav to præsentationer med den — og ret reglerne, ikke dine slides.