Från prompt till färdighet

Om varför framtidens AI-förmågor behöver bli portabla, återanvändbara och begripliga för både människor och maskiner.

Vi har blivit ganska bra på att prata med AI.

Vi skriver prompts. Förfinar dem. Lägger till kontext. Testar igen. Justerar tonen. Stoppar in några regler. Lägger till en källa. Ber modellen tänka ett varv till.

Till slut fungerar det riktigt bra.

Sedan stänger vi chatten.

Nästa person börjar med:

Hej ChatGPT, kan du hjälpa mig att…

Vi kallar det ibland AI-transformation. Det ser emellanåt misstänkt mycket ut som kollektiv minnesförlust.

Problemet är inte att vi saknar bra prompts. Problemet är att väldigt mycket av det vi lär oss om hur AI ska arbeta fortfarande sitter fast i chatthistorik, personliga promptbibliotek, Word-dokument, Teams-trådar och den där ovanligt avancerade OneNote-sidan som någon skapade 2024.

Så: mer AI, gärna. Men strukturerat — så att kunnandet håller längre än chattfönstret det föddes i.

Prompten var aldrig slutprodukten

Prompts har varit viktiga. De har lärt oss att ge AI bättre instruktioner, bättre kontext och tydligare mål.

Men en prompt är egentligen bara en del av något större. Om jag vill att en AI ska kunna hjälpa till att ta fram ett svarsförslag på ett ärende behöver den inte bara veta vad jag vill ha just nu. Den behöver också förstå när arbetssättet ska användas, vilka steg som ska genomföras, vilka källor som är tillåtna, vilka regler som gäller, hur resultatet ska struktureras, vad som ska kontrolleras, när arbetet ska avbrytas — och när en handläggare måste ta över.

Det börjar inte längre se ut som en prompt. Det börjar se ut som en färdighet.

En prompt instruerar en modell. En skill paketerar ett sätt att arbeta.

En bra prompt kan hjälpa mig en gång. En bra skill kan potentiellt hjälpa en hel organisation — om och om igen.

Färdigheter på burk

Inom programvaruutveckling accepterade vi för länge sedan att återanvändbara saker ska paketeras. Vi har bibliotek. Paket. Containers. Git repositories. Vi har npm, pip och NuGet.

Ingen seriös utvecklingsorganisation skulle bygga sin strategi kring:

Jag tror Peter har biblioteket på sin laptop någonstans.

Men ungefär så hanterar vi fortfarande mycket av vårt AI-kunnande. En riktigt bra metod för att granska ett krav? Någon har en prompt. Ett bra sätt att analysera en incident? Finns i en gammal chat. Ett fungerande upplägg för ett svarsförslag till ett ärende? Fråga Anna.

Det fungerar. Ända tills Peter byter jobb, Anna är på semester och chatten heter “New chat 42:1337”.

En AI-färdighet gör något annat. Den gör arbetssättet till en tillgång som kan versioneras, testas, granskas, återanvändas, förbättras, kombineras — och flyttas mellan olika AI-miljöer. Betydligt mer intressant än ännu ett promptbibliotek.

Färdighet, kompetens, förmåga

Innan vi går vidare: ett litet men irriterande terminologiproblem. Vi säger “AI-kompetens” i varje styrgruppsmöte och menar tre helt olika saker beroende på vem i rummet som pratar — vilket är en utmärkt metod om målet är att alla ska lämna mötet nöjda och oense.

Färdigheter är det konkreta en individ — eller en agent — kan göra: formulera en uppgift, granska ett AI-genererat svar, avgränsa ett anrop. Kompetenser är kombinationen av kunskap, färdighet och förmåga att prestera i en roll (den termen HR gärna sätter på en kompetensmatris och sedan aldrig öppnar igen). Förmågor är organisationens samlade kapacitet att åstadkomma något: att kunna införa, styra, övervaka och vidareutveckla AI-lösningar över tid.

