Das beste Claude Code Setup für 2026 (30-Minuten-Guide)

Jedes Claude-Code-Setup, das wir uns angesehen haben, fällt in einen von zwei Fehlermodi. Der erste ist der nackte Standard: keine CLAUDE.md, keine Skills, bei jedem Befehl ein Permission-Prompt, und der Nutzer fragt sich, warum Claude ständig vergisst, wie sein Projekt gebaut wird. Der zweite ist die überkonfigurierte Maschine: 40 Skills, 9 MCP-Server, eine CLAUDE.md von der Länge einer Hausarbeit, und ein Kontextfenster, das schon vor dem ersten Prompt halb aufgebraucht ist.

Das gute Setup liegt dazwischen, und es dauert etwa 30 Minuten, wenn du die Schichten in der richtigen Reihenfolge aufbaust. Diese Reihenfolge ist wichtig. Skills setzen eine funktionierende Installation voraus. Permission-Entscheidungen hängen davon ab, welche MCP-Server du betreibst. Die Aufteilung zwischen Projekt und global ergibt erst Sinn, wenn du weißt, was du überhaupt aufteilst. Das ist der Guide, den wir neuen SkillProof-Teammitgliedern am ersten Tag geben, minus die Fehler, die wir in sechs Monaten selbst gemacht haben.

Schicht 1: Installation und Login, fünf Minuten

Das hast du wahrscheinlich schon erledigt, also halte ich es kurz.

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

Beim ersten Start führt dich /login durch die Authentifizierung. Du hast zwei Abrechnungswege: ein Claude-Abo (Pro oder Max) oder einen API-Key mit Pay-per-Token. Codest du täglich mit Claude, ist das Abo fast immer günstiger; API-Abrechnung summiert sich bei intensiven Agenten-Sessions schneller, als man denkt. Bist du im Team, prüf zuerst, ob dein Unternehmen einen Claude-for-Work-Sitzplatz hat, bevor du einen privaten API-Key verbrennst.

Verifizier mit etwas Trivialem ("was macht dieses Repo?") und bestätige, dass Claude deine Dateien lesen kann. Das ist die ganze Schicht. Alles Weitere ist der Punkt, an dem sich Setups wirklich unterscheiden.

Schicht 2: eine CLAUDE.md, die ihre Tokens verdient

CLAUDE.md ist eine Markdown-Datei, die Claude zu Beginn jeder Session in diesem Projekt in den Kontext lädt. Jede Session, egal ob der Inhalt relevant ist oder nicht. Dieses Ladeverhalten bestimmt alles, was hineingehört.

Was hineingehört: Fakten, die für fast jede Session gelten. Build- und Testbefehle. Die Zwei-Satz-Version deiner Architektur. Konventionen, die Claude ständig falsch macht, wenn man sie nicht nennt (deine Import-Reihenfolge, dein Commit-Format). Wo die Leichen liegen: das deprecated Modul, das niemand anfassen soll, die Config-Datei, die unbenutzt aussieht, es aber nicht ist.

Was nicht hineingehört: prozedurales Wissen, das du nur gelegentlich brauchst. Wie man eine Datenbank-Migration schreibt. Deine Release-Checkliste. Der Hausstil für Kunden-E-Mails. Jedes davon betrifft vielleicht 5 % der Sessions, und in CLAUDE.md bezahlst du dafür in den anderen 95 % mit. Dieses Material will ein Skill sein (nächste Schicht), der nur bei Bedarf lädt.

Unsere Faustregel nach dem Test am eigenen Repo: Ist deine CLAUDE.md über 60 Zeilen lang, sollte etwas davon raus. Unsere begann bei 400 Zeilen, weil wir sie wie Dokumentation behandelt haben. Claude befolgte sie schlechter, nicht besser, weil das Signal im Rauschen unterging. Die komprimierte Version, etwa 50 Zeilen mit Befehlen und harten Constraints, wird fast immer befolgt.

Schreib den ersten Entwurf in zehn Minuten und hör dann auf. Du wirst ihn über Wochen verfeinern, sobald du Claude bei Wiederholungsfehlern ertappst; diese iterative Schleife ist die eigentliche Methode. Die volle Behandlung, inklusive der Antipatterns aus eingereichten Leser-Dateien, steht in unserem CLAUDE.md-Guide.

