De beste Claude Code setup voor 2026 (30 minuten)

Elke Claude Code setup die ik heb bekeken valt in een van twee faalmodi. De eerste is kaal standaard: geen CLAUDE.md, geen skills, permissie-prompts bij elk commando, en de gebruiker die zich afvraagt waarom Claude steeds vergeet hoe zijn project bouwt. De tweede is de overgeconfigureerde machine: 40 skills, 9 MCP-servers, een CLAUDE.md zo lang als een scriptie, en een contextvenster dat al half vol zit voor de eerste prompt.

De goede setup zit daartussenin, en je bouwt hem in ongeveer 30 minuten als je de lagen in afhankelijkheidsvolgorde doorloopt. Die volgorde is belangrijk. Skills gaan uit van een werkende installatie. Permissiekeuzes hangen af van welke MCP-servers je draait. De verdeling per project versus globaal is pas zinvol als je weet wat je opsplitst. Dit is de gids die we nieuwe SkillProof-collega's op dag één geven, met de onderdelen die we in zes maanden fout deden eruit gehaald.

Laag 1: installeren en inloggen, vijf minuten

Dit heb je waarschijnlijk al gedaan, dus ik houd het kort.

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

Bij de eerste run leidt /login je door het inloggen. Je hebt twee betaalroutes: een Claude-abonnement (Pro of Max) of een API-key met pay-per-token facturatie. Codeer je dagelijks met Claude, dan is het abonnement bijna altijd goedkoper; API-facturatie bij zware agentic sessies loopt sneller op dan mensen verwachten. Zit je in een team, check dan of je organisatie een Claude for Work-seat heeft voordat je een persoonlijke API-key opstookt.

Verifieer met iets triviaals ("wat doet deze repo?") en bevestig dat Claude je bestanden kan lezen. Dat is de hele laag. Alles hieronder is waar setups echt uit elkaar gaan lopen.

Laag 2: een CLAUDE.md die zijn tokens verdient

CLAUDE.md is een markdown-bestand dat Claude bij elke sessie in dat project in de context inleest. Elke sessie, of de inhoud nu relevant is of niet. Dat laadgedrag bepaalt alles over wat erin hoort.

Wat erin hoort: feiten die voor bijna elke sessie gelden. Build- en testcommando's. De versie van je architectuur in twee zinnen. Conventies die Claude blijft misdoen zonder dat je het zegt (je import-volgorde, je commit-formaat). Waar de lijken begraven liggen: de verouderde module die niemand mag aanraken, het configbestand dat ongebruikt lijkt maar dat niet is.

Wat er niet in hoort: procedurele kennis die je af en toe nodig hebt. Hoe je een databasemigratie schrijft. Je release-checklist. De huisstijl voor klant-e-mails. Elk daarvan is relevant voor misschien 5% van de sessies, en in CLAUDE.md betaal je ervoor in de andere 95% ook. Dat materiaal wil een skill zijn (volgende laag), die alleen laadt wanneer getriggerd.

Onze vuistregel na het testen op onze eigen repo: is je CLAUDE.md langer dan 60 regels, dan moet er iets uit. Die van ons begon op 400 regels omdat we het als documentatie behandelden. Claude volgde het slechter, niet beter, omdat het signaal verdronk. De ingekorte versie, zo'n 50 regels commando's en harde randvoorwaarden, wordt bijna altijd opgevolgd.

Schrijf de eerste versie in tien minuten en stop dan. Je verfijnt hem wekenlang terwijl je Claude betrapt op herhaalde fouten; die iteratieve cyclus is de eigenlijke methode. De volledige behandeling, inclusief de anti-patronen die we in door lezers ingestuurde bestanden zien, staat in onze CLAUDE.md-gids.

Laag 3: skills, de laag die de meesten overslaan

Dit is de laag die een setup onderscheidt van een installatie, en het is degene die de meeste mensen nooit aanraken. Een skill is een map met een SKILL.md-bestand die Claude een manier van werken aanleert. Hij kost ongeveer 100 tokens aan metadata terwijl hij inactief is en laadt zijn volledige instructies alleen wanneer een taak bij zijn beschrijving past. Eenmaal geïnstalleerd, geldt hij voor altijd, in elke sessie.

Mensen slaan deze laag over om een rationele reden: ongeveer de helft van de community-skills op GitHub faalt bij de eerste installatie. We weten dat omdat het installeren en testen ervan ons hele bedrijf is. Elke skill in de SkillProof-catalogus krijgt een installatie op een schone machine en trigger-checks, waarna echte taken tegen een baseline zonder skill draaien, voordat er een oordeel volgt. Van de 73 skills die we tot nu toe hebben gecatalogiseerd, zijn er 35 geslaagd.