Det är alltså inte samma sak, hur gärna man än vill klämma in alla tre i samma PowerPoint-bullet. Den här texten pratar därför konsekvent om AI-färdigheter när det gäller det paketerbara — det som kan bli en skill — och AI-förmåga när det gäller det organisationen behöver kunna i stort. En skill är en byggsten. En förmåga är det som byggs av den. Ingen av dem får plats i ett enda Excel-ark, hur mycket någon i ledningsgruppen än önskar det.

Verbet och substantivet

En AI-färdighet blir sällan värdefull av en enda anledning. Den blir värdefull för att den håller isär två saker som annars smälter ihop i en superprompt: hur agenten ska arbeta och vad agenten behöver veta.

Det finns nu ett par kompletterande format som gör den uppdelningen konkret i stället för filosofisk:

• Agent Skills / SKILL.md paketerar procedurkunskap — arbetsflödet, reglerna, stoppvillkoren.
• Google Open Knowledge Format (OKF) paketerar domänkunskap — begreppen, fakta, relationerna, de auktoritativa källorna.

SKILL.md är verbet. OKF är substantivet.

Tag en agent vars uppgift är att förbereda ett svarsförslag på ett inkommet ärende. Skillen utarbeta-arendesvar beskriver hur den ska gå tillväga:

markdown

---
name: utarbeta-arendesvar
description: >
  Använd när ett inkommet ärende ska analyseras och ett svarsförslag
  tas fram med stöd av godkända interna kunskapskällor.
version: 1.0.0
owner: Kundservice
requires_human_approval: true
---

## Arbetsgång
1. Läs ärendet, identifiera ämne, fråga och saknade uppgifter.
2. Klassificera enligt konceptet `arendekategori`.
3. Hämta relevanta koncept för tjänst, regel och svarsmall.
4. Kontrollera mot eskaleringsreglerna.
5. Skapa svarsförslag enligt `svarsmall`, eller eskalera.
6. Ange använda källor, antaganden och öppna frågor.
7. Lämna till handläggare för granskning och godkännande.

## Stop-regler
Eskalera om sekretess, myndighetsutövning, låg klassningssäkerhet
eller motstridiga källor är inblandade.

Lägg märke till vad som inte står här: exakt vad “arendekategori” eller “svarsmall” faktiskt innehåller. Det ligger i stället i ett OKF-koncept — en egen liten fil som beskriver just det begreppet, ägs av en informationsägare, och kan uppdateras utan att skillen ovan behöver röras:

markdown

---
type: policy
id: informationsklassning
owner: Informationssäkerhetsfunktion
status: approved
version: 2.1
related_concepts: [sekretess-och-eskalering, personuppgifter]
---

## Klassningsnivåer
- Öppen: godkända externa AI-tjänster
- Intern: endast organisationens AI-miljö
- Känslig: särskilt godkänd behandling och loggning
- Sekretess: får inte behandlas av denna AI-tjänst

## Regler för agenten
Läs behörighet före hämtning. Maskera personuppgifter. Eskalera
vid osäker klassning. Ange tillämpad klass i resultatet.

Poängen är inte formaten i sig — det är att de tvingar fram en gräns som annars är lätt att slarva bort. Ändras informationsklassningspolicyn nästa kvartal räcker det att uppdatera OKF-konceptet. Skillen, arbetsflödet, förblir orörd. Ändras i stället arbetssättet — kanske ska handläggaren godkänna i två steg i stället för ett — räcker det att uppdatera SKILL.md. Kunskapen om vad sekretess betyder ligger kvar, oberörd, i sitt eget lager.

Det är precis den separationen en superprompt aldrig ger dig. I en superprompt är arbetsflödet och sakuppgifterna sammanvävda, och den dag policyn ändras vet ingen exakt vilken rad i den 400 raderna långa instruktionen som behöver justeras.

text

AI-förmåga
   =
Skill (SKILL.md — hur)
   +
Knowledge (OKF — vad)
   +
Tools (verktyg — vad agenten får göra)
   +
Human judgement (vem som ansvarar)