Schicht 3: Skills, die Schicht, die die meisten überspringen

Das ist die Schicht, die ein Setup von einer bloßen Installation unterscheidet, und die die meisten nie anfassen. Ein Skill ist ein Ordner mit einer SKILL.md-Datei, die Claude eine Arbeitsweise beibringt. Er kostet im Leerlauf rund 100 Tokens Metadaten und lädt seine vollen Anweisungen nur, wenn eine Aufgabe zu seiner Beschreibung passt. Einmal installiert, gilt er für immer, in jeder Session.

Die meisten überspringen diese Schicht aus einem rationalen Grund: etwa die Hälfte der Community-Skills auf GitHub scheitert schon bei der Erstinstallation. Wir wissen das, weil das Installieren und Testen unser ganzes Geschäft ist. Jeder Skill im SkillProof-Katalog bekommt eine Installation auf einer sauberen Maschine, Trigger-Checks, dann echte Aufgaben gegen eine Baseline ohne Skill, bevor er ein Urteil erhält. Von den 73 Skills, die wir bisher katalogisiert haben, haben 35 bestanden.

Für ein Entwickler-Setup sind das die ersten fünf zum Installieren, mit Werten aus unseren Testläufen:

1. Test-Driven Development, 9,6. Erzwingt strikten Red-Green-Refactor-Zyklus: erst ein fehlschlagender Test, dann die minimale Implementierung, dann Aufräumen. In unserer Drei-Feature-Session hat er den Zyklus nie übersprungen, selbst als wir versucht haben, ihn davon abzubringen.
2. Systematic Debugging, 9,6. Ersetzt Rate-und-Prüfe-Fixes durch eine Hypothese-Test-Verifizieren-Schleife. Er hat eine Race Condition auf die Ursache zurückgeführt, die Claude zuvor dreimal durch Raten "gefixt" hatte.
3. Frontend Design, 9,6. Die größte Vorher-Nachher-Lücke, die wir bei irgendeinem Skill gemessen haben. Gleiches Landingpage-Briefing, zweimal ausgeführt: die Baseline produzierte den Neon-Verlauf-alles-zentriert-Look, die Version mit Skill hatte eine echte Typoskala und eine Palette, die wie bewusst gewählt wirkte.
4. Memory Management, 9,2. Gibt Claude ein dauerhaftes Gedächtnis über Sessions hinweg. Über eine Woche Testing hat er Projektentscheidungen und Präferenzen zuverlässig erinnert, und die Trefferquote blieb stabil, während der Speicher wuchs.
5. Webapp Testing, 8,8. Claude steuert deine App in einem echten Browser via Playwright und meldet, was kaputt ist. Er hat eine Regression gefunden, die unsere Unit-Tests übersehen haben.

Die ersten beiden stammen aus Jesse Vincents Superpowers-Sammlung (/plugin marketplace add obra/superpowers-marketplace, dann /plugin install superpowers). Frontend Design ist Teil von Anthropics offiziellem Skills-Repo und wird direkt nach ~/.claude/skills/ kopiert. Die genauen Schritte, inklusive der Fehlermodi, die Leuten die erste Stunde fressen, stehen im Installations-Guide. Nach der Installation startest du Claude Code neu und testest jeden Trigger, indem du um die Arbeit bittest, ohne den Skill zu nennen. Ändert sich sichtbar nichts, feuert der Skill nicht, und ein installierter Skill, der nie feuert, ist nur ein Ordner.

Geht deine Arbeit in eine andere Richtung, listet unsere Liste der besten Coding-Skills die ganze Kategorie, aktualisiert mit jedem neuen Testlauf.

Schicht 4: MCP-Server, nur die, die du wirklich nutzt

MCP-Server verbinden Claude mit Dingen außerhalb des Repos: deiner Datenbank, deinem Issue-Tracker, einem echten Browser. Sie sind mächtig und der teuerste Posten in deinem Kontextbudget. Jeder verbundene Server injiziert seine Tool-Definitionen in jede Session, benutzt oder nicht, und ein einziger geschwätziger Server kann mehr Standing Tokens kosten als 50 installierte Skills zusammen. Wir haben das im Guide zu Token-Kosten gemessen, und die Zahlen haben verändert, wie wir unsere eigenen Maschinen konfigurieren.