Voor een developer-setup zijn dit de vijf om als eerste te installeren, met scores uit onze testruns:

1. Test-Driven Development, 9,6. Dwingt strikte red-green-refactor af: eerst een falende test, dan minimale implementatie, dan opruimen. In onze sessie met drie features sloeg hij de cyclus nooit over, zelfs niet toen we probeerden hem ervan te overtuigen dat wel te doen.
2. Systematic Debugging, 9,6. Vervangt gok-en-check-fixes door een hypothese-test-verifieer-cyclus. Hij herleidde de oorzaak van een race condition die Claude eerder drie keer had "opgelost" door te gokken.
3. Frontend Design, 9,6. Het grootste voor/na-verschil dat we ooit bij een skill hebben gemeten. Dezelfde landingspagina-briefing, twee keer uitgevoerd: de baseline leverde de neon-gradient-alles-gecentreerd-look op, de versie met skill had een echte typeschaal en een palet dat gekozen leek.
4. Memory Management, 9,2. Geeft Claude een persistent geheugen over sessies heen. Tijdens een week testen herinnerde hij zich betrouwbaar projectbeslissingen en voorkeuren, en de herinnering bleef accuraat naarmate de opslag groeide.
5. Webapp Testing, 8,8. Claude bestuurt je app in een echte browser via Playwright en meldt wat er stuk is. Hij ving een regressie op die onze unittests misten.

De eerste twee komen uit Jesse Vincents Superpowers-collectie (/plugin marketplace add obra/superpowers-marketplace, dan /plugin install superpowers). Frontend Design zit in Anthropics officiële skills-repo en kopieer je direct naar ~/.claude/skills/. De exacte stappen, inclusief de faalpatronen die mensen hun eerste uur kosten, staan in de installatiegids. Herstart Claude Code na installatie en test elke trigger door om het werk te vragen zonder de skill te noemen. Verandert er niets zichtbaar, dan triggert de skill niet, en een geïnstalleerde skill die nooit triggert is gewoon een map.

Ligt jouw werk een andere kant op, dan rangschikt onze lijst met beste coding skills de hele categorie, bijgewerkt zodra nieuwe testruns binnenkomen.

Laag 4: MCP-servers, alleen de servers die je echt gebruikt

MCP-servers verbinden Claude met dingen buiten de repo: je database, je issue tracker, een live browser. Ze zijn krachtig en de duurste post op je contextbudget. Elke verbonden server injecteert zijn tool-definities in elke sessie, gebruikt of niet, en één praatgrage server kan meer standaard tokens kosten dan 50 geïnstalleerde skills samen. We hebben dit gemeten in de gids over tokenkosten, en de cijfers veranderden hoe we onze eigen machines configureren.

De lat voor een MCP-server moet dus hoog liggen: hij verdient een plek alleen als Claude iets moet bereiken dat hij anders niet kan. Drie overleven die toets doorgaans voor developers:

Een databaseserver (Postgres of wat je ook draait). Claude die queries schrijft tegen je echte schema in plaats van een geraden schema is een ander product. Dit is de meest waardevolle MCP-verbinding voor de meeste teams.

Browserautomatisering (Playwright MCP), als je UI shipt en niet de eigen setup van de Webapp Testing-skill gebruikt. De gerenderde pagina zien wint altijd van haar afleiden uit JSX.

Je issue tracker, maar alleen als je echt ticket-voor-ticket binnen Claude Code werkt. Kijk je twee keer per dag in Linear, dan volstaat de browser en zijn de tokens het niet waard.

Let op wat ontbreekt: de GitHub MCP-server. De gh-CLI doet alles wat die doet, Claude weet al hoe hij die moet gebruiken, en het kost nul standaard context. Dit substitutiepatroon generaliseert. Vraag je voordat je een server toevoegt af of een CLI-tool die Claude kan aanroepen je hetzelfde bereik gratis oplevert. En weeg je af of een probleem MCP nodig heeft of gewoon een skill, dan staat de beslisregel in skills versus MCP: skills veranderen wat Claude weet te doen, MCP verandert wat hij kan aanraken.

Laag 5: permissies en veiligheidsinstellingen die de moeite waard zijn om te wijzigen

De standaard permissie-ervaring is een prompt bij bijna elk commando, wat mensen traint om reflexmatig op toestaan te klikken. Dat is het slechtst mogelijke resultaat: alle frictie, geen veiligheid. Twee wijzigingen lossen dit op.

