Vad en skill-diff avslöjar — Anthropics omskrivna design-skill som lektion i skill-design

Sammanfattning

Anthropic skrev nyligen om sin frontend-design skill, den som ska få Claude att generera gränssnitt som inte ser ut som alla andra AI-genererade gränssnitt. Jag ställde de två versionerna sida vid sida och läste diffen rad för rad. Det är där den här artikeln börjar: i vad ändringarna avslöjar.

Anthropic är så nära man kommer experter på att skriva skills. När experter reviderar sitt eget hantverk i öppen källkod kan man läsa ändringarna baklänges: vad de klippte bort, vad de la till, och vad det säger om hur en bra skill ska skrivas. En skill är trots allt bara text — markdown som beskriver kunskap och omdöme. Att se en mästare stryka i sin egen text avslöjar principen bakom strykningen.

Artikeln handlar om vad Anthropics omskrivning lär oss om att skriva skills överhuvudtaget, inte om frontend-design. Jag drar fyra principer ur diffen, var och en förankrad i en konkret ändring de gjorde.

Varför en skill-diff är värd att läsa

De flesta kopierar skills. Man hittar en bra SKILL.md, klistrar in den, byter ut domänen. Det fungerar, men man lär sig ingenting om varför den är bra.

En diff är ett annat slags källa. När samma team skriver om samma skill med samma mål ("få Claude att göra distinkt design") är skillnaden mellan de två versionerna ren signal. Allt som var konstant (målet, modellen, formatet) faller bort, och kvar står de beslut som faktiskt rör hur man formulerar en instruktion till en agent.

Jag skriver skills åt kundprojekt: en för dimensionering av industriella värmekablar, en för innehållsproduktion på den här sajten, flera till. I ett av projekten mätte vi effekten av att lägga till en domän-skill med evals: agenten gick från 25 % till 84 % pass rate på blindtest, +59 procentenheter, utan att byta modell. Det lärde mig att en skill spelar enorm roll, men inte hur man skriver en som generaliserar. Anthropics diff gör det.

Vad som faktiskt ändrades

På ytan gör båda versionerna samma sak. Den gamla har ett uttalat mål — "avoid generic AI aesthetics" — och en strukturerad genomgång: en sektion om designtänkande, en lista med estetiska riktlinjer (typografi, färg, motion, layout), och en uttalad NEVER-lista: använd aldrig Inter, Roboto, Arial; aldrig lila gradienter på vit bakgrund; aldrig förutsägbara layouter.

Den nya versionen river upp formatet. Den öppnar med en roll:

Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's.

Sedan följer prosa, inte punktlistor: förankra designen i ämnet, jobba i en uttalad process (brainstorm → plan → kritik → bygg → kritik igen), och, det mest konkreta tillägget, en hel sektion om copy som designmaterial. Den gamla versionens förbudslista är borta. I stället står en kalibrering: AI-design klustrar just nu kring tre looks, här är de exakt, använd dem bara om uppdraget faktiskt ber om det.

Fyra beslut i den diffen generaliserar bortom design.

Fyra principer ur diffen

1. Ge agenten en roll, inte en checklista

Den gamla skillen var en kravspec: bocka av typografi, bocka av färg, bocka av motion. En checklista är lätt att följa och lätt att verifiera, men den faller platt i exakt det ögonblick man möter ett fall som inte står på listan. Agenten har inget att resonera ifrån.

Den nya skillen ger Claude en yrkesidentitet att resonera ifrån: en designledare vars rykte hänger på att inget arbete ser ut som någon annans. Den rollen genererar omdöme i situationer ingen checklista förutsåg. När agenten möter ett nytt slags brief frågar den inte "vilken punkt på listan gäller här" utan "vad skulle en designledare med det här ryktet göra". Rollen är komprimerad domänkunskap: den bär med sig hundra implicita regler utan att räkna upp en enda.

När en skill ska producera omdöme snarare än följa en sekvens, ger en väl vald roll mer än en uttömmande regellista. Spara listan till det som verkligen är en sekvens.

2. Positiv riktning styr starkare än förbud

Den gamla skillens NEVER-lista är frestande att skriva, för den är konkret och känns trygg. Problemet är vad den lämnar efter sig. Ett förbud säger var agenten inte får vara. Det säger ingenting om vart den ska. En agent som lyckats undvika Inter, lila gradienter och förutsägbara layouter står kvar i ett tomt rum utan riktning, och faller då tillbaka på nästa default i ledet.

Den nya skillen ersätter förbuden med en positiv förankring: namnge det konkreta subjektet, dess publik, och sidans enda jobb innan du designar något. Hämta uttryck ur ämnets egen värld. Det styr genom att fylla rummet med riktning i stället för att möblera bort några möbler. Förankringen producerar distinkthet som bieffekt: en design som verkligen utgår från sitt ämne kan inte samtidigt se ut som alla andra.

I egna skills märker jag samma sak. "Undvik X" lägger en gräns men ingen kurs. "Gör Y, av det här skälet" generaliserar, för agenten kan tillämpa skälet på fall jag aldrig skrev ner.

3. Namnge agentens egen felväg konkret

Det skarpaste i den nya skillen är att den vågar vara specifik om hur Claude själv brukar misslyckas. Den beskriver de tre looks som AI-genererad design klustrar kring just nu: en varm gräddvit bakgrund nära #F4F1EA med ett högkontrast-serif-display och en terracotta-accent; en nästan svart bakgrund med en enda klar syra-grön eller vermilion-accent; och en broadsheet-layout med hårfina linjer, noll border-radius och täta tidningsspalter. Tre legitima looks, men defaults snarare än val, och de dyker upp oavsett ämne.

En skill som kan beskriva sin egen typiska felväg så konkret kan styra undan just den. Det är skillnaden mellan "var originell" (intetsägande) och "du dras mot de här tre uttrycken, känn igen dem och välj aktivt bort dem om briefen inte ber om dem". Det andra är användbart för att det möter agenten där den faktiskt fastnar.

Tillämpat brett: en bra skill innehåller en ärlig beskrivning av domänens vanligaste misstag, gärna de som modellen själv lutar åt. Det kräver att man vet var det brukar gå fel, vilket man bara gör efter att ha sett det gå fel. Det är därför evals och skill-skrivande hör ihop: evals visar dig felvägen, skillen kodifierar undanmanövern.

4. Bygg in en process och en kritik-loop, inte bara ett mål

Den gamla skillen beskrev vad som blir bra. Den nya beskriver hur man kommer dit: brainstorma ett kompakt token-system (färg, typ, layout, signatur), granska planen mot briefen innan en rad kod skrivs, bygg, och kritisera sedan igen. Den citerar till och med Chanels råd (ta av en accessoar innan du går ut) som en inbyggd självkritik.

En process överlever fall som ett kvalitetsmål inte gör. "Gör distinkt design" ger ingen hjälp när agenten kört fast; "lägg en plan, granska den mot uppdraget, bygg, kritisera" ger en väg framåt oavsett ämne. Kritik-loopen är särskilt värd att stjäla: en skill som ber agenten granska sitt eget utkast mot det ursprungliga kravet fångar fel innan de hinner bli leverans.

Den största enskilda ändringen var en hel dimension som saknades, inte en finputsning av det som redan stod där. Den nya skillen lägger till ett helt avsnitt om copy: ord i ett gränssnitt är designmaterial, inte dekoration, och förtjänar samma omsorg som färg och spacing. När man reviderar en skill är den mest värdeskapande frågan sällan "hur skärper jag den här meningen" utan "vilken dimension av domänen har jag inte beskrivit alls".

I praktiken

Om du ska skriva eller revidera en egen skill, här är diffen översatt till arbetssätt:

1. Avgör om uppgiften kräver omdöme eller en sekvens. Är det en process med ordning som spelar roll, gör en checklista. Ska agenten producera omdöme i oförutsedda fall, ge den en roll att resonera ifrån, och spara listan till det som verkligen är stegvis.

2. Skriv riktning, inte bara förbud. För varje "gör inte X", fråga vad agenten ska göra i stället, och varför. Skälet är det som generaliserar: ett förbud gäller bara sin egen rad.

3. Namnge den vanligaste felvägen konkret. Skriv ner hur det brukar gå fel i din domän, helst de misstag modellen själv lutar åt. Ju mer specifikt, desto mer styr det. Det här fältet kan du oftast bara fylla i efter att ha kört evals och sett mönstren.

4. Lägg in en kritik-loop. Be agenten granska sitt utkast mot det ursprungliga kravet innan den levererar. Ett steg, en mening, men det fångar fel som inget kvalitetsmål gör.

5. Vid revidering: leta efter den saknade dimensionen. Innan du finputsar formuleringar, fråga vilken hel del av domänen skillen inte nämner alls. Det var där Anthropic hämtade sitt största lyft.

Det fina med att läsa skills den här vägen är att varje uppdatering Anthropic gör i öppen källkod blir gratis läromaterial. Man läser deras ändringar och tar med sig principen in i sina egna, utan att kopiera skillen.

Källor och vidare läsning

Se källorna i artikelns metadata för originalreferenser — frontend-design-skillen och dess revideringshistorik ligger öppet i anthropics/skills.