Die Messlatte für einen MCP-Server sollte also hoch sein: er verdient sich einen Platz nur, wenn Claude etwas erreichen muss, das es sonst nicht kann. Drei bestehen diesen Test meistens für Entwickler:

Ein Datenbank-Server (Postgres oder was auch immer du betreibst). Claude, das Queries gegen dein echtes Schema schreibt statt gegen ein geratenes, ist ein anderes Produkt. Das ist die wertvollste MCP-Verbindung für die meisten Teams.

Browser-Automatisierung (Playwright MCP), wenn du UI ausliefertst und nicht das eigene Setup des Webapp-Testing-Skills nutzt. Die gerenderte Seite zu sehen schlägt jedes Mal, sie aus JSX zu erraten.

Dein Issue-Tracker, aber nur, wenn du wirklich Ticket für Ticket in Claude Code arbeitest. Schaust du zweimal am Tag in Linear, reicht der Browser, und die Tokens lohnen sich nicht.

Beachte, was fehlt: der GitHub-MCP-Server. Die gh-CLI macht alles, was er macht, Claude weiß bereits, wie man sie benutzt, und sie kostet null Standing Context. Dieses Substitutionsmuster verallgemeinert sich. Bevor du einen Server hinzufügst, frag dich, ob ein CLI-Tool, das Claude aufrufen kann, dir dieselbe Reichweite umsonst verschafft. Und überlegst du, ob ein Problem überhaupt MCP braucht oder nur einen Skill, steht die Entscheidungsregel in Skills vs. MCP: Skills verändern, was Claude zu tun weiß, MCP verändert, was es berühren kann.

Schicht 5: Permissions und Sicherheitseinstellungen, die sich zu ändern lohnen

Das Standard-Permission-Erlebnis ist ein Prompt für fast jeden Befehl, was Leute darauf trainiert, reflexartig auf Erlauben zu klicken. Das ist das schlechtestmögliche Ergebnis: die ganze Reibung, keine Sicherheit. Zwei Änderungen beheben das.

