Sådan lærte jeg Ronni at bygge Claude Code Skills på en dag

Den 29. april 2026 holdt jeg og min medejer Ronni hos AP3 en intern arbejdsdag med ét formål: Ronni skulle gå fra at bruge AI som en bedre Google til at bygge sin første genbrugelige Claude Code Skill.

Vi gjorde det færdigt. Han har sin første egen skill kørende i produktion. Det her er hvad vi byggede, hvad der gik galt undervejs, og hvad der kom ud i den anden ende.

Hvad jeg byggede

En arbejdsdag, ikke et stykke software. Det vigtigste skifte jeg lavede inden dagen: jeg droppede planen om at “shippe ti ting” og reducerede til ét pair-build eksempel.

Strukturen blev sådan her:

• Formiddag: Hvad er en Skill, og hvor sidder den i landskabet (deterministisk vs. ræsonnerende vs. autonom AI). Skills er tool-making, ikke en fjerde kategori. Det skal være klart fra start.
• Eftermiddag (13:00 til 16:30): Pair-build. Vi byggede én konkret skill sammen, brugt på en rigtig kundeopfølgning Ronni skulle lave alligevel.
• Sidst på dagen (17:30 til 19:30): Vi tog Ronnis eksisterende analytics-rapport-skill, som han havde bygget alene, og refaktorerede den med samme disciplin som vi havde bygget den nye med.

Hele dagen kørte med ét princip: vi byggede ikke for at have bygget noget. Vi byggede en ting Ronni skulle have brugt i ugen efter alligevel.

Skillen vi byggede

Et “kunde-opfølgnings”-skill. Konkret: Ronni har et hav af kunder i vores PM-system (Productive). Hver mandag skal han igennem dem og se hvor der mangler opfølgning. Det er den slags arbejde der falder mellem stolene.

Skillen gør det her:

1. Slår op i Productive via MCP-connector
2. Henter kundens seneste aktivitet, deadlines og udestående tasks
3. Krydsrefererer med Notion-kunde-databasen for kontekst
4. Genererer et udkast til en opfølgningsmail eller en Slack-besked

Den er ikke autonom. Den er ikke “AI agent”. Det er en deterministisk skill der gør det samme hver gang, men gør det 30 gange hurtigere end Ronni gjorde det manuelt.

Tool stack

• Claude Code som runtime for skillen
• MCP-connectors til Productive (PM) og Notion (kundedatabase)
• Markdown + et SKILL.md fil som hele “kildekoden” til skillen
• Privat GitHub-repo til distribution mellem mig og Ronni
• Dropbox-bundle som første distribution før vi flyttede til repo

Ingen frameworks. Ingen byggesystem. Skillen er et par hundrede linjer markdown, der instruerer Claude i hvordan opgaven skal løses, og hvilke connectors den skal kalde i hvilken rækkefølge.

Hvad gik galt

Tre ting, og det er værd at nævne dem alle:

1. Distribution. Jeg antog at vi bare kunne dele skillen mellem to brugere via en symlink fra Dropbox. Det virker ikke. Der er ikke et officielt privat-plugin-distributionsspor, så vi endte på et privat GitHub-repo med Ronni som collaborator. Dropbox-bundle som mellemstation duer fint til engangsoverleveringer, men ikke til løbende opdateringer.

2. Per-bruger credentials. Productive MCP’en kunne deles via skill-bundlet. Notion og Gmail kunne ikke. Jeg brugte 30 minutter på at prøve at få Notion-credentials til at flyde med, før jeg accepterede at de skal bo per bruger. Det er en grænse i platformen, ikke i skillen.

3. Den var for Ronni-specifik. Da vi pakkede den ud af Ronnis Downloads-mappe, opdagede jeg at jeg havde skrevet hans navn ind tre steder, og at trigger-phrases kun matchede den måde han talte til Claude på. Vi brugte den sidste halvanden time på at generalisere den, så den virker for begge to. Det blev den vigtigste lektion i dagen: byg det specifikt først, generaliser når du har set det fungere.

Outcome

• 1 skill i produktion, brugt på rigtige kundeopfølgninger fra ugen efter
• Ronni byggede selv en variant ugen efter uden mig som backseat driver
• Hans gamle analytics-rapport-skill blev refaktoreret samme dag og er nu også delt mellem os
• Test på en rigtig kunde lykkedes første gang efter generaliseringen

Vigtigste outcome: Ronni er nu ikke afhængig af at jeg sidder ved siden af. Han kan bygge nye skills selv, og han kan gennemskue mine når jeg deler dem. Det er det eneste mål der tæller på en sådan dag.

Hvad jeg vil gøre anderledes næste gang

Jeg ville starte med distributionsspørgsmålet i stedet for at gemme det til sidst. Det viste sig at være den største friktionspunkt, og hvis vi havde haft det privat repo oprettet om morgenen, havde vi sparet to timers omveje.

Jeg ville også have skåret ned på teorien i formiddagen. Halvdelen af det jeg gennemgik blev først rigtigt forstået, da vi sad og byggede. Næste gang: 30 minutters intro, så direkte ind i kode.

Hvis du vil prøve det selv

Vælg én ting du gør hver uge i hånden. Ikke ti. Én. Byg en skill der gør den ene ting. Brug den i en uge. Først dér ved du om skillen skulle have været bygget anderledes, og så kan du bygge nummer to.

Det er præcis sådan jeg arbejder dagligt på Primux-kunder, og det er sådan jeg lærte Ronni at gøre det samme.

Om dette case study: Skrevet 3. maj 2026, fire dage efter den faktiske arbejdsdag. Alle detaljer er fra rigtigt arbejde hos AP3, anonymiseret hvor det rører ved kundedata.