Den bästa Claude Code-installationen för 2026

Varje Claude Code-installation vi granskat hamnar i ett av två failure-lägen. Det första är standard utan mer: ingen CLAUDE.md, inga skills, permissions-prompt vid varje kommando, och användaren undrar varför Claude ständigt glömmer hur projektet byggs. Det andra är den överkonfigurerade maskinen: 40 skills, 9 MCP-servrar, en CLAUDE.md lång som en c-uppsats, och ett context window som är halvfullt redan innan första prompten.

Den bra installationen ligger mellan de ytterligheterna, och det tar cirka 30 minuter att bygga om du gör lagren i rätt beroendeordning. Den ordningen spelar roll. Skills förutsätter en fungerande installation. Permissions-beslut beror på vilka MCP-servrar du kör. Uppdelningen per projekt är först meningsfull när du vet vad du delar upp. Det här är guiden vi ger nya SkillProof-kollegor dag ett, med delarna vi gjorde fel under sex månader borttagna.

Lager 1: installation och inloggning, fem minuter

Du har förmodligen redan gjort det här, så jag håller det kort.

npm install -g @anthropic-ai/claude-code
cd your-project
claude

Vid första körningen guidar /login dig genom inloggningen. Du har två betalningsvägar: ett Claude-abonnemang (Pro eller Max) eller en API-nyckel med betalning per token. Kodar du med Claude dagligen är abonnemanget nästan alltid billigare; API-fakturering vid tunga agentiska sessioner blir dyrare snabbare än folk tror. Är du en del av ett team, kolla om er organisation har en Claude for Work-plats innan du bränner en privat API-nyckel.

Verifiera med något trivialt ("vad gör det här repot?") och bekräfta att Claude kan läsa dina filer. Det är hela lagret. Allt nedan är där installationer faktiskt börjar skilja sig åt.

Lager 2: en CLAUDE.md som förtjänar sina tokens

CLAUDE.md är en markdown-fil som Claude läser in i kontexten vid start av varje session i det projektet. Varje session, oavsett om innehållet är relevant eller inte. Det inläsningsbeteendet avgör allt om vad som hör hemma i den.

Det som hör hemma: fakta som gäller nästan varje session. Build- och testkommandon. Tvåmeningsversionen av er arkitektur. Konventioner Claude ständigt gör fel utan att bli tillsagd (er import-ordning, ert commit-format). Var liken ligger begravda: den föråldrade modulen ingen ska röra, konfigfilen som ser oanvänd ut men inte är det.

Det som inte hör hemma: procedurkunskap du bara behöver ibland. Hur man skriver en databasmigrering. Er release-checklista. Husstilen för kundmejl. Vart och ett av dessa gäller kanske 5 % av sessionerna, och i CLAUDE.md betalar du för dem i de andra 95 % också. Det materialet vill vara en skill (nästa lager), som bara laddas när den triggas.

Vår tumregel efter att ha testat detta på vårt eget repo: är din CLAUDE.md över 60 rader bör något i den flyttas ut. Vår började på 400 rader eftersom vi behandlade den som dokumentation. Claude följde den sämre, inte bättre, eftersom signalen drunknade. Den komprimerade versionen, cirka 50 rader kommandon och hårda begränsningar, följs nästan alltid.

Skriv första utkastet på tio minuter och sluta där. Du kommer förfina den under veckor allteftersom du märker att Claude upprepar misstag; den iterativa loopen är själva metoden. Den fullständiga genomgången, inklusive antimönstren vi ser i läsarinskickade filer, finns i vår guide till CLAUDE.md.

Lager 3: skills, lagret de flesta hoppar över

Det här är lagret som skiljer en installation från en genomtänkt setup, och det är det de flesta aldrig rör. En skill är en mapp med en SKILL.md-fil som lär Claude ett arbetssätt. Den kostar ungefär 100 tokens metadata i vila och laddar sina fullständiga instruktioner först när en uppgift matchar dess beskrivning. Installerad en gång gäller den för alltid, i varje session.

Folk hoppar över det här lagret av ett rationellt skäl: ungefär hälften av community-skillsen på GitHub misslyckas vid första installationen. Vi vet, eftersom att installera och testa dem är hela vår verksamhet. Varje skill i SkillProof-katalogen genomgår en installation på en ren maskin och triggerkontroller, sedan körs riktiga uppgifter mot en baslinje utan skill, innan den får ett betyg. Av de 73 skills vi hittills katalogiserat klarade sig 35.

För en utvecklarmiljö är det här de fem att installera först, med poäng från våra testkörningar:

1. Test-Driven Development, 9,6. Tvingar fram strikt red-green-refactor: misslyckat test först, minimal implementation, sedan städning. I vår session med tre features hoppade den aldrig över cykeln, inte ens när vi försökte prata den till det.
2. Systematic Debugging, 9,6. Ersätter gissa-och-testa-fixar med en hypotes-test-verifiera-loop. Den rotfelsökte ett race condition som Claude tidigare "fixat" tre gånger genom att gissa.
3. Frontend Design, 9,6. Det största före/efter-gapet vi mätt på någon skill. Samma landningssidebrief, körd två gånger: baslinjen gav den neongradient-allt-centrerat-looken, versionen med skill hade en riktig typskala och en palett som såg vald ut.
4. Memory Management, 9,2. Ger Claude ett bestående minne mellan sessioner. Under en veckas testning kom den ihåg projektbeslut och preferenser tillförlitligt, och minnet förblev korrekt allteftersom minnesbanken växte.
5. Webapp Testing, 8,8. Claude kör din app i en riktig webbläsare via Playwright och rapporterar vad som går sönder. Den fångade en regression våra enhetstester missade.

De två första kommer från Jesse Vincents Superpowers-samling (/plugin marketplace add obra/superpowers-marketplace, sedan /plugin install superpowers). Frontend Design levereras i Anthropics officiella skills-repo och kopieras direkt in i ~/.claude/skills/. Exakta steg, inklusive failure-lägena som äter upp folks första timme, finns i installationsguiden. Efter installationen, starta om Claude Code och testa varje trigger genom att be om arbetet utan att nämna skillen. Om inget synligt ändras triggas inte skillen, och en installerad skill som aldrig triggas är bara en mapp.

Om ditt arbete lutar åt ett annat håll rankar vår lista över bästa kodningsskills hela kategorin, uppdaterad allteftersom nya testkörningar landar.

Lager 4: MCP-servrar, bara de du faktiskt använder

MCP-servrar kopplar Claude till saker utanför repot: din databas, ditt ärendesystem, en levande webbläsare. De är kraftfulla och de är den dyraste posten i din context-budget. Varje ansluten server injicerar sina toolbeskrivningar i varje session, använd eller inte, och en enda pratsam server kan kosta mer stående tokens än 50 installerade skills tillsammans. Vi mätte det här i guiden om token-kostnader, och siffrorna ändrade hur vi konfigurerar våra egna maskiner.

Så ribban för en MCP-server bör vara hög: den förtjänar en plats bara om Claude behöver nå något den annars inte kan. Tre brukar klara det testet för utvecklare:

En databasserver (Postgres eller vad ni nu kör). Att Claude skriver queries mot ert riktiga schema i stället för ett gissat är en helt annan produkt. Det här är den enskilt mest värdefulla MCP-anslutningen för de flesta team.

Webbläsarautomation (Playwright MCP), om ni bygger UI och inte använder Webapp Testing-skillens egen setup. Att se den renderade sidan slår att gissa sig till den från JSX, varje gång.

Ert ärendesystem, men bara om ni faktiskt arbetar ärende för ärende inuti Claude Code. Kikar ni på Linear två gånger om dagen räcker webbläsaren, och tokensen är inte värda det.

Lägg märke till vad som saknas: GitHub MCP-servern. gh-CLI:t gör allt den gör, Claude vet redan hur man använder den, och den kostar noll stående kontext. Det här substitutionsmönstret generaliserar. Innan du lägger till en server, fråga om ett CLI-verktyg Claude kan anropa ger dig samma räckvidd gratis. Och väger du om ett problem behöver MCP alls eller bara en skill, finns beslutsregeln i skills vs. MCP: skills ändrar vad Claude vet hur man gör, MCP ändrar vad den kan nå.

Lager 5: permissions och säkerhetsinställningar värda att ändra

Standardupplevelsen för permissions är en prompt för nästan varje kommando, vilket tränar folk att klicka "tillåt" reflexmässigt. Det är det sämsta möjliga utfallet: all friktion, ingen säkerhet. Två ändringar löser det.

Först, allowlista kommandona du ändå skulle godkänna. I .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

För det andra, lägg märke till deny-blocket, för det är halvan folk hoppar över. Claude har ingen anledning att läsa er .env, och en deny-regel gör det till en egenskap hos systemet i stället för ett hopp. Kör ni MCP-servrar eller skills från tredje part spelar det här ännu större roll, eftersom en illvillig instruktion inte kan exfiltrera det som harnesset inte läser. Vår säkerhetsguide täcker granskningssidan.

Om --dangerously-skip-permissions: flaggnamnet är ärligt. Inuti en engångscontainer utan credentials är det ett bra sätt att köra långa obevakade jobb. På din laptop, med dina SSH-nycklar och dina inloggade webbläsarsessioner, är det så du hamnar i en postmortem. Vi använder den i CI-sandlådor och ingen annanstans.

Per projekt vs. globalt: var varje del hör hemma

Allt ovan finns på två nivåer, och att blanda ihop dem är den vanligaste konfigrörig vi ser. Uppdelningen:

Del	Globalt (~/.claude/)	Per projekt (.claude/ i repot)
CLAUDE.md	Din personliga stil: svarslängd, språk, käpphästar	Build-kommandon, arkitektur, projektkonventioner (committa denna)
Skills	Allt generellt: debugging, TDD, skrivande	Bara teamspecifika arbetsflöden
Settings	Din personliga allowlist	Teamets allowlist och deny-regler (committa denna)
settings.local.json	—	Dina maskinspecifika överskrivningar (gitignore denna)
MCP-servrar	Servrar du använder överallt	Projektets .mcp.json, så att kollegor får samma anslutningar

Principen: allt en kollega skulle behöva går i repot, allt som handlar om dig går globalt. Vinsten syns när någon ny klonar projektet och Claude redan kan build-kommandona och konventionerna, med databasanslutningen redo. Deras lager 2 och halva lager 4 kommer på köpet.

Min setup efter sex månader

Vad som faktiskt överlever på min maskin, för kalibrering: en 54-raders projekt-CLAUDE.md, nio skills, två MCP-servrar (Postgres och Playwright), och permissions-blocket ovan. Installationssessioner känns identiska med för sex månader sedan; skillnaden är allt jag tagit bort.

Borttagningarna lärde mig mer än tilläggen:

Tog bort GitHub MCP-servern. Behöll den i fyra månader av ren tröghet. Dess toolbeskrivningar kostade tusentals stående tokens per session och gh gjorde samma jobb. Inget försämrades. Den här enda borttagningen betalade för tiden det tog att skriva den här artikeln.

Tog bort en minnes-MCP-server till förmån för Memory Management-skillen. Servern var ännu en process att passa och ännu en inloggning att underhålla. Skillen gör jobbet i vanliga filer jag kan läsa och redigera själv. När minnet krånglar öppnar jag markdown-filen och fixar det, vilket jag aldrig kunde med ett ogenomskinligt lager.

Skar ner CLAUDE.md från 400 rader till 54. Den långa versionen läste som bra dokumentation och presterade som brus. Efterlevnaden av reglerna som spelade roll gick upp när reglerna som inte gjorde det togs bort. Jag ser numera varje rad som hyra.

Avinstallerade 19 av 28 skills. De flesta var "kan-vara-bra-att-ha"-installationer som aldrig triggades i riktigt arbete. Lazy loading gör att de kostar lite, men överlappande beskrivningar orsakade två riktiga triggerkonflikter, och granskningen som hittade dem var mödosam. Nio skills som triggas varje vecka slår 28 som mest inte gör det.

Rullade tillbaka en generell Bash(*)-allow-regel. Lade till den under en deadline-vecka, behöll den för länge. Dagen Claude med säkert intonation körde en destruktiv migrering mot en utvecklingsdatabas som visade sig vara mindre engångs än märkt, satte jag tillbaka prompterna för allt som skriver.

Mönstret genom alla fem: jag ångrade aldrig en borttagning. Jag ångrade ofta tillägg.

Vanliga misstag i första veckan

Fem saker nästan alla gör vecka ett, så att du kan hoppa över dem:

1. Att skriva 500-radersversionen av CLAUDE.md dag ett. Du vet ännu inte vad Claude gör fel i ert repo. Börja med 15 rader och låt den växa utifrån observerade misslyckanden.
2. Att installera varje intressant MCP-server. Var och en beskattar varje session. Börja med noll och lägg till en när du stöter på en vägg den löser.
3. Att köra --dangerously-skip-permissions på huvudmaskinen för att prompterna irriterade. Allowlista de säkra kommandona i stället; det tar bort 90 % av prompterna utan exponeringen.
4. Att installera skills utan att verifiera att de triggas. Halva värdet av en skill dör i ett vagt beskrivningsfält. Testa varje med en naturlig förfrågan, utan att nämna skillens namn.
5. Att hålla konfigen utanför repot. Är inte projektets CLAUDE.md och settings.json committade återskapar varje kollega din setup dåligt ur minnet.

Underhåll: vad du bör se över efter varje Claude-release

En setup finjusterad för en modellversion driver iväg vid nästa. Efter varje betydande Claude-release, lägg 20 minuter på fyra kontroller.

Läs om din CLAUDE.md och ta bort regler den nya modellen inte längre behöver. Modelluppgraderingar gör regelbundet instruktioner överflödiga; regeln "kör alltid linter" du skrev för ett år sedan kan nu vara standardbeteende du betalar tokens för att upprepa.

Testa om dina skill-triggers. Triggermatchning är modellbeteende, inte nyckelordsmatchning, så en beskrivning som triggade tillförlitligt på en modell kan bli tyst på nästa. Vår katalog omtestar toppskills efter större releaser, och varje skillsida bär det aktuella betyget.

Mät om ditt context-overhead. Nya releaser ändrar ibland hur MCP-toolbeskrivningar räknas eller cachas. Effektivitetsverktygen på vår lista över effektivitetsskills är dit vi pekar folk som vill granska vad som faktiskt bränner deras budget; flera skills i den kategorin finns just för den här kontrollen.

Och kolla changeloggen för ändringar i permissions-modellen innan teamets inställningar tyst betyder något annat. Det tar fem minuter och har räddat oss två gånger.

Vanliga frågor

Är 30 minuter realistiskt, ärligt talat?

För lager 1 till 5 som skrivet, ja, vi har tagit tid på det med nyanställda. Det som tar längre tid är finjusteringen: din CLAUDE.md når sin stabila form efter två till tre veckor av att fånga Claudes återkommande misstag. Budgetera 30 minuter för bygget och räkna med några minuters finjustering per dag de första två veckorna.

Behöver jag MCP-servrar alls?

Många starka setups kör noll. Lever ditt arbete i repot (kod, tester, dokumentation) täcker skills plus CLI-verktyg det. MCP förtjänar sin kostnad när Claude behöver levande åtkomst till något externt, och en databas är det vanligaste genuina fallet. Är du osäker, börja utan och lägg till servern första gången du känner väggen.

Ska CLAUDE.md vara global eller per projekt?

Båda, med olika innehåll. Global (~/.claude/CLAUDE.md) bär dina personliga preferenser och gäller överallt. Per projekt bär build-kommandon och konventioner, och hör hemma i git så att hela teamet delar den. Misstaget är att lägga projektfakta i den globala filen, där de förorenar varje annat projekts sessioner.

Hur många skills är för många?

Tokenmässigt är taket högt: även 50 skills kostar bara några tusen tokens stående metadata. Det praktiska taket är lägre eftersom skills med överlappande beskrivningar börjar konkurrera om samma triggers. Vi kör nio. Över 15 eller så bör du gallra det som inte triggats på en månad i stället för att lägga till.

Kan jag hoppa över permissions-lagret om jag jobbar i en sandlåda?

Är sandlådan genuint engångs, inga credentials, inga monterade volymer du bryr dig om, då ja, och --dangerously-skip-permissions finns för precis det. Lagret spelar roll på maskiner med riktiga hemligheter. De flestas "sandlåda" är en laptop med produktions-AWS-nycklar i en dotfile, vilket inte är en sandlåda.