Den bedste Claude Code-opsætning i 2026 (30 min)

Hver Claude Code-opsætning, vi har gennemgået, falder i en af to fælder. Den første er bar standard: ingen CLAUDE.md, ingen skills, tilladelsesprompts ved hver kommando, og brugeren undrer sig over, hvorfor Claude bliver ved med at glemme, hvordan projektet bygges. Den anden er den overkonfigurerede maskine: 40 skills, 9 MCP-servere, en CLAUDE.md på størrelse med en semesteropgave, og et kontekstvindue der er halvt brugt op, før den første prompt overhovedet er skrevet.

Den gode opsætning ligger midt imellem, og det tager omkring 30 minutter at bygge den, hvis du gør lagene i den rigtige rækkefølge. Den rækkefølge betyder noget. Skills forudsætter en fungerende installation. Beslutninger om tilladelser afhænger af, hvilke MCP-servere du kører. Opdelingen mellem projekt og global konfiguration giver kun mening, når du ved, hvad du deler op. Dette er guiden, vi giver nye SkillProof-kolleger på deres første dag, med de dele fjernet, som vi fik galt i løbet af seks måneder.

Lag 1: installation og login, fem minutter

Det har du sikkert allerede gjort, så jeg holder det kort.

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

Ved første kørsel guider /login dig gennem loginprocessen. Du har to betalingsveje: et Claude-abonnement (Pro eller Max) eller en API-nøgle med betaling per token. Hvis du koder med Claude dagligt, er abonnementet næsten altid billigere; API-fakturering på tunge agentiske sessioner løber hurtigere op, end folk regner med. Er du på et team, så tjek om jeres organisation har en Claude for Work-plads, før du brænder en personlig API-nøgle af.

Verificér med noget trivielt ("hvad laver dette repo?") og bekræft, at Claude kan læse dine filer. Det er hele laget. Alt nedenfor er, hvor opsætninger reelt begynder at divergere.

Lag 2: en CLAUDE.md, der er sine tokens værd

CLAUDE.md er en markdown-fil, som Claude læser ind i konteksten ved starten af hver session i det projekt. Hver session, uanset om indholdet er relevant eller ej. Den indlæsningsadfærd afgør alt om, hvad der hører hjemme i den.

Hvad der hører hjemme: fakta, der gælder for stort set alle sessioner. Build- og testkommandoer. To-sætnings-versionen af jeres arkitektur. Konventioner, Claude bliver ved med at få galt uden at blive fortalt det (jeres import-rækkefølge, jeres commit-format). Hvor ligene er begravet: det udfasede modul, ingen bør røre, config-filen der ser ubrugt ud, men ikke er det.

Hvad der ikke hører hjemme: proceduremæssig viden, du kun sjældent har brug for. Hvordan man skriver en database-migration. Jeres release-tjekliste. Husstilen for kundemails. Hver af dem gælder for måske 5 % af sessionerne, og i CLAUDE.md betaler du for dem i de andre 95 % også. Det materiale bør være en skill (næste lag), som kun indlæses, når den udløses.

Vores tommelfingerregel efter at have testet dette på vores eget repo: er din CLAUDE.md over 60 linjer, skal noget i den flyttes ud. Vores startede på 400 linjer, fordi vi behandlede den som dokumentation. Claude fulgte den værre, ikke bedre, fordi signalet druknede. Den komprimerede version, omkring 50 linjer med kommandoer og hårde begrænsninger, bliver adlydt næsten hver gang.

Skriv det første udkast på ti minutter og stop der. Du vil finpudse den i ugevis, efterhånden som du opdager, at Claude gentager fejl; den iterative løkke er selve metoden. Den fulde gennemgang, inklusive de antimønstre vi ser i indsendte filer fra læsere, er i vores guide til CLAUDE.md.

Lag 3: skills, laget de fleste springer over

Dette er laget, der adskiller en opsætning fra en installation, og det er det, de fleste aldrig rører. En skill er en mappe med en SKILL.md-fil, der lærer Claude en måde at arbejde på. Den koster cirka 100 tokens metadata i hvile og indlæser først sine fulde instruktioner, når en opgave matcher dens beskrivelse. Installeret én gang gælder den for evigt, på tværs af alle sessioner.

Folk springer dette lag over af en rationel grund: omkring halvdelen af community-skills på GitHub fejler ved første installation. Vi ved det, fordi at installere og teste dem er hele vores forretning. Hver skill i SkillProof-kataloget gennemgår en installation på en ren maskine og trigger-tjek, hvorefter rigtige opgaver køres mod en baseline uden skill, før den får en dom. Af de 73 skills, vi har katalogiseret indtil videre, bestod 35.