Erstens: allowliste die Befehle, die du sowieso genehmigen würdest. 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/**)"
    ]
  }
}

Zweitens: achte auf den Deny-Block, denn das ist die Hälfte, die die meisten überspringen. Claude hat keinen Grund, deine .env zu lesen, und eine Deny-Regel macht das zu einer Eigenschaft des Systems statt zu einer Hoffnung. Betreibst du MCP-Server oder Skills von Drittanbietern, ist das noch wichtiger, denn eine bösartige Anweisung kann nicht exfiltrieren, was der Harness gar nicht liest. Unser Sicherheits-Guide behandelt die Audit-Seite.

Zu --dangerously-skip-permissions: der Flag-Name ist ehrlich. In einem Wegwerf-Container ohne Zugangsdaten ist es eine gute Art, lange unbeaufsichtigte Jobs laufen zu lassen. Auf deinem Laptop, mit deinen SSH-Keys und deinen eingeloggten Browser-Sessions, ist es der Weg in eine Postmortem-Hauptrolle. Wir nutzen es in CI-Sandboxes und sonst nirgends.

Pro Projekt vs. global: wo welches Teil hingehört

Alles oben existiert auf zwei Ebenen, und sie zu vermischen ist das häufigste Konfigurations-Chaos, das wir sehen. Die Aufteilung:

Teil	Global (~/.claude/)	Pro Projekt (.claude/ im Repo)
CLAUDE.md	Dein persönlicher Stil: Antwortlänge, Sprachen, Marotten	Build-Befehle, Architektur, Projektkonventionen (committen)
Skills	Alles Allgemeine: Debugging, TDD, Schreiben	Nur team-spezifische Workflows
Settings	Deine persönliche Allowlist	Team-Allowlist und Deny-Regeln (committen)
settings.local.json	—	Deine maschinenspezifischen Overrides (gitignore)
MCP-Server	Server, die du überall nutzt	.mcp.json des Projekts, damit Teammitglieder dieselben Verbindungen bekommen

Das Prinzip: Alles, was ein Teammitglied bräuchte, gehört ins Repo, alles, was dich persönlich betrifft, gehört global. Der Nutzen zeigt sich, sobald jemand Neues das Projekt klont und Claude die Build-Befehle und Konventionen schon kennt, mit der Datenbankverbindung startklar. Schicht 2 und die halbe Schicht 4 gibt es für sie gratis dazu.

Mein Setup nach sechs Monaten

Was tatsächlich auf meiner Maschine überlebt, zur Einordnung: eine 54-zeilige Projekt-CLAUDE.md, neun Skills, zwei MCP-Server (Postgres und Playwright) und der Permissions-Block von oben. Setup-Sessions fühlen sich an wie vor sechs Monaten; der Unterschied ist alles, was ich gelöscht habe.

Die Streichungen haben mir mehr beigebracht als die Ergänzungen:

Den GitHub-MCP-Server entfernt. Vier Monate aus reiner Trägheit behalten. Seine Tool-Definitionen kosteten tausende Standing Tokens pro Session, und gh erledigte dieselbe Arbeit. Nichts hat sich verschlechtert. Diese eine Streichung hat die Zeit für diesen Artikel schon wieder reingeholt.

Einen Memory-MCP-Server zugunsten des Memory-Management-Skills entfernt. Der Server war ein weiterer Prozess zum Beaufsichtigen und eine weitere Auth zum Pflegen. Der Skill erledigt den Job in reinen Dateien, die ich selbst lesen und bearbeiten kann. Verhält sich das Gedächtnis daneben, öffne ich das Markdown und korrigiere es, was mit einem undurchsichtigen Speicher nie ging.

CLAUDE.md von 400 auf 54 Zeilen gekürzt. Die lange Version las sich wie gute Dokumentation und performte wie Rauschen. Die Einhaltung der Regeln, die zählten, stieg, als die Regeln, die es nicht taten, gestrichen wurden. Ich behandle jetzt jede Zeile wie Miete.

19 von 28 Skills deinstalliert. Die meisten waren "könnte-nützlich-sein"-Installs, die in echter Arbeit nie gefeuert haben. Lazy Loading heißt, sie kosten wenig, aber überlappende Beschreibungen verursachten zwei echte Trigger-Konflikte, und das Audit, das sie fand, war mühsam. Neun Skills, die wöchentlich feuern, schlagen 28, die es meistens nicht tun.

Eine pauschale Bash(*)-Allow-Regel zurückgerollt. In einer Deadline-Woche hinzugefügt, zu lange behalten. An dem Tag, als Claude selbstbewusst eine destruktive Migration gegen eine Dev-Datenbank fuhr, die sich als weniger wegwerfbar herausstellte als beschriftet, kamen die Prompts für alles Schreibende zurück.

Das Muster durch alle fünf: Eine Streichung habe ich nie bereut. Ergänzungen habe ich häufig bereut.

Häufige Fehler in der ersten Woche

Fünf Dinge, die fast jeder in Woche eins macht, damit du sie überspringen kannst:

1. Die 500-Zeilen-CLAUDE.md am ersten Tag schreiben. Du weißt noch nicht, was Claude in deinem Repo falsch macht. Starte mit 15 Zeilen und lass sie aus beobachteten Fehlern wachsen.
2. Jeden interessanten MCP-Server installieren. Jeder besteuert jede Session. Starte bei null und füge einen hinzu, wenn du gegen eine Wand läufst, die er löst.
3. --dangerously-skip-permissions auf deiner Hauptmaschine laufen lassen, weil die Prompts genervt haben. Allowliste stattdessen die sicheren Befehle; das killt 90 % der Prompts ohne das Risiko.
4. Skills installieren und nie prüfen, ob sie triggern. Die halbe Wirkung eines Skills stirbt in einem vagen Beschreibungsfeld. Teste jeden mit einer natürlichen Anfrage, ohne den Skill-Namen zu nennen.
5. Config nicht im Repo halten. Sind deine Projekt-CLAUDE.md und settings.json nicht committet, baut jedes Teammitglied dein Setup schlecht aus dem Gedächtnis nach.

Wartung: was du nach jedem Claude-Release prüfen solltest

Ein Setup, das für eine Modellversion getunt ist, driftet mit der nächsten. Nach jedem größeren Claude-Release lohnen sich 20 Minuten für vier Checks.

Lies deine CLAUDE.md neu und streich Regeln, die das neue Modell nicht mehr braucht. Modell-Upgrades machen regelmäßig Anweisungen obsolet; die "führ immer den Linter aus"-Regel von vor einem Jahr ist heute vielleicht Standardverhalten, für dessen Wiederholung du Tokens bezahlst.

Teste deine Skill-Trigger neu. Trigger-Matching ist Modellverhalten, kein Keyword-Matching, also kann eine Beschreibung, die bei einem Modell zuverlässig feuerte, beim nächsten verstummen. Unser Katalog testet Top-Skills nach großen Releases neu, und die Skill-Seiten tragen das aktuelle Urteil.

Miss deinen Kontext-Overhead neu. Neue Releases ändern manchmal, wie MCP-Tool-Definitionen gezählt oder gecacht werden. Die Effizienz-Tools auf unserer Liste der Effizienz-Skills sind die Adresse, an die wir Leute verweisen, die prüfen wollen, was wirklich ihr Budget frisst; mehrere Skills in dieser Kategorie existieren genau für diesen Check.

Und prüf den Changelog auf Änderungen am Permission-Modell, bevor die Settings deines Teams stillschweigend etwas anderes bedeuten. Das dauert fünf Minuten und hat uns schon zweimal gerettet.

FAQ

Sind 30 Minuten ehrlich realistisch?

Für die Schichten 1 bis 5 wie beschrieben, ja, wir haben es mit neuen Kolleg:innen gestoppt. Was länger dauert, ist das Feintuning: deine CLAUDE.md erreicht ihre stabile Form nach zwei bis drei Wochen, in denen du Claudes Wiederholungsfehler einfängst. Plane 30 Minuten für den Aufbau ein und erwarte in den ersten zwei Wochen ein paar Minuten Feinschliff pro Tag.

Brauche ich überhaupt MCP-Server?

Jede Menge starker Setups laufen mit null. Lebt deine Arbeit im Repo (Code, Tests, Docs), decken Skills plus CLI-Tools das ab. MCP verdient sich seine Kosten, wenn Claude Live-Zugriff auf etwas Externes braucht, und eine Datenbank ist der häufigste echte Fall. Im Zweifel: erst ohne starten und den Server beim ersten Mal hinzufügen, wenn du die Wand spürst.

Sollte CLAUDE.md global oder pro Projekt sein?

Beides, mit unterschiedlichem Inhalt. Global (~/.claude/CLAUDE.md) trägt deine persönlichen Präferenzen und gilt überall. Pro Projekt trägt Build-Befehle und Konventionen und gehört in Git, damit das ganze Team sie teilt. Der Fehler ist, Projektfakten in die globale Datei zu packen, wo sie jede andere Projekt-Session verschmutzen.

Wie viele Skills sind zu viele?

Token-mäßig ist die Decke hoch: selbst 50 Skills kosten nur ein paar Tausend Tokens Standing-Metadaten. Die praktische Decke ist niedriger, weil Skills mit überlappenden Beschreibungen anfangen, um dieselben Trigger zu konkurrieren. Wir betreiben neun. Ab etwa 15 solltest du eher ausdünnen, was seit einem Monat nicht gefeuert hat, statt weiter hinzuzufügen.

Kann ich die Permissions-Schicht überspringen, wenn ich in einer Sandbox arbeite?

Ist die Sandbox wirklich Wegwerf, keine Zugangsdaten, keine Volumes, die dir wichtig sind, dann ja, und genau dafür gibt es --dangerously-skip-permissions. Die Schicht zählt auf Maschinen mit echten Secrets. Die "Sandbox" der meisten Leute ist ein Laptop mit den Produktions-AWS-Keys in einer Dotfile, was keine Sandbox ist.