En playbook per jobb: så gör AI:n rätt även nästa gång

Du har säkert varit med om det. Du ber AI:n om något, rättar två saker, och till slut blir det bra. Veckan efter ber du om samma sak. Och båda felen är tillbaka.

Det är inte konstigt. Allt du lärde den förra veckan fanns i en chatt som är stängd. Nästa chatt börjar från noll.

Det här är guiden vi själva önskar att vi hade läst tidigare. Vi arbetar så här med de återkommande jobben bakom våra egna produkter, och exemplen längre ner kommer därifrån.

Idén i en mening

Ett återkommande jobb får en egen mapp med instruktioner, verktyg och kontroller. När något går fel rättar du i mappen, inte i chatten.

Resten av guiden handlar om hur.

Varför “en agent per uppgift” slutar fungera

Det naturliga första steget är att bygga en ny assistent för varje sak: en för offerter, en för veckorapporten, en för att sammanfatta möten. Det fungerar en stund. Sedan händer tre saker:

• Kunskapen sprids ut. Samma regel (“skriv aldrig ut kundens personnummer”) finns i fem instruktioner, i fem något olika versioner.
• Ingen vet varför en regel finns. Instruktionen säger “använd alltid mallen”, men inte vad som hände sist någon inte gjorde det. Så regeln tas bort när den känns i vägen.
• Rättelser försvinner. Felet rättas i svaret, inte i instruktionen. Nästa körning gör om det.

En playbook löser inte allt, men den ger rättelserna ett ställe att bo på.

Playbookens tre delar

1. Processen: hur jobbet görs, och varför

Det här är instruktionen. Men skriv den inte som en lista med kommandon. Skriv den som du skulle förklara jobbet för en ny kollega:

• stegen i ordning,
• besluten som ska fattas längs vägen,
• och varför varje beslut fattas som det gör.

Varför-delen är den viktigaste. En regel utan motivering följs bokstavligt och bryts så fort ett fall ser lite annorlunda ut. En regel med motivering kan AI:n tillämpa på fall du inte förutsåg.

Ett exempel från vårt eget arbete. En av reglerna i vår publiceringsplaybook lyder ungefär: “‘Kör på’ är inte ett godkännande. Godkännandet ska säga att personen själv har gått igenom ändringen.” Motiveringen står direkt under: vi har fått ett “kör på” som svar på en lång text, och ingenting i svaret visade att någon faktiskt hade klickat igenom. Utan den meningen hade regeln sett ut som byråkrati.

Skriv inte processen själv från början. Låt AI:n intervjua dig. Du vet mer än du tror, men du kommer inte ihåg det förrän någon frågar.

Jag vill att du skriver en playbook för ett jobb jag gör regelbundet: [jobbet].

Intervjua mig först. Ställ en fråga i taget. Fråga om:
- stegen i den ordning jag gör dem
- vilka beslut jag fattar längs vägen och vad jag tittar på då
- vad som brukar gå fel, och hur jag märker det
- vad jag aldrig skulle göra, och varför

När du vet tillräckligt: skriv SKILL.md med stegen i ordning och en
motivering under varje beslutsregel. Hitta inte på regler jag inte nämnt.

2. Verktygslådan: det som inte ska uppfinnas varje gång

Allt som AI:n annars skulle gissa sig fram till hör hemma här:

• mallar (hur en veckorapport eller ett offertmejl ser ut),
• referenser (prislista, kontaktlista, tonläge),
• små skript för det som ska räknas eller hämtas, inte formuleras,
• exempel på ett resultat du har godkänt.

Exemplen är underskattade. Ett enda godkänt exempel säger mer om nivå, längd och ton än en sida instruktioner.

3. Beviset: kontroller som faktiskt kan bli röda

Det här är delen de flesta hoppar över. Innan resultatet når dig ska det passera kontroller som är sanna eller falska, inte bedömningar.

“Ser rapporten bra ut?” är ingen kontroll. Det här är:

• Summan i tabellen stämmer med summan i underlaget.
• Varje kund i listan finns i kundregistret.
• Texten innehåller inga ord från listan över förbjudna formuleringar.
• Länkarna svarar.