Til en udviklers opsætning er her de fem, du skal installere først, med score fra vores testkørsler:

1. Test-Driven Development, 9,6. Tvinger streng rød-grøn-refaktor: fejlende test først, minimal implementering, så oprydning. I vores session med tre features sprang den aldrig cyklussen over, selv når vi prøvede at overtale den til det.
2. Systematic Debugging, 9,6. Erstatter gæt-og-prøv-rettelser med en hypotese-test-verificér-løkke. Den fandt rodårsagen til en race condition, som Claude tidligere havde "rettet" tre gange ved at gætte.
3. Frontend Design, 9,6. Det største før/efter-spring, vi har målt på nogen skill. Samme landingsside-brief, kørt to gange: baseline gav det neon-gradient-alt-centreret-look, versionen med skill havde en reel typografisk skala og en palet, der virkede valgt.
4. Memory Management, 9,2. Giver Claude en vedvarende hukommelse på tværs af sessioner. Over en uges test huskede den pålideligt projektbeslutninger og præferencer, og genkaldelsen forblev præcis, efterhånden som lageret voksede.
5. Webapp Testing, 8,8. Claude styrer din app i en rigtig browser via Playwright og rapporterer, hvad der går i stykker. Den fangede en regression, vores enhedstests overså.

De to første kommer fra Jesse Vincents Superpowers-samling (/plugin marketplace add obra/superpowers-marketplace, derefter /plugin install superpowers). Frontend Design leveres i Anthropics officielle skills-repo og kopieres direkte ind i ~/.claude/skills/. Nøjagtige trin, inklusive de fejltyper der æder folks første time, er i installationsguiden. Efter installation genstarter du Claude Code og tester hver trigger ved at bede om arbejdet uden at nævne skillen ved navn. Sker der ikke synligt noget, udløses skillen ikke, og en installeret skill, der aldrig udløses, er bare en mappe.

Peger dit arbejde en anden vej, rangerer vores bedste kodningsskills hele kategorien, opdateret efterhånden som nye testkørsler lander.

Lag 4: MCP-servere, kun dem du rent faktisk bruger

MCP-servere forbinder Claude med ting uden for repoet: din database, dit issue-tracker-system, en live browser. De er kraftfulde, og de er den dyreste post på dit kontekstbudget. Hver tilsluttede server injicerer sine værktøjsdefinitioner i hver session, brugt eller ej, og en enkelt snakkesalig server kan koste flere faste tokens end 50 installerede skills tilsammen. Vi målte det i guiden om token-omkostninger, og tallene ændrede, hvordan vi konfigurerer vores egne maskiner.

Så barren for en MCP-server bør være høj: den fortjener kun en plads, hvis Claude skal nå noget, den ellers ikke kan. Tre plejer at bestå den test for udviklere:

En databaseserver (Postgres eller hvad I nu kører). At Claude skriver forespørgsler mod jeres rigtige skema i stedet for et gættet, er et andet produkt. Dette er den enkeltvis mest værdifulde MCP-forbindelse for de fleste teams.

Browserautomatisering (Playwright MCP), hvis I bygger UI og ikke bruger Webapp Testing-skillens egen opsætning. At se den rendrede side slår at udlede den fra JSX hver gang.

Jeres issue-tracker, men kun hvis I faktisk arbejder ticket-for-ticket inde i Claude Code. Kigger I kun på Linear to gange om dagen, klarer browseren det, og tokens er det ikke værd.

Læg mærke til, hvad der mangler: GitHub MCP-serveren. gh-CLI'en gør alt det samme, Claude ved allerede, hvordan den bruges, og den koster nul faste tokens. Dette substitutionsmønster generaliserer. Før du tilføjer nogen server, så spørg om et CLI-værktøj, Claude kan kalde, giver dig samme rækkevidde gratis. Og hvis du overvejer, om et problem overhovedet kræver MCP eller bare en skill, står beslutningsreglen i skills vs. MCP: skills ændrer, hvad Claude ved, hvordan man gør; MCP ændrer, hvad den kan røre.

Lag 5: tilladelser og sikkerhedsindstillinger, der er værd at ændre

