Karpathys CLAUDE.md, förklarad: en fil bakom en sökning efter skills

På Google Trends, globalt, under de senaste sju dagarna och avläst den 23 oktober 2026, framträder "karpathy skills" som en stigande sökfråga under ursprungssökningen "claude skills". Alla som följer den sökningen hamnar på samma ställe: github.com/multica-ai/andrej-karpathy-skills, ett repository som visade 222 612 stjärnor på GitHub, avläst den 23 oktober 2026. Dess beskrivning innehåller inte ordet skill överhuvudtaget. Den lyder: "En enda CLAUDE.md-fil för att förbättra beteendet hos Claude Code, härledd från Andrej Karpathys observationer om fallgropar vid kodning med LLM."

Klyftan mellan sökfrågan och objektet är ingen liten teknikalitet. En skill och en CLAUDE.md-fil är olika mekanismer som gör olika saker, och nästan varje påstående folk gör om det här repot bygger antingen på att veta vilken av dem det är eller på att tyst förutsätta fel mekanism. Vägledningen inuti är en enda fil. Repot runt den filen har också ett pluginmanifest och en mapp under skills, vilket förmodligen är där ordet i sökfältet kommer ifrån. Att skilja paketeringen från nyttolasten är det första användbara steget här.

Siffrorna, alla från GitHub och lästa den 23 oktober 2026: 222 612 stjärnor, 22 321 forks, skapad den 27 januari 2026, senast pushad den 20 april 2026, MIT-licens. Det sista paret är det intressanta. Repositoriet har inte fått någon push på ungefär sex månader, och antalet stjärnor fortsatte ändå att klättra.

Filen gör jobbet; förpackningen förklarar söktermen.

Öppna repot så blir det lätt att se diskrepansen i fillistningen. I roten finns CLAUDE.md och bredvid det CURSOR.md, EXAMPLES.md, en .cursor/rules-mapp som innehåller samma riktlinjer som en Cursor-projektregel, en .claude-plugin-mapp och en katalog skills/karpathy-guidelines. README:s rekommenderade installationsväg är pluginmarknadsplatsen, och den beskriver resultatet som att det gör "skillen tillgänglig i alla dina projekt".

Så söktermen är inte direkt fel, utan snarare oprecis. Det finns en skills-mapp. Det finns en plugin. Det som inte finns är en uppsättning separata skills som var och en gör olika saker, vilket är den form folk vanligtvis menar med ett skill-paket: en mapp som innehåller en SKILL.md och de stödfiler som förmågan behöver, som anropas för en uppgift. Här är hela vägledningen ett enda dokument med stående instruktioner, och pluginen finns för att leverera det dokumentet till ett projekt.

Om den distinktionen spelar roll för dig beror på vad du ville få ut av sökningen. Om du letade efter en verktygslåda är det här inte en sådan. Om du ville ha en kort regelbok som förändrar hur en kodagent beter sig i ett projekt, är det precis vad det här är, och det är värt att förstå varför någon skulle skriva den som en fil i stället för som färdigheter.

Klagomålen som det skrevs mot

README:s angivna källa är ett inlägg av Andrej Karpathy på X, som README citerar för tre klagomål om hur modeller skriver kod. De är värda att läsas i sin helhet, eftersom de fyra principerna motsvarar dem nästan ett till ett.

Det första: modellerna "gör felaktiga antaganden å dina vägnar och bara kör på med dem utan att kontrollera" och "hanterar inte sin förvirring, söker inte förtydliganden, lyfter inte fram inkonsekvenser, presenterar inte avvägningar, säger inte emot när de borde." Notera vad som beskrivs. Detta är inte ett klagomål på felaktiga svar. Det är ett klagomål på flytande felaktiga svar som levereras utan tvekan, där osäkerheten som borde ha lett till en fråga i stället ledde till självsäker kod.

Den andra: de "gillar verkligen att överkomplicera kod och API:er, blåsa upp abstraktioner, städa inte bort död kod… implementera en uppblåst konstruktion på över 1000 rader när 100 hade räckt." Den känner alla igen som har bett om en funktion och fått ett ramverk.

Den tredje är subtilare och, för alla som granskar diffar, den mest kostsamma: de "ändrar/tar fortfarande ibland bort kommentarer och kod som de inte förstår tillräckligt som bieffekter, även om det är ortogonalt mot uppgiften." En ortogonal ändring av en kommentar är liten i sig. Multiplicerad över en kodbas är det så en granskningskö fylls med ändringar som ingen bad om, och så en kommentar som förklarar en workaround försvinner innan någon lär sig varför workarounden fanns.

Fyra principer, och det test som var och en lämnar efter sig

Filen kodar fyra principer. Var och en åtföljs av en kort uppsättning regler, och två av dem anger ett enradigt test som du kan tillämpa på en diff utan att installera något. Det är i reglerna som filens karaktär framträder.

Tänk innan du kodar