Och en regel vi har lärt oss den hårda vägen: lita aldrig på en grön kontroll som du inte har sett bli röd. Vi har haft en kontroll som visade “0 fel” för att den kontrollerade en funktion som inte fanns. Mata in ett medvetet fel en gång och se att kontrollen fångar det. Först då betyder grönt något.

Loopen: rätta i playbooken, inte i chatten

Så här ser arbetet ut när playbooken väl finns:

1. AI:n gör jobbet enligt playbooken.
2. Du hittar ett fel.
3. Innan du rättar resultatet, fråga vilken del som brast:
   • Saknades ett steg eller en regel? → processen.
   • Gissade AI:n något som borde ha stått i en mall eller referens? → verktygslådan.
   • Borde en kontroll ha fångat det? → beviset.
4. Rätta där. Skriv en rad i loggen: datum, vad som hände, vad du ändrade.
5. Kör om.

Steg 3 är hela poängen. Rättar du bara resultatet har du fixat en körning. Rättar du playbooken har du fixat alla kommande.

Det här blev fel: [beskriv felet].

Rätta inte resultatet än. Säg först vilken del av playbooken som brast:
processen, verktygslådan eller kontrollerna. Föreslå sedan en ändring i
den filen, och en rad till notes.md som förklarar vad som hände.

Mappen

En mapp per jobb. Inte mer komplicerat än så:

veckorapport/
├── SKILL.md      processen: steg, beslutsregler och varför
├── files/        mallar, referenser, skript, kontroller
├── examples/     resultat du har godkänt
└── notes.md      loggen: datum, vad som gick fel, vad som ändrades

notes.md ser ut som en bisak, men läs igenom den en gång i månaden. Det som dyker upp flera gånger är nästa sak att bygga en kontroll för.

Ett exempel: från ändring till publicering

Så här ser en av våra egna playbooks ut, förenklad. Jobbet: få en ändring i en av våra produkter från kod till publicerad, utan att något hoppas över.

Processen beskriver stegen från ändring till testmiljö, granskning och publicering, och vem som gör vad. Under varje beslutsregel står varför. Till exempel att det som publiceras ska vara exakt det som granskades, inte en ny version byggd efteråt. Annars har granskningen inte granskat det som faktiskt går ut.

Verktygslådan har en mall för granskningsunderlaget. Mallen håller underlaget till en skärm: adress, en klickväg med vad som ska synas och vad som vore fel, texter att godkänna och kända fel.

Beviset är en lista med kommandon som ger ett ja eller nej: kör testmiljön rätt version, har testerna för just den versionen gått igenom, svarar sidan och visar den faktiskt innehåll, inte bara en tom sida med statuskod 200.

Loggen har vuxit ur verkliga fel. En av raderna handlar om kontrollen som visade grönt mot en funktion som inte fanns. Därför står regeln om röda kontroller nu i processen.

Ingen av delarna skrevs färdig på en gång. Playbooken har vuxit ur fel, ett i taget.

Fem fällor

1. En playbook för allt. Håll en per jobb. När en playbook börjar handla om två saker, dela den.
2. Regler utan varför. De tas bort första gången de är i vägen. Skriv motiveringen, även när den känns självklar.
3. Kontroller som är åsikter. “Kontrollera att tonen är rätt” är en förhoppning. Gör den mätbar, eller lägg till ett godkänt exempel i stället.
4. Rättelser i chatten. Varje gång du rättar ett svar utan att röra playbooken betalar du för samma fel igen.
5. Att vänta på den perfekta playbooken. Börja med tre steg och en kontroll. Resten kommer från felen.

Dina första trettio minuter

1. Välj ett jobb du gör varje vecka och som följer ungefär samma mönster. (5 min)
2. Låt AI:n intervjua dig med prompten ovan och skriv SKILL.md. (10 min)
3. Lägg ett godkänt exempel i examples/. Ett gammalt resultat du var nöjd med räcker. (5 min)
4. Skriv en kontroll som kan bli röd, och se den bli röd en gång. (10 min)

Nästa gång något går fel vet du var rättelsen ska in.