Standardoplevelsen for tilladelser er en prompt ved næsten hver kommando, hvilket træner folk til reflekstrykkende at klikke "tillad". Det er det værst tænkelige udfald: al friktionen, ingen af sikkerheden. To ændringer retter det.

Først, tillad-list de kommandoer, du alligevel ville godkende. 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 andet, læg mærke til deny-blokken, for det er den halvdel folk springer over. Claude har ingen forretning i at læse din .env, og en deny-regel gør det til en egenskab ved systemet i stedet for et håb. Kører du MCP-servere eller skills fra tredjeparter, betyder det endnu mere, da en ondsindet instruktion ikke kan eksfiltrere det, harnesset ikke læser. Vores sikkerhedsguide dækker revisionssiden.

Om --dangerously-skip-permissions: flagnavnet er ærligt. Inde i en engangscontainer uden legitimationsoplysninger er det en fin måde at køre lange, ubemandede jobs på. På din bærbare, med dine SSH-nøgler og dine indloggede browsersessioner, er det sådan, du ender med at optræde i en postmortem. Vi bruger det i CI-sandkasser og ingen andre steder.

Per-projekt vs. globalt: hvor hver del hører hjemme

Alt ovenstående findes på to niveauer, og at blande dem sammen er det mest almindelige konfigurationsrod, vi ser. Opdelingen:

Del	Global (~/.claude/)	Per projekt (.claude/ i repoet)
CLAUDE.md	Din personlige stil: svarlængde, sprog, kæpheste	Build-kommandoer, arkitektur, projektkonventioner (commit denne)
Skills	Alt generelt: debugging, TDD, skrivning	Kun teamspecifikke arbejdsgange
Indstillinger	Din personlige allow-liste	Teamets allow- og deny-regler (commit denne)
settings.local.json	—	Dine maskinspecifikke overstyringer (gitignore denne)
MCP-servere	Servere du bruger overalt	Projektets .mcp.json, så kolleger får samme forbindelser

Princippet: alt en kollega ville have brug for, hører til i repoet; alt der handler om dig, hører til globalt. Gevinsten viser sig, når en ny person kloner projektet, og Claude allerede kender build-kommandoerne og konventionerne, med databaseforbindelsen klar. Deres lag 2 og halvdelen af lag 4 kommer gratis med.

Min opsætning efter seks måneder

Til kalibrering, det der reelt overlever på min maskine: en 54 linjers projekt-CLAUDE.md, ni skills, to MCP-servere (Postgres og Playwright) og tilladelsesblokken ovenfor. Opsætningssessioner føles identiske med for seks måneder siden; forskellen er alt det, jeg har slettet.

Fjernelserne lærte mig mere end tilføjelserne:

Fjernede GitHub MCP-serveren. Beholdt den i fire måneder af ren inerti. Dens værktøjsdefinitioner kostede tusindvis af faste tokens per session, og gh klarede det samme arbejde. Intet blev ringere. Denne ene sletning betalte for tiden, det tog at skrive denne artikel.

Fjernede en hukommelses-MCP-server til fordel for Memory Management-skillen. Serveren var endnu en proces at passe og endnu et login at vedligeholde. Skillen klarer jobbet i almindelige filer, jeg selv kan læse og redigere. Når hukommelsen opfører sig underligt, åbner jeg markdown-filen og retter den, hvilket jeg aldrig kunne med et uigennemsigtigt lager.

Skar CLAUDE.md fra 400 linjer til 54. Den lange version læste som god dokumentation og performede som støj. Overholdelse af de regler, der betød noget, gik op, da reglerne, der ikke gjorde, blev slettet. Jeg behandler nu hver linje som husleje.

Afinstallerede 19 ud af 28 skills. De fleste var "kunne være nyttige"-installationer, der aldrig udløstes i rigtigt arbejde. Doven indlæsning betyder, at de koster lidt, men overlappende beskrivelser forårsagede to reelle trigger-konflikter, og revisionen der fandt dem var trættende. Ni skills, der udløses ugentligt, slår 28, der mest ikke gør.

Rullede en blanket Bash(*)-tilladelsesregel tilbage. Tilføjede den i en deadline-uge, beholdt den for længe. Den dag Claude selvsikkert kørte en destruktiv migration mod en udviklingsdatabase, der viste sig at være mindre disponibel end mærket, satte jeg prompterne tilbage for alt, der skriver.

Mønstret på tværs af alle fem: jeg fortrød aldrig en fjernelse. Jeg fortrød ofte tilføjelser.

Almindelige fejl i første uge

Fem ting, næsten alle gør i uge et, så du kan springe dem over:

1. At skrive den 500-linjers CLAUDE.md på dag ét. Du ved endnu ikke, hvad Claude får galt i dit repo. Start med 15 linjer og lad den vokse fra observerede fejl.
2. At installere alle interessante MCP-servere. Hver enkelt beskatter hver session. Start med nul og tilføj én, når du rammer en mur, den løser.
3. At køre --dangerously-skip-permissions på din hovedmaskine, fordi prompterne generede dig. Tillad-list de sikre kommandoer i stedet; det fjerner 90 % af prompterne uden eksponeringen.
4. At installere skills og aldrig verificere, at de udløses. Halvdelen af en skills værdi dør i et vagt beskrivelsesfelt. Test hver enkelt med en naturlig forespørgsel, uden at nævne skillnavne.
5. At holde config uden for repoet. Er jeres projekt-CLAUDE.md og settings.json ikke committet, genopbygger hver kollega jeres opsætning dårligt fra hukommelsen.

Vedligeholdelse: hvad du skal genbesøge efter hver Claude-udgivelse

En opsætning tunet til én modelversion driver på den næste. Efter hver væsentlig Claude-udgivelse, brug 20 minutter på fire tjek.

Genlæs din CLAUDE.md og slet regler, den nye model ikke længere behøver. Modelopgraderinger gør regelmæssigt instruktioner overflødige; "kør altid linteren"-reglen, du skrev for et år siden, kan nu være standardadfærd, du betaler tokens for at genfortælle.

Gentest dine skill-triggere. Trigger-matching er modeladfærd, ikke nøgleordsmatching, så en beskrivelse, der udløste pålideligt på én model, kan gå stille på den næste. Vores katalog gentester topskills efter store udgivelser, og de enkelte skill-sider bærer den aktuelle dom.

Genmål din kontekstoverhead. Nye udgivelser ændrer nogle gange, hvordan MCP-værktøjsdefinitioner tælles eller caches. Effektivitetsværktøjerne på vores liste over effektivitetsskills er, hvor vi henviser folk, der vil revidere, hvad der reelt bruger deres budget; flere skills i den kategori findes netop til dette tjek.

Og tjek changelog for ændringer i tilladelsesmodellen, før teamets indstillinger stille og roligt kommer til at betyde noget andet. Det tager fem minutter og har reddet os to gange.

Ofte stillede spørgsmål

Er 30 minutter realistisk, ærligt talt?

For lag 1 til 5 som skrevet, ja, vi har timet det med nye ansatte. Det, der tager længere tid, er finjusteringen: din CLAUDE.md når sin stabile form efter to-tre ugers observation af Claudes gentagne fejl. Budgetter 30 minutter til opbygningen og forvent et par minutters finpudsning per dag de første to uger.

Har jeg overhovedet brug for MCP-servere?

Masser af stærke opsætninger kører med nul. Ligger dit arbejde i repoet (kode, tests, docs), dækker skills plus CLI-værktøjer det. MCP fortjener sin pris, når Claude har brug for levende adgang til noget eksternt, og en database er det mest almindelige reelle tilfælde. I tvivlstilfælde, start uden og tilføj serveren første gang du mærker muren.

Skal CLAUDE.md være global eller per projekt?

Begge dele, med forskelligt indhold. Global (~/.claude/CLAUDE.md) bærer dine personlige præferencer og gælder overalt. Per projekt bærer build-kommandoer og konventioner, og hører hjemme i git, så hele teamet deler den. Fejlen er at putte projektfakta i den globale fil, hvor de forurener alle andre projekters sessioner.

Hvor mange skills er for mange?

Tokenmæssigt er loftet højt: selv 50 skills koster kun et par tusind tokens fast metadata. Det praktiske loft er lavere, fordi skills med overlappende beskrivelser begynder at konkurrere om de samme triggere. Vi kører ni. Over cirka 15 bør du beskære det, der ikke er udløst i en måned, i stedet for at tilføje mere.

Kan jeg springe tilladelseslaget over, hvis jeg arbejder i en sandkasse?

Er sandkassen reelt disponibel, ingen legitimationsoplysninger, ingen monterede diske du bekymrer dig om, så ja, og --dangerously-skip-permissions findes netop til det. Laget betyder noget på maskiner med rigtige hemmeligheder. De fleste folks "sandkasse" er en bærbar med deres produktions-AWS-nøgler i en dotfile, hvilket ikke er en sandkasse.