Rubrikens instruktion är "Anta inte. Dölj inte förvirring. Synliggör avvägningar." Under den: ange antaganden explicit och fråga i stället för att gissa; presentera flera tolkningar när förfrågan är tvetydig; invänd när ett enklare tillvägagångssätt finns; stanna när du är förvirrad, namnge vad som är oklart och be om förtydligande. Detta riktar sig direkt mot det första klagomålet. Mekanismen är inte "var mer försiktig" – den handlar om att omvandla tysta val till synliga sådana, så att en granskare kan invända innan koden finns i stället för efter.

Enkelhet först

Regeln är minimal kod som löser problemet, utan något spekulativt: inga funktioner utöver det som efterfrågades, inga abstraktioner för kod som bara används en gång, ingen flexibilitet eller konfigurerbarhet som ingen har bett om, ingen felhantering för omöjliga scenarier, och "om 200 rader kunde vara 50, skriv om det". Testet är en enda fråga – skulle en senior ingenjör säga att detta är överkomplicerat? – vilket är en bedömningsfråga, och det är öppet sagt.

Kirurgiska förändringar

Här delar filen upp instruktionen i två delar, vilket är det mest användbara i den. När du redigerar befintlig kod: förbättra inte angränsande kod, kommentarer eller formatering; refaktorera inte sådant som inte är trasigt; matcha den befintliga stilen även om du skulle göra det annorlunda; nämn orelaterad död kod i stället för att radera den. När dina egna ändringar skapar föräldralösa objekt: ta bort de importer, variabler och funktioner som dina ändringar gjorde oanvända, men lämna redan befintlig död kod i fred om du inte blir ombedd. Testet är att varje ändrad rad kan spåras direkt till begäran.

Måldriven exekvering

Definiera framgångskriterier och loopa tills det har verifierats. README-filen visar omvandlingen som par. I stället för att "lägga till validering", skriv tester för ogiltiga indata och få dem sedan att passera. I stället för att "åtgärda buggen", skriv ett test som återskapar den och få det sedan att passera. I stället för att "refaktorera X", säkerställ att testerna passerar före och efter. För arbete i flera steg efterfrågar den en kort plan där varje steg anger sin egen verifiering. README-filen citerar Karpathy igen här: "LLM:er är exceptionellt bra på att loopa tills de uppnår specifika mål… Berätta inte för den vad den ska göra, ge den framgångskriterier och se hur det går."

En fil, en färdighet och ett plugin är tre olika saker

Det är värt att vara precis om mekaniken, eftersom det praktiska beteendet skiljer sig. CLAUDE.md är en projektinstruktionsfil: text som Claude Code läser som stående kontext för ett repository, närvarande oavsett om någon bad om den under den här omgången eller inte. En skill är en mapp med en SKILL.md som beskriver när förmågan bör användas, och som laddas när en uppgift kräver den och inte tidigare. En plugin är ett distributionspaket, installerat via en marketplace, som kan innehålla skills, kommandon och andra komponenter. Distinktionerna handlar om när instruktioner kommer in i kontexten och vem som bestämmer, inte om kvalitet.

En CLAUDE.md är i den bemärkelsen den mest trubbiga av de tre. Den är alltid på i det projektet, den gäller för varje uppgift i det, och den upptar kontext vid varje tur oavsett om arbetet är en enradig stavningsrättelse eller en migrering. Filens egen README erkänner kostnaden i ett avsnitt som heter Tradeoff Note: riktlinjerna lutar mot försiktighet framför snabbhet, och för triviala uppgifter – enkla stavningsrättelser, uppenbara enradare – bör du använda gott omdöme. Det står att målet är att minska kostsamma misstag i icke-trivialt arbete, inte att bromsa enkla sådana.

Det är en rättvisande beskrivning av vad en stående instruktionsfil kan göra. Den kan inte lägga till en förmåga som modellen inte har. Den kan bara göra modellens befintliga beteende mer eller mindre sannolikt. Det är därför filen är skriven som begränsningar – gör inte detta, fråga innan du gör det – snarare än som uppmuntran att bli bättre.

Vad 222 612 stjärnor mäter

De mäter uppmärksamhet. Det är inte ett avfärdande, och det är inte ingenting: ett repository som skapades i januari 2026 och senast pushades i april nådde 222 612 stjärnor och 22 321 forks den 23 oktober 2026 på GitHub, läst den dagen, vilket innebär att det delades brett och forkades av människor som ville ha en egen kopia. Antalet stjärnor är en rimlig indikator på hur många som ansåg att något var värt att bokmärka.

Det är inte en proxy för effekt, och repot låtsas inte vara något annat. Det som inte publiceras någonstans i det: någon benchmark som jämför utfall med och utan filen, någon metodik för att mäta huruvida den fungerar, och någon jämförelse mot en kontroll. Det finns ingen före- och eftermätning på en verklig kodbas, ingen granskarstudie, ingen incidentfrekvens. En sådan fil är en hypotes om modellbeteende, elegant formulerad, och ingen har genomfört försöket.

