Det beste Claude Code-oppsettet for 2026 (30 minutter)

Hvert Claude Code-oppsett vi har vurdert, havner i en av to feilmodus. Den første er bar standard: ingen CLAUDE.md, ingen skills, tillatelsesspørsmål på hver eneste kommando, og brukeren som lurer på hvorfor Claude stadig glemmer hvordan prosjektet bygges. Den andre er den overkonfigurerte maskinen: 40 skills, 9 MCP-servere, en CLAUDE.md på lengde med en semesteroppgave, og et kontekstvindu som er halvfullt før første prompt.

Det gode oppsettet ligger et sted mellom disse, og det tar rundt 30 minutter å bygge hvis du gjør lagene i riktig rekkefølge. Den rekkefølgen betyr noe. Skills forutsetter en fungerende installasjon. Tillatelsesvalg avhenger av hvilke MCP-servere du kjører. Oppdelingen mellom prosjekt og global konfig gir først mening når du vet hva du deler opp. Dette er guiden vi gir nye SkillProof-kolleger på dag én, med delene vi gjorde feil de siste seks månedene fjernet.

Lag 1: installasjon og innlogging, fem minutter

Du har sannsynligvis gjort dette allerede, så jeg holder det kort.

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

Ved første kjøring guider /login deg gjennom innloggingen. Du har to betalingsveier: et Claude-abonnement (Pro eller Max) eller en API-nøkkel med betaling per token. Koder du med Claude daglig, er abonnementet nesten alltid billigst; API-fakturering på tunge agentiske økter løper fort opp mer enn folk forventer. Jobber du i et team, sjekk om organisasjonen har en Claude for Work-plass før du bruker en personlig API-nøkkel.

Verifiser med noe trivielt ("hva gjør dette repoet?") og bekreft at Claude kan lese filene dine. Det er hele laget. Alt under er der oppsettene faktisk begynner å skille lag.

Lag 2: en CLAUDE.md som fortjener tokenene sine

CLAUDE.md er en markdown-fil Claude leser inn i konteksten ved starten av hver økt i det prosjektet. Hver eneste økt, uansett om innholdet er relevant eller ikke. Den lastemåten avgjør alt om hva som hører hjemme der.

Det som hører hjemme: fakta som gjelder for nesten hver økt. Bygge- og testkommandoer. Arkitekturen din i to setninger. Konvensjoner Claude stadig bommer på uten å bli fortalt om det (importrekkefølgen din, commit-formatet ditt). Hvor likene ligger begravd: den utdaterte modulen ingen skal røre, konfigfilen som ser ubrukt ut, men ikke er det.

Det som ikke hører hjemme: prosedyrekunnskap du bare trenger av og til. Hvordan du skriver en databasemigrasjon. Utgivelseslisten din. Husstilen for kundeeposter. Hver av disse gjelder kanskje 5 % av øktene, og i CLAUDE.md betaler du for dem i de andre 95 % også. Det materialet vil helst være en skill (neste lag), som bare lastes når den trigges.

Vår tommelfingerregel etter å ha testet dette på vårt eget repo: er CLAUDE.md-filen din over 60 linjer, bør noe i den flyttes ut. Vår startet på 400 linjer fordi vi behandlet den som dokumentasjon. Claude fulgte den dårligere, ikke bedre, fordi signalet druknet. Den komprimerte versjonen, rundt 50 linjer med kommandoer og harde begrensninger, blir fulgt nesten hver gang.

Skriv det første utkastet på ti minutter og stopp der. Du kommer til å finpusse det i ukevis etter hvert som du fanger opp Claude som gjentar feil; den iterative loopen er selve metoden. Den fulle gjennomgangen, inkludert antimønstrene vi ser i filer lesere sender inn, finner du i CLAUDE.md-guiden vår.

Lag 3: skills, laget de fleste hopper over

Dette er laget som skiller et oppsett fra en installasjon, og det er laget de fleste aldri rører. En skill er en mappe med en SKILL.md-fil som lærer Claude en arbeidsmåte. Den koster rundt 100 tokens metadata mens den er inaktiv, og laster hele instruksjonssettet sitt bare når en oppgave matcher beskrivelsen. Installert én gang, gjelder den for alltid, i hver eneste økt.

Folk hopper over dette laget av en rasjonell grunn: omtrent halvparten av community-skillsene på GitHub feiler ved første installasjon. Vi vet det fordi å installere og teste dem er hele forretningen vår. Hver skill i SkillProof-katalogen får en installasjon på en ren maskin og triggersjekker, deretter kjøres reelle oppgaver mot en uten-skill-baseline, før den får en dom. Av de 73 skillsene vi har katalogisert så langt, besto 35.