Eerst: zet de commando's die je toch zou goedkeuren op de allowlist. In .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/**)"
    ]
  }
}

Ten tweede: let op het deny-blok, want dat is de helft die mensen overslaan. Claude heeft niets te zoeken in je .env, en een deny-regel maakt dat een eigenschap van het systeem in plaats van een hoop. Draai je MCP-servers of skills van derden, dan telt dit nog zwaarder, want een kwaadaardige instructie kan niet exfiltreren wat de harness niet leest. Onze beveiligingsgids behandelt de audit-kant.

Over --dangerously-skip-permissions: de vlagnaam is eerlijk. Binnen een wegwerpcontainer zonder credentials is het een prima manier om lange onbewaakte taken te draaien. Op je laptop, met je SSH-keys en je ingelogde browsersessies, is het de manier waarop je de hoofdrol krijgt in een post-mortem. Wij gebruiken het in CI-sandboxes en nergens anders.

Per project versus globaal: waar elk onderdeel thuishoort

Alles hierboven bestaat op twee niveaus, en ze door elkaar halen is de meest voorkomende configuratiewarboel die we zien. De verdeling:

Onderdeel	Globaal (~/.claude/)	Per project (.claude/ in de repo)
CLAUDE.md	Jouw persoonlijke stijl: antwoordlengte, talen, ergernissen	Buildcommando's, architectuur, projectconventies (commit dit)
Skills	Alles algemeens: debuggen, TDD, schrijven	Alleen teamspecifieke workflows
Settings	Jouw persoonlijke allowlist	Team-allowlist en deny-regels (commit dit)
settings.local.json	—	Jouw machine-only overrides (gitignore dit)
MCP-servers	Servers die je overal gebruikt	Het .mcp.json van het project, zodat teamgenoten dezelfde verbindingen krijgen

Het principe: alles waar een teamgenoot iets aan zou hebben, gaat in de repo; alles wat over jou gaat, gaat globaal. De winst blijkt zodra iemand nieuw het project kloont en Claude de buildcommando's en conventies al kent, met de databaseverbinding klaar voor gebruik. Hun laag 2 en de helft van laag 4 komen gratis mee.

Mijn setup na zes maanden

Wat er echt overleeft op mijn machine, ter kalibratie: een projectbestand CLAUDE.md van 54 regels, negen skills, twee MCP-servers (Postgres en Playwright), en het permissieblok hierboven. Setupsessies voelen identiek aan zes maanden geleden; het verschil is alles wat ik heb verwijderd.

De verwijderingen leerden me meer dan de toevoegingen:

De GitHub MCP-server verwijderd. Vier maanden aangehouden uit gewoonte. De tool-definities kostten duizenden standaard tokens per sessie en gh deed hetzelfde werk. Niets ging achteruit. Deze ene verwijdering betaalde de tijd terug om dit artikel te schrijven.

Een memory-MCP-server verwijderd ten gunste van de Memory Management-skill. De server was nog een proces om in de gaten te houden en nog een auth om te onderhouden. De skill doet het werk in gewone bestanden die ik zelf kan lezen en bewerken. Als het geheugen zich misdraagt, open ik de markdown en fix ik het, wat ik nooit kon met een ondoorzichtige opslag.

CLAUDE.md teruggebracht van 400 naar 54 regels. De lange versie las als goede documentatie en presteerde als ruis. Naleving van de regels die ertoe deden ging omhoog toen de regels die er niet toe deden werden verwijderd. Ik behandel nu elke regel als huur.

19 van de 28 skills verwijderd. De meeste waren "misschien handig"-installaties die nooit triggerden bij echt werk. Lazy loading betekent dat ze weinig kosten, maar overlappende beschrijvingen veroorzaakten twee echte triggerconflicten, en de audit die ze vond was tijdrovend. Negen skills die wekelijks triggeren verslaan 28 die dat meestal niet doen.

Een algemene Bash(*)-allow-regel teruggedraaid. Toegevoegd tijdens een deadline-week, te lang aangehouden. De dag dat Claude vol vertrouwen een destructieve migratie uitvoerde tegen een dev-database die minder wegwerpbaar bleek dan het label deed vermoeden, zette ik de prompts terug voor alles dat schrijft.

Het patroon door alle vijf heen: ik heb nooit ook maar één verwijdering betreurd. Ik betreurde vaak toevoegingen.

Veelvoorkomende beginnersfouten in de eerste week