Det README erbjuder i stället är en sektion som heter How to Know It's Working, som listar fyra saker du kan observera: färre onödiga ändringar i diffar, färre omskrivningar på grund av överkomplicering, förtydligande frågor som kommer före implementeringen i stället för efter misstag, och rena minimala pull requests. Det är rimliga signaler. De är också precis vad man skulle skriva om man inte hade mätt något, och de är självrapporterade av den som tillämpar filen. Läs dem som en checklista att ställa filen mot i ditt eget repository, inte som bevis på att den redan har klarat sig.

Vad du faktiskt skriver för att installera det

README anger två vägar. Den rekommenderade körs inuti Claude Code: lägg till marknadsplatsen och installera sedan pluginen, varefter riktlinjerna finns över projekt i stället för per repo. Den andra är per projekt: hämta den råa CLAUDE.md till ett nytt repo, eller lägg till den i ett befintligt. Det finns också en incheckad projektregel för Cursor, så samma riktlinjer gäller när mappen öppnas i Cursor – en detalj som visar att filen skrevs för att vara portabel mellan verktyg som läser en projektövergripande instruktionsfil, inte knuten till en leverantörs laddare.

En sak som skaver, värd att påpeka eftersom du kommer att stöta på den om du följer README exakt. Marketplace-kommandot namnger forrestchang/andrej-karpathy-skills, medan repo-URL:en högst upp på sidan är multica-ai/andrej-karpathy-skills. Båda strängarna förekommer i samma README, läst den 23 oktober 2026. Jag kan se avvikelsen och kan inte säga varför den finns, så det ärliga rådet är att prova den andra sökvägen om den ena inte fungerar, och att betrakta en av de två strängarna som inaktuell.

En annan sak att lägga märke till på förstasidan: arkivet underhålls av multica-ai, och README-filens inledande blockcitat gör reklam för Multica, "en öppen källkodsplattform för att köra och hantera kodagenter med återanvändbara färdigheter." Det är en legitim upplysning, och det är också en ledtråd till varför paketeringen ser ut som den gör. Ett projekt som är intresserat av återanvändbara färdigheter levererar sannolikt sin egen vägledning som något installerbart, vilket är vad pluginen är.

Använda det utan att ärva dess antaganden

Avsnittet Anpassning är den del som de flesta läsare hoppar över. Filen är utformad för att slås samman med projektspecifika instruktioner snarare än att ersätta dem, och exemplen den ger är konkreta: använd TypeScripts strikta läge, alla API-slutpunkter måste ha tester, följ de befintliga mönstren för felhantering i en viss fil. Det är inte dekoration. Det är skillnaden mellan en generisk regelbok och en instruktionsuppsättning som vet var din kod finns.

Det finns ett praktiskt skäl att slå samman i stället för att stapla. Om du klistrar in filen som den är och ditt projekt har sina egna konventioner kan de två uppsättningarna instruktioner vara oförenliga, och en modell som försöker lösa en sådan konflikt är precis den förvirring som den första principen försöker eliminera. Att skriva in dina konventioner i samma fil, med samma röst, håller instruktionsytan tillräckligt liten för att kunna granskas.

Och granska det bör du. Detta är ett kort dokument med beteendeinstruktioner som kommer att gälla för varje begäran i repositoriet. Rätt fråga är inte huruvida 222 612 personer kan ha fel – det sättet att rama in saken avgör ingenting – utan huruvida varje regel motsvarar ett fel du faktiskt har sett. Om dina diffar aldrig har innehållit oombedda kommentarsomskrivningar kostar avsnittet Kirurgiska ändringar dig kontext helt i onödan. Ta bort det. Filen är MIT-licensierad och avsedd att redigeras.

Ett lager ned förändrar inget av detta när det gäller vilken modell som svarar. En CLAUDE.md-fil formar hur en begäran hanteras när den väl når en modell; den säger ingenting om modellen som tar emot den. Det andra beslutet tillhör det som sitter framför modellen. Ett sätt att ordna det är en enda OpenAI-kompatibel slutpunkt med fler än 200 modeller under en och samma nyckel, med automatisk failover mellan leverantörer och leverantörernas listpriser som förs vidare med 0 % påslag. Vi hostar modeller; vi utvecklar inte Claude Code, och ingenting i ditt repository är synligt för oss.

Sökningen kommer att fortsätta säga skills, eftersom det är ordet folk har för en sak som man installerar för att få en agent att bete sig annorlunda, och paketeringen kring det här repositoryt använder det också. Artefakten är en fil: ett dokument med stående instruktioner, skrivet mot tre specifika klagomål, med fyra principer och en uppsättning tester som du kan tillämpa för hand. Bedöm den utifrån huruvida de klagomålen låter som ditt repository. Det är en bättre fråga än antalet stjärnor, som bara någonsin mätte hur många människor som hade samma reaktion som du just hade.