Tools är det tredje lagret: sök, läs, anropa ett API, skapa ett dokument. Human judgement är det fjärde och sista: att en modell kan föreslå ett svar betyder inte att den bör skicka det. I exemplet ovan är gränsen uttryckt rakt i skillen — requires_human_approval: true — snarare än underförstådd och förhoppningsvis ihågkommen.

En liten mognadstrappa, så ingen behöver bygga Skynet för att svara på ett ärende

Alla AI-lösningar behöver inte, och bör inte, ha samma grad av autonomi.

1. Informera — agenten hittar och sammanfattar information.
2. Assistera — agenten skapar utkast, som utarbeta-arendesvar ovan, som en handläggare granskar.
3. Orkestrera — agenten samordnar flera deluppgifter och verktyg under mänsklig kontroll.
4. Automatisera begränsat — agenten utför tydligt avgränsade, reversibla åtgärder.
5. Automatisera med höga kontroller — agenten hanterar avancerade flöden där mandat och ansvar är etablerat.

Vårt ärendeexempel ligger medvetet still på steg 2. Det är inte en begränsning i vad tekniken klarar — det är ett beslut om vad som faktiskt behöver en människas underskrift. Ett mötesprotokoll behöver sällan ett godkännandeflöde med tre eskaleringsnivåer. Ett ärende med sekretessfrågor gör det. Skillnaden är inte teknisk mognad. Det är omdöme om vad som faktiskt står på spel.

---

Men text är ett ganska dåligt ritbord

AI-färdigheter passar bra i textbaserade format. Markdown och YAML är enkla att läsa, versionshantera och lagra i Git — de två exemplen ovan är i praktiken helt vanliga textfiler.

Utmärkt för maskiner. Faktiskt ganska bra för människor också.

Men när en färdighet börjar innehålla många delar — instruktion, OKF-koncept, verktyg, andra skills, mänskliga kontrollpunkter och olika outputs — börjar texten få samma problem som många arkitekturdokument. Man kan läsa den. Men man kan inte alltid se den.

Och om något består av komponenter, relationer, beroenden och flöden finns det ett gammalt arkitektknep: rita det.

Skill Canvas

Det är utgångspunkten för Skill Canvas — ett experiment i att göra skills till något man kan komponera visuellt, inte bara skriva.

Tanken är enkel: en AI-färdighet borde inte bara kunna skrivas. Den borde också kunna byggas på en whiteboard, med moduler för Markdown-instruktioner, Mermaid- och ArchiCode-diagram, taxonomier, mindmaps, bilder, PromptBooks och inbäddat HTML — kopplade ihop med relationer som visar vad som hör ihop med vad.

Vårt ärendeexempel ovan går fint att lägga upp så: ett Markdown-kort för själva SKILL.md-instruktionen, ett taxonomi-kort för arendekategori, ytterligare kort för OKF-koncepten informationsklassning och sekretess-och-eskalering — och relationer som visar exakt vilket steg i arbetsgången som hämtar vilket koncept. Det som i textform kräver att läsaren håller reda på tre filer i huvudet samtidigt blir i canvasen tre kort och två pilar.

När canvasen exporteras blir den ett ZIP-baserat paket med filändelsen .skill eller .zip: alltid en SKILL.md, en genererad index.md som fungerar som innehållsförteckning, och mapparna med de faktiska artefakterna.

text

utarbeta-arendesvar.skill
├── SKILL.md
├── index.md
├── knowledge/
│   ├── arendekategori.md
│   ├── informationsklassning.md
│   └── sekretess-och-eskalering.md
├── templates/
│   └── svarsmall.md
└── tests/
    └── testfall.yaml

index.md gör paketet möjligt att läsa progressivt: en AI kan börja med metadata och huvudinstruktion, och sedan öppna koncept, exempel eller referensfiler bara vid behov — i stället för att svälja hela paketet på en gång och hoppas på det bästa.

Det visuella blir inte en snygg bild av färdigheten. Det blir ett sätt att bygga den.

---

Modellen är förmodligen den minst intressanta delen

I nästan varje AI-diskussion kommer samma fråga: vilken modell ska vi använda? GPT? Claude? Gemini? En lokal modell?

Naturligtvis relevant. Men vi är långsamt på väg mot en värld där modellen blir en betydligt mer utbytbar komponent. Det verkligt värdefulla blir det vi bygger runt modellen: vår kunskap, våra regler, våra arbetsmetoder — våra skills och våra OKF-koncept.

text

              SKILL + OKF
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
       GPT        Claude      Gemini
         │          │          │
         └──────────┼──────────┘
                    ▼
               Lokal modell

Lås inte verksamhetens kunnande till modellen som råkar vara bäst denna tisdag.

En organisation kommer byta modeller många gånger. utarbeta-arendesvar och informationsklassning kan leva betydligt längre än vilken modell som helst. Det gör portabilitet till något mer än ett tekniskt önskemål. Det blir en fråga om digital rådighet.

Från App Store till Skill Store

I stället för installera system X för att utföra uppgift Y kan man börja tänka ge agenten färdigheten Y.

En organisation kan då ha ett internt bibliotek ungefär så här — där skills och den kunskap de bygger på ligger separerade, precis som i exemplet ovan:

text

ai-capabilities/
├── skills/
│   ├── utarbeta-arendesvar/
│   ├── skapa-beslutsunderlag/
│   └── klassificera-information/
└── knowledge/
    ├── kommunal-arendehantering-okf/
    └── digital-utveckling-okf/

Varje skill kan ha en ägare, en version, tester, dokumentation och beroenden till namngivna OKF-koncept. Varje koncept kan i sin tur ha en egen informationsägare. Och framför allt: bägge kan förbättras en gång och återanvändas på många ställen, utan att någon behöver klippa och klistra en uppdaterad policy in i fem olika promptar.

Nästa stora interna portal kanske alltså inte behöver heta AI Innovation Hub 360. Den behöver bara innehålla saker som faktiskt går att använda.

Sex saker att inte glömma på vägen

1. Separera kunskap från procedur. OKF beskriver fakta och regler; skillen beskriver arbetsmetoden. Blanda inte ihop dem bara för att det är bekvämt just idag.
2. Prioritera auktoritativa källor framför utkast, historik och informella anteckningar.
3. Tillämpa minsta behörighet — ge agenten bara de data och verktyg uppgiften faktiskt kräver.
4. Gör mänskligt ansvar explicit — skriv ut vem som granskar och godkänner, i stället för att låta det vara en underförstådd förhoppning som ingen testat.
5. Gör resultat spårbara, så att det går att se vilka källor och vilken version av skillen som faktiskt påverkade svaret.
6. Utforma för portabilitet. Öppna, läsbara format som Markdown och YAML minskar beroendet av en enskild leverantör.

Ingen av dem är särskilt sexig på en konferensslide. Alla sex är betydligt billigare att följa nu än att sakna om arton månader.

Från artificiell intelligens till organisatorisk intelligens

AI-modeller kommer fortsätta bli bättre, snabbare, billigare, mer kapabla. Men de stora modellerna är samtidigt tillgängliga för nästan alla. Det betyder att själva modellen sannolikt inte blir den långsiktiga konkurrensfördelen.

Det som är unikt är hur en organisation arbetar. Vad den vet. Vilka regler den följer. Hur den fattar beslut. Hur den hanterar undantag. Hur den upptäcker när något är fel.

Det är där skills och OKF blir mer än ännu ett agentformat. De blir ett sätt att göra organisatoriskt kunnande explicit, paketerat och återanvändbart — för människor, för AI-agenter, och för nästa AI-plattform efter den vi råkar använda idag.

AI-modellen är generell intelligens som vi hyr. Färdigheterna är organisatoriskt kunnande som vi kan äga.

Nästa steg i AI-utvecklingen är kanske inte att skriva ännu bättre prompts.

Det är att skriva färre av dem — och paketera resten.

Läs mer: För en introduktion till paketerade AI-färdigheter, skills och hur organisatoriskt kunnande kan göras portabelt mellan olika AI-plattformar, se: 🔗 Paketerade AI-färdigheter [AI Wiki]