Vijf dingen die bijna iedereen in week één doet, zodat jij ze kunt overslaan:

1. De CLAUDE.md van 500 regels op dag één schrijven. Je weet nog niet wat Claude fout doet in jouw repo. Begin met 15 regels en laat het groeien vanuit geconstateerde fouten.
2. Elke interessante MCP-server installeren. Elke server belast elke sessie. Begin met nul en voeg er een toe zodra je tegen een muur aanloopt die hij oplost.
3. --dangerously-skip-permissions draaien op je hoofdmachine omdat de prompts irriteren. Zet de veilige commando's op de allowlist in plaats daarvan; dat elimineert 90% van de prompts zonder het risico.
4. Skills installeren en nooit verifiëren of ze triggeren. De helft van de waarde van een skill sterft in een vaag beschrijvingsveld. Test elke skill met een natuurlijk verzoek, zonder de skill te noemen.
5. Config buiten de repo houden. Zit je project-CLAUDE.md en settings.json niet in git, dan herbouwt elke teamgenoot je setup slecht uit het geheugen.

Onderhoud: wat je na elke Claude-release opnieuw bekijkt

Een setup afgestemd op één modelversie drift af bij de volgende. Besteed na elke belangrijke Claude-release 20 minuten aan vier checks.

Lees je CLAUDE.md opnieuw en verwijder regels die het nieuwe model niet meer nodig heeft. Modelupgrades maken regelmatig instructies overbodig; de regel "draai altijd de linter" die je een jaar geleden schreef, is nu misschien standaardgedrag waar je tokens voor betaalt om het te herhalen.

Test je skill-triggers opnieuw. Triggermatching is modelgedrag, geen keyword-matching, dus een beschrijving die betrouwbaar triggerde op één model kan stil vallen op het volgende. Onze catalogus test topskills opnieuw na grote releases, en de pagina's per skill dragen het actuele oordeel.

Meet je context-overhead opnieuw. Nieuwe releases veranderen soms hoe MCP-tool-definities worden geteld of gecachet. De efficiëntietooling op onze lijst met efficiëntieskills is waar we mensen naartoe sturen die willen auditen wat hun budget echt opsoupeert; verschillende skills in die categorie bestaan precies voor deze check.

En controleer de changelog op wijzigingen in het permissiemodel voordat de settings van je team stilletjes iets anders gaan betekenen. Dit kost vijf minuten en heeft ons al twee keer gered.

Veelgestelde vragen

Is 30 minuten realistisch, eerlijk gezegd?

Voor lagen 1 tot en met 5 zoals beschreven, ja, we hebben het getimed met nieuwe collega's. Wat langer duurt is het afstemmen: je CLAUDE.md bereikt zijn stabiele vorm na twee tot drie weken waarin je Claudes herhaalde fouten opvangt. Begroot 30 minuten voor de bouw en verwacht een paar minuten verfijning per dag gedurende de eerste twee weken.

Heb ik überhaupt MCP-servers nodig?

Genoeg sterke setups draaien er nul. Leeft je werk in de repo (code, tests, docs), dan dekken skills plus CLI-tools het. MCP verdient zijn kosten als Claude live toegang nodig heeft tot iets externs, en een database is het meest voorkomende echte geval. Twijfel je, begin dan zonder en voeg de server toe zodra je de muur voelt.

Moet CLAUDE.md globaal zijn of per project?

Beide, met verschillende inhoud. Globaal (~/.claude/CLAUDE.md) draagt je persoonlijke voorkeuren en geldt overal. Per project draagt buildcommando's en conventies, en hoort in git zodat het hele team het deelt. De fout is projectfeiten in het globale bestand zetten, waar ze elke andere sessie van elk ander project vervuilen.

Hoeveel skills is te veel?

Qua tokens ligt het plafond hoog: zelfs 50 skills kosten maar een paar duizend tokens aan standaard metadata. Het praktische plafond ligt lager omdat skills met overlappende beschrijvingen om dezelfde triggers gaan concurreren. Wij draaien er negen. Boven de 15 of zo moet je gaan snoeien in wat een maand niet getriggerd heeft in plaats van toe te voegen.

Kan ik de permissielaag overslaan als ik in een sandbox werk?

Is de sandbox echt wegwerpbaar, geen credentials, geen gemounte volumes waar je om geeft, dan wel, en --dangerously-skip-permissions bestaat precies daarvoor. De laag telt op machines met echte secrets. De "sandbox" van de meeste mensen is een laptop met hun productie-AWS-keys in een dotfile, en dat is geen sandbox.