For et utvikleroppsett er dette de fem å installere først, med score fra testkjøringene våre:

1. Test-Driven Development, 9,6. Tvinger fram streng red-green-refactor: feilende test først, minimal implementasjon, så opprydding. I vår treoppgaveøkt hoppet den aldri over syklusen, selv når vi prøvde å snakke den inn i å hoppe over.
2. Systematic Debugging, 9,6. Erstatter gjett-og-sjekk-fiksing med en hypotese-test-verifiser-loop. Den fant rotårsaken til en race condition Claude tidligere hadde «fikset» tre ganger ved å gjette.
3. Frontend Design, 9,6. Det største før/etter-gapet vi har målt på noen skill. Samme landingsside-brief, kjørt to ganger: baseline ga det neon-gradient-alt-sentrert-look, versjonen med skill hadde en ekte typeskala og en palett som virket valgt.
4. Memory Management, 9,2. Gir Claude et vedvarende minne på tvers av økter. Over en uke med testing husket den konsekvent prosjektbeslutninger og preferanser, og gjenkallingen forble presis etter hvert som lageret vokste.
5. Webapp Testing, 8,8. Claude styrer appen din i en ekte nettleser via Playwright og rapporterer hva som går i stykker. Den fanget opp en regresjon enhetstestene våre bommet på.

De to første kommer fra Jesse Vincents Superpowers-samling (/plugin marketplace add obra/superpowers-marketplace, deretter /plugin install superpowers). Frontend Design leveres i Anthropics offisielle skills-repo og kopieres rett inn i ~/.claude/skills/. Nøyaktige steg, inkludert feilmodusene som spiser opp folks første time, finner du i installasjonsguiden. Etter installasjon: restart Claude Code og test hver trigger ved å be om arbeidet uten å nevne skillnavnet. Skjer det ingen synlig endring, trigger ikke skillen, og en installert skill som aldri trigges er bare en mappe.

Går arbeidet ditt i en annen retning, rangerer vår beste kodeskills-liste hele kategorien, oppdatert etter hvert som nye testkjøringer kommer inn.

Lag 4: MCP-servere, bare de du faktisk bruker

MCP-servere kobler Claude til ting utenfor repoet: databasen din, saksbehandlingssystemet ditt, en levende nettleser. De er kraftige, og de er den dyreste posten i kontekstbudsjettet ditt. Hver tilkoblede server injiserer verktøydefinisjonene sine i hver eneste økt, brukt eller ikke, og én pratsom server kan koste mer fast tokenbruk enn 50 installerte skills til sammen. Vi målte dette i tokenkostnadsguiden, og tallene endret hvordan vi konfigurerer våre egne maskiner.

Så terskelen for en MCP-server bør være høy: den fortjener en plass bare hvis Claude trenger å nå noe den ellers ikke kan. Tre pleier å bestå den testen for utviklere:

En databaseserver (Postgres eller det du kjører). At Claude skriver spørringer mot det ekte skjemaet ditt i stedet for et gjettet, er et helt annet produkt. Dette er den enkeltmest verdifulle MCP-koblingen for de fleste team.

Nettleserautomatisering (Playwright MCP), hvis du leverer UI og ikke bruker Webapp Testing-skillens eget oppsett. Å se den rendrede siden slår å gjette seg fram fra JSX hver gang.

Saksbehandlingssystemet ditt, men bare hvis du faktisk jobber sak-for-sak inne i Claude Code. Kikker du innom Linear to ganger om dagen, holder nettleseren og tokenene er ikke verdt det.

Legg merke til hva som mangler: GitHub MCP-serveren. gh-CLI-en gjør alt den gjør, Claude kan allerede bruke den, og den koster null fast kontekst. Dette substitusjonsmønsteret generaliserer. Før du legger til en server, spør om et CLI-verktøy Claude kan kalle gir deg samme rekkevidde gratis. Og lurer du på om et problem trenger MCP i det hele tatt eller bare en skill, ligger beslutningsregelen i skills vs MCP: skills endrer hva Claude vet hvordan det skal gjøre, MCP endrer hva den kan nå.

Lag 5: tillatelser og sikkerhetsinnstillinger verdt å endre

Standard tillatelsesopplevelse er et spørsmål for nesten hver kommando, noe som lærer folk å klikke «tillat» refleksivt. Det er verst tenkelig utfall: all friksjonen, ingen av sikkerheten. To endringer fikser det.

Først, tillat-list kommandoene du ville godkjent uansett. 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/**)"
    ]
  }
}

For det andre, legg merke til deny-blokken, for det er halvparten folk hopper over. Claude har ingenting i .env-filen din å gjøre, og en deny-regel gjør det til en egenskap ved systemet i stedet for et håp. Kjører du MCP-servere eller skills fra tredjeparter, betyr dette enda mer, siden en ondsinnet instruks ikke kan lekke ut det harnesset ikke leser.

Om --dangerously-skip-permissions: flaggnavnet er ærlig. Inne i en engangscontainer uten legitimasjon er det en fin måte å kjøre lange uovervåkede jobber på. På din bærbare, med SSH-nøklene dine og innloggede nettleserøkter, er det slik du ender opp med hovedrolle i en postmortem. Vi bruker det i CI-sandkasser og ingen andre steder.

Prosjekt vs globalt: hvor hver del hører hjemme

Alt over finnes på to nivåer, og å blande dem er den vanligste konfigrotet vi ser. Fordelingen:

Del	Global (~/.claude/)	Per prosjekt (.claude/ i repo)
CLAUDE.md	Din personlige stil: svarlengde, språk, kjepphester	Byggekommandoer, arkitektur, prosjektkonvensjoner (commit denne)
Skills	Alt generelt: feilsøking, TDD, skriving	Kun teamspesifikke arbeidsflyter
Settings	Din personlige tillat-liste	Team-tillatelser og deny-regler (commit denne)
settings.local.json	—	Dine maskinspesifikke overstyringer (gitignore denne)
MCP-servere	Servere du bruker overalt	Prosjektets .mcp.json, slik at kolleger får samme tilkoblinger

Prinsippet: alt en kollega ville trengt går i repoet, alt som handler om deg går globalt. Gevinsten viser seg når noen ny kloner prosjektet og Claude allerede kjenner byggekommandoene og konvensjonene, med databasetilkoblingen klar. Deres lag 2 og halve lag 4 kommer gratis.

Mitt oppsett etter seks måneder

Hva som faktisk overlever på min maskin, til kalibrering: en CLAUDE.md på 54 linjer for prosjektet, ni skills, to MCP-servere (Postgres og Playwright), og tillatelsesblokken over. Oppsettsøkter føles identiske med for seks måneder siden; forskjellen er alt jeg har slettet.

Fjerningene lærte meg mer enn tilføyelsene:

Fjernet GitHub MCP-serveren. Beholdt den i fire måneder av ren treghet. Verktøydefinisjonene dens kostet tusenvis av faste tokens per økt, og gh gjorde samme jobb. Ingenting ble dårligere. Denne ene fjerningen betalte for tiden det tok å skrive denne artikkelen.

Fjernet en minne-MCP-server til fordel for Memory Management-skillen. Serveren var enda en prosess å passe på og enda en innlogging å vedlikeholde. Skillen gjør jobben i vanlige filer jeg kan lese og redigere selv. Når minnet oppfører seg rart, åpner jeg markdown-filen og fikser det, noe jeg aldri kunne gjort med et lukket lager.

Kuttet CLAUDE.md fra 400 linjer til 54. Den lange versjonen leste som god dokumentasjon og fungerte som støy. Etterlevelsen av reglene som betydde noe gikk opp når reglene som ikke betydde noe ble slettet. Jeg behandler nå hver linje som leie.

Avinstallerte 19 av 28 skills. De fleste var «kan være nyttig»-installasjoner som aldri trigget i reelt arbeid. Lat lasting betyr at de koster lite, men overlappende beskrivelser forårsaket to reelle triggerkonflikter, og revisjonen som fant dem var tidkrevende. Ni skills som trigger ukentlig slår 28 som stort sett ikke gjør det.

Rullet tilbake en generell Bash(*)-tillatelsesregel. La den til i en leveringsuke med tidspress, beholdt den for lenge. Dagen Claude selvsikkert kjørte en destruktiv migrering mot en utviklingsdatabase som viste seg å være mindre engangs enn den var merket, satte jeg tilbake spørsmålene for alt som skriver.

Mønsteret på tvers av alle fem: jeg angret aldri en fjerning. Jeg angret ofte tilføyelser.

Vanlige feil i første uke

Fem ting nesten alle gjør i uke én, så du kan hoppe over dem:

1. Å skrive en CLAUDE.md på 500 linjer dag én. Du vet ennå ikke hva Claude bommer på i repoet ditt. Start med 15 linjer og la den vokse ut fra observerte feil.
2. Å installere hver interessante MCP-server. Hver eneste beskatter hver eneste økt. Start med null og legg til én når du treffer en vegg den løser.
3. Å kjøre --dangerously-skip-permissions på hovedmaskinen din fordi spørsmålene irriterte deg. Tillat-list de trygge kommandoene i stedet; det fjerner 90 % av spørsmålene uten eksponeringen.
4. Å installere skills og aldri verifisere at de trigger. Halve verdien av en skill dør i et vagt beskrivelsesfelt. Test hver med en naturlig forespørsel, uten å nevne skillnavn.
5. Å holde konfig utenfor repoet. Er ikke CLAUDE.md og settings.json for prosjektet ditt committet, bygger hver kollega opp oppsettet ditt dårlig fra hukommelsen.

Vedlikehold: hva du bør se over etter hver Claude-utgivelse

Et oppsett tilpasset én modellversjon driver etter hvert på den neste. Etter hver betydelige Claude-utgivelse, bruk 20 minutter på fire sjekker.

Les gjennom CLAUDE.md på nytt og slett regler den nye modellen ikke lenger trenger. Modelloppgraderinger gjør jevnlig instrukser overflødige; «kjør alltid linteren»-regelen du skrev for et år siden er kanskje nå standardoppførsel du betaler tokens for å gjenta.

Test skill-triggerne dine på nytt. Triggermatching er modelloppførsel, ikke nøkkelordmatching, så en beskrivelse som trigget pålitelig på én modell kan bli stille på den neste. Katalogen vår retester toppskillsene etter store utgivelser, og skillsidene bærer gjeldende dom.

Mål kontekstbelastningen på nytt. Nye utgivelser endrer noen ganger hvordan MCP-verktøydefinisjoner telles eller caches. Verktøyene på effektivitetsskills-listen er der vi sender folk som vil revidere hva som faktisk brenner av budsjettet deres; flere skills i den kategorien finnes nettopp for denne sjekken.

Og sjekk endringsloggen for tillatelsesmodell-endringer før teamets settings plutselig betyr noe annet. Dette tar fem minutter og har spart oss to ganger.

Ofte stilte spørsmål

Er 30 minutter realistisk, ærlig talt?

For lag 1 til 5 som beskrevet, ja, vi har tidtatt det med nyansatte. Det som tar lengre tid, er finjusteringen: CLAUDE.md-filen din når sin stabile form etter to-tre uker med å fange opp Claudes gjentatte feil. Sett av 30 minutter til byggingen og forvent noen minutters finpuss per dag de første to ukene.

Trenger jeg MCP-servere i det hele tatt?

Mange solide oppsett kjører null. Ligger arbeidet ditt i repoet (kode, tester, dokumentasjon), dekker skills pluss CLI-verktøy det meste. MCP fortjener kostnaden når Claude trenger levende tilgang til noe eksternt, og en database er det vanligste reelle tilfellet. Er du i tvil, start uten og legg til serveren første gang du kjenner veggen.

Bør CLAUDE.md være global eller per prosjekt?

Begge deler, med forskjellig innhold. Global (~/.claude/CLAUDE.md) bærer dine personlige preferanser og gjelder overalt. Per prosjekt bærer byggekommandoer og konvensjoner, og hører hjemme i git slik at hele teamet deler den. Feilen er å legge prosjektfakta i den globale filen, der de forurenser alle andre prosjekters økter.

Hvor mange skills er for mange?

Tokenmessig er taket høyt: selv 50 skills koster bare noen tusen tokens fast metadata. Det praktiske taket er lavere fordi skills med overlappende beskrivelser begynner å konkurrere om de samme triggerne. Vi kjører ni. Forbi 15 eller så bør du luke ut det som ikke har trigget på en måned i stedet for å legge til mer.

Kan jeg hoppe over tillatelseslaget om jeg jobber i en sandkasse?

Er sandkassen reelt engangs, uten legitimasjon, ingen monterte volumer du bryr deg om, da ja, og --dangerously-skip-permissions finnes nettopp for det. Laget betyr noe på maskiner med ekte hemmeligheter. De fleste sine «sandkasser» er en bærbar med produksjons-AWS-nøkler i en dotfile, som ikke er en sandkasse.