Från kontext till skill: metoden
Det finns ett snabbt sätt att bygga en skill och ett rätt sätt, och de är inte desamma.
Det snabba sättet är att tänka på en uppgift, be Claude bygga en skill för den, och börja använda den. Den kommer att producera något som ser färdigt ut. Det rätta sättet börjar ett steg tidigare — med att förstå uppgiften tillräckligt bra så att skillen fångar det som faktiskt fungerar, inte det du antog skulle fungera.
Regeln under hela metoden är rak: om du automatiserar innan du förstår flyttar du bara röran snabbare. En skill upprepar vad du än lägger in i den. Koda in en vacklande process och du fixar den inte — du reproducerar den, i hög hastighet, med ditt namn på varje output.
Så metoden går åt andra hållet. Från förståelse, till en skill som håller.
Steg 1: Gör uppgiften för hand först
Innan du kodar in något, gör uppgiften — eller minns att göra den — i tillräcklig detalj för att du skulle kunna berätta varje steg. Om uppgiften är ny för dig, gör den manuellt en eller två gånger först. Du kan inte automatisera en process du inte faktiskt har kört; du kan bara automatisera din gissning om den.
Detta är inte bortkastad tid. Den manuella genomgången är där du upptäcker de steg som inte är nedskrivna någonstans — kontrollen du alltid gör, källan du alltid korsrefererar, omdömet du gör utan att lägga märke till det.
Steg 2: Skilj den stabila processen från omdömet
Dela nu upp det du gjorde i två högar.
Den stabila processen — stegen som är desamma varje gång. Hämta dessa indata, i denna ordning. Producera denna struktur. Formatera det på detta sätt. Detta är vad en skill hanterar pålitligt.
Omdömet — stegen som beror på kontext som bara du besitter. Vilket fynd som spelar störst roll för den här målgruppen. Om det här är redo att skickas. Vad datan faktiskt betyder för den här situationen. Dessa automatiseras inte bort; de blir skyddade. En bra skill gör det stabila arbetet och pausar sedan för dig vid omdömespunkterna.
Att få den uppdelningen rätt är den verkliga skickligheten i att bygga skills. Allt annat är mekanik.
Steg 3: Fånga kontexten en gång — inklusive vad som ska frågas dig
En skill är bara så specifik som den kontext du ger den. Skriv ned, en gång, de saker som gör outputen din: målgruppen, rösten och tonen, begränsningarna, de stående fakta om ditt arbete.
Lägg sedan till den del de flesta missar. Modellen löser problemet du räcker den — den kommer inte att lyfta det du glömde att inkludera. Så bygg in de klargörande frågorna i skillen: de två eller tre saker den alltid bör fråga dig innan den rusar i väg. "Vem är detta för?" "Vilken är den enda poäng du vill landa?" På så sätt kommer den saknade kontexten upp till ytan varje gång, av rutin, i stället för att läcka in i en självsäker, felaktig output.
Steg 4: Håll den kort och enkelsyftes
När en skill körs laddas dess fullständiga instruktioner in i Claudes arbetskontext och stannar där resten av sessionen — så längd har en verklig kostnad. Motstå lusten att låta en skill göra allt. En skill, en kärnuppgift. Om uppgiften är stor — en process med tjugo eller trettio steg — är det ett tecken på att den bör bli ett par fokuserade skills som lämnar över till varandra, inte en vidlyftig. (Serien återkommer till kedjning senare; för nu, håll varje skill till ett jobb.)
Steg 5: Planera, bygg sedan
Först nu bygger du. Med processen förstådd, omdömespunkterna markerade, kontexten fångad och frågorna definierade är den faktiska konstruktionen den enkla delen — Claude kan hjälpa dig att skriva själva skillen. Arbetet som gjorde den bra har redan hänt, på papper, innan du rörde verktyget.
Design först räcker inte
Du kommer att höra, korrekt, att "design är den svåra delen" och att du bör planera innan du bygger. Sant — men ofullständigt. Att planera en uppgift du aldrig faktiskt har gjort är fortfarande gissningar, bara bättre organiserade. Skillnaden som spelar roll är att designa utifrån förståelse: processen du kodar in är en du har kört för hand och sett fungera. Det är vad som skiljer en skill som håller under verklig användning från en som producerar något plausibelt och en aning fel, varje gång, tills du slutar lita på den.
Vad som kommer härnäst
Du har nu metoden. Nästa del blir konkret om själva artefakten — vad en bra skill faktiskt består av, varför kort och enkelsyftes spelar större roll än det låter, och hur man håller en skill tillräckligt effektiv för att lita på.
Nästa i den här serien: Del 3 — En bra skills anatomi