Claude Code im Team einrichten: Rules, Permissions und Skills

Die meisten Teams setzen KI-Tools so ein, wie sie einzelne Entwickler einsetzen: jeder konfiguriert sich seins, jeder klickt jede Permission-Frage einzeln weg, und die Regeln, an die sich die KI halten soll, leben als Zettel im Kopf eines Senior-Entwicklers. Das funktioniert für Solo-Hacking. Es bricht in dem Moment, in dem ein zweiter Dev dazukommt — spätestens dann, wenn die KI über mehr als ein Verzeichnis arbeiten soll.

Wer Claude Code im Team einrichten will, stößt sehr schnell auf drei Hebel, die den Unterschied zwischen Spielzeug und Werkzeug ausmachen: Permissions, path-scoped Rules und Skills. Wir setzen Claude Code seit Anfang 2025 produktiv ein — bei Kunden-Projekten und in der eigenen Toolchain. Dieser Post zeigt, wie wir diese drei Hebel konkret konfigurieren, mit Beispielen aus unserem tatsächlichen Setup.

Was dieser Post liefert — und für wen

Zielgruppe sind Senior-Devs und Tech-Leads, die Claude Code im Team einführen oder den eigenen Workflow professionalisieren wollen. Wir setzen Grundvertrautheit mit dem Tool voraus — Installation und erste Schritte überspringen wir. Stattdessen geht es um die Patterns, die den Unterschied zwischen “ich nutze Claude Code” und “unser Team arbeitet mit Claude Code produktiv” machen.

Konkret bekommen Sie:

• Wie wir Permissions im Team-Kontext einrichten, ohne dass jede Aktion eine Rückfrage produziert.
• Was in die globale CLAUDE.md gehört, was in die projekt-CLAUDE.md, und warum verschachtelte Regeln pro Verzeichnis das wichtigste vergessene Feature sind.
• Was Skills sind, wie sie sich von Rules unterscheiden, und wann welcher Mechanismus passt.

Was wir bewusst weglassen: Subagents und Hooks. Beide gehören in eigene Posts — die Orchestrierung paralleler KI-Tasks und automatisierte Quality-Gates sind eigene Themen mit eigener Tiefe.

Setup-Grundlagen — was im Team-Kontext zählt

Auth und erste Schritte machen wir kurz, weil sie in der offiziellen Doku gut abgedeckt sind. Wichtig sind drei Punkte, an denen Teams typisch stolpern.

Erstens: Auth-Pfad. Im Einzelnutzer-Setup ist der API-Key über die Anthropic Console der Standardweg. Im Team-Kontext lohnt sich der Blick auf OAuth über die Anthropic-Workbench — Nutzungsabrechnung, Quoten und Audit-Logs zentralisiert. Bei kleineren Teams (bis fünf Devs) ist das oft Overkill; ab zehn Devs wird es zur Hygiene.

Zweitens: Was ins Repo gehört. Claude Code legt nach dem ersten /init zwei Dinge an — eine CLAUDE.md im Projekt-Root und einen .claude/-Ordner. Die CLAUDE.md und alle geteilten Skills im .claude/skills/-Pfad gehören ins Repo. Die persönliche settings.local.json sowie alle individuellen Permission-Anpassungen gehören ins .gitignore. Wir empfehlen, das .gitignore direkt beim Setup zu pflegen:

# Claude Code — geteilte Konfiguration committen, persönliche nicht
.claude/settings.local.json
.claude/projects/

Drittens: Die Settings-Layer verstehen. Claude Code kennt zwei Settings-Ebenen pro Projekt:

• .claude/settings.json — geteilt, im Repo, gilt für alle Devs.
• .claude/settings.local.json — persönlich, nicht im Repo, überschreibt das geteilte Layer.

Das ist genau der gleiche Mechanismus, den VS Code mit Workspace- und User-Settings fährt. Wenn Sie die zwei Ebenen sauber trennen — geteilte Permissions ins Repo, persönliche Bequemlichkeit lokal — haben Sie 80% der späteren Konflikte gelöst, bevor sie entstehen.

Permissions im Team-Kontext

Die Default-Permission-Behaviour von Claude Code ist konservativ: fast jede Aktion fragt nach. Im Einzelbetrieb tolerabel. Im Team-Alltag — wo der gleiche Dev fünf Mal am Tag den gleichen Befehl bestätigt — wird das schnell zur Reibung, die das Tool wieder aus dem Workflow drückt.

Die Lösung ist eine durchdachte Allowlist in der settings.json. Pattern:

• Lesende Operationen pauschal erlauben. git status, git diff, npm ls, dotnet --version — keine davon kann Schaden anrichten. Allowlist auf.
• Mutierende, aber reversible Operationen erlauben. git add, git commit ohne --amend, npm install, dotnet build, das Schreiben in Projekt-Dateien.
• Destruktive oder remote-wirksame Operationen immer bestätigen lassen. git push --force, rm, git reset --hard, alles, was Production-Systeme berührt.
• Tools mit unklarem Blast-Radius außerhalb des Repos verbieten. Datenbank-Tools mit Production-Credentials, Cloud-CLIs gegen echte Subscriptions.

Ein realistischer .claude/settings.json-Auszug für ein .NET/React-Projekt sieht bei uns ungefähr so aus:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git add:*)",
      "Bash(npm install:*)",
      "Bash(npm run build:*)",
      "Bash(dotnet build:*)",
      "Bash(dotnet test:*)"
    ],
    "deny": [
      "Bash(git push --force:*)",
      "Bash(rm -rf:*)",
      "Bash(git reset --hard:*)"
    ]
  }
}

Die allow-Liste ist die wichtigere — sie reduziert die Permission-Fragen auf das, was wirklich entschieden werden muss. Die deny-Liste ist die Sicherheitsschiene für die Befehle, die niemals von der KI durchlaufen sollen, auch nicht versehentlich.

Eine zusätzliche Verteidigungsebene sind Hooks — Shell-Skripte, die vor oder nach bestimmten Tool-Calls automatisch laufen können. Sie eignen sich für automatische Linter-Läufe, Formatierung oder Vorab-Checks, bevor ein Commit erlaubt wird. Hooks behandeln wir ausführlich in Teil 3 der Serie.

CLAUDE.md und path-scoped Rules — KI-Governance, die wirklich wirkt

Hier liegt der Kern dieses Posts. Wenn Sie aus diesem Artikel nur eine Sache mitnehmen, dann diese: Pauschale Regeln in einer großen CLAUDE.md werden entweder ignoriert oder gelten überall — beides macht sie wertlos.

Was funktioniert, ist eine bewusst gewählte Hierarchie aus mehreren CLAUDE.md-Dateien, die Claude Code automatisch in den richtigen Kontexten lädt.

Die Hierarchie verstehen

Claude Code liest CLAUDE.md-Dateien auf drei Ebenen:

1. Global (~/.claude/CLAUDE.md) — gilt für jede Session überall. Hier gehören Dinge rein, die für jedes Projekt gelten, das Sie als Entwickler bearbeiten.
2. Projekt (<repo>/CLAUDE.md) — gilt für alle Sessions in diesem Repo. Hier gehören projektspezifische Konventionen rein.
3. Verschachtelt (<repo>/<unterordner>/CLAUDE.md) — gilt nur, wenn Claude in dem entsprechenden Unterordner arbeitet. Das ist der eigentliche Hebel für Monorepos und Stacks mit getrennten Code-Bereichen.

Alle Ebenen werden zusammengeführt — niedrigere Ebenen ergänzen oder überschreiben höhere.

Pattern A — Ausgelagerte Rule-Dateien für die globale Ebene

Wir halten die globale ~/.claude/CLAUDE.md selbst kurz. Stattdessen liegen die eigentlichen Regeln in einem ~/.claude/rules/-Verzeichnis, thematisch getrennt:

~/.claude/
├── CLAUDE.md           # nur ein Index, lädt die rules via @-Referenz
└── rules/
    ├── general-quality.md      # Naming, Read-before-write, One-concern-per-change
    ├── git-workflow.md         # Branch model, Commit format, Push process
    └── github-workflow.md      # Issue model, MCP tools, Project state model

Die CLAUDE.md referenziert die Rule-Dateien einfach:

# Global rules

@~/.claude/rules/general-quality.md
@~/.claude/rules/git-workflow.md
@~/.claude/rules/github-workflow.md

Das hat drei Vorteile:

• Fokussierte Edits. Wenn der Git-Workflow geändert wird, fasst niemand die Datei für allgemeine Code-Qualität an.
• Lesbarkeit für die KI. Jede Datei ist intern kohärent — Claude versteht den Kontext einer Anweisung besser, wenn sie nicht zwischen drei Themen eingebettet ist.
• Teilbarkeit. Eine git-workflow.md lässt sich an Kollegen weitergeben, ohne dass deren Setup angepasst werden muss.

Pattern B — Verschachtelte CLAUDE.md in Unterordnern

In einem typischen .NET-Backend / React-Frontend-Monorepo legen wir zusätzlich zur Root-CLAUDE.md je eine in den großen Sub-Trees an:

<projekt>/
├── CLAUDE.md           # generelle Projekt-Konventionen, Architektur, Domänen-Kontext
├── backend/
│   ├── CLAUDE.md       # .NET-spezifisch: DI-Pattern, EF Core, Test-Konventionen
│   └── src/
└── frontend/
    ├── CLAUDE.md       # React/TS-spezifisch: State-Management, Komponenten-Patterns
    └── src/

Wenn Claude einen Task in backend/ bearbeitet, lädt es Root-CLAUDE.md + backend/CLAUDE.md — die Frontend-Regeln stören den Kontext gar nicht erst.

Konkretes Beispiel: Eine Anweisung wie “alle async-Methoden enden auf Async” ist im Backend universell richtig. Im Frontend ist sie sinnlos, weil dort kein Sprachkonvent existiert. Pauschal in der Root-CLAUDE.md würde sie entweder zu viel beanspruchen (Frontend-Code falsch beurteilen) oder ignoriert werden (KI lernt, Anweisungen selektiv anzuwenden — schlechtes Trainings-Signal).

Anti-Pattern: die 800-Zeilen-CLAUDE.md

Was wir bei Kunden-Reviews regelmäßig sehen: eine einzelne, gewachsene CLAUDE.md mit Regeln für Backend, Frontend, DevOps, Naming, Testing, Security, Deployment — alles in einer Datei.

Das Ergebnis ist vorhersagbar:

• Die Datei wird so lang, dass die KI Regeln am Ende effektiv weniger gewichtet als Regeln am Anfang.
• Widersprüche zwischen Stack-Bereichen entstehen unbemerkt.
• Die Regel-Datei wird nie reviewt, weil der Diff zu groß wirkt.

Wenn Ihre CLAUDE.md länger als 200 Zeilen wird, splitten Sie sie. Entweder thematisch (Rules-Pattern) oder räumlich (verschachtelte CLAUDE.md). Beides funktioniert; Mischformen auch.

Skills — wiederverwendbare Workflows

Rules definieren, wie sich Claude generell verhalten soll. Skills definieren Workflows, die man bewusst aufruft, wenn ein bestimmter wiederholbarer Task ansteht.

Was Skills sind — und was sie nicht sind

Ein Skill ist eine Markdown-Datei mit Frontmatter, die einen wiederverwendbaren Workflow beschreibt. Liegen Skills in ~/.claude/skills/ (global) oder .claude/skills/ (projekt), kann man sie via /skill-name aufrufen — oder die KI ruft sie automatisch auf, wenn die Skill-Description den aktuellen Task passend beschreibt.

Was Skills nicht sind: keine Makros, keine Funktionen, keine Templates. Sie sind Anweisungen an die KI, einen bestimmten Workflow zu durchlaufen — mit Spielraum für Interpretation und Kontextanpassung.

Skill-Anatomie

Ein Skill-File hat einen festen Aufbau:

---
name: review-pr
description: Reviewt einen Pull Request gegen unsere Projekt-Konventionen
  und Qualitäts-Standards. Use for ad-hoc reviews of branches, PRs,
  or staged changes.
allowed-tools: Bash, Read, Grep, Glob
---

# Pull Request Review Skill

Du reviewst einen Pull Request gegen die Konventionen in CLAUDE.md.

## Schritte
1. Hole die Liste der geänderten Dateien...
2. Lies jede Datei und prüfe gegen...
3. ...

Die description ist nicht Kosmetik — sie ist das, was Claude als Trigger-Signal verwendet, wenn jemand keinen expliziten Skill-Aufruf macht. Klare, spezifische Beschreibungen führen zu treffsicherer Aktivierung.

Wann Skill, wann Rule, wann gar nichts?

Faustregel:

Bedingung	Lösung
Permanentes Verhalten, gilt immer	Rule (CLAUDE.md)
Aufrufbarer Workflow, gleicher Ablauf jedes Mal	Skill
Einmaliger Sonderfall	Im Prompt direkt formulieren
Komplexe parallele Orchestrierung	Subagents (Teil 2)

Beispiel aus unserem Setup: Die Regel “Branch-Namen folgen dem Schema feature/{issue-number}-{slug}” gehört in die git-workflow.md (Rule, permanentes Verhalten). Der Workflow “Issue lesen, Branch anlegen, implementieren, PR aufmachen” ist ein Skill (/story-implement — aufrufbarer Workflow).

Rollout im Team

Drei Dinge haben sich bei uns als praxistauglich bewiesen.

Geteilte vs. persönliche Schichten klar trennen. Im Repo: die projekt-CLAUDE.md, verschachtelte CLAUDE.md-Dateien in Sub-Trees, geteilte Skills im .claude/skills/, geteilte settings.json. Im persönlichen ~/.claude/: globale Rules, persönliche Skills, individuelle Permission-Erweiterungen. Diese Trennung verhindert, dass persönliche Präferenzen ins Repo lecken oder geteilte Konventionen versehentlich durch lokale Edits umgangen werden.

Onboarding-Pfad für neue Devs auf 30 Minuten setzen. Wer neu ins Projekt kommt, soll in einer halben Stunde produktiv mit dem KI-Setup arbeiten können: Claude Code installieren, OAuth-Login, ins Repo clonen, einmal die Projekt-CLAUDE.md lesen, fertig. Dafür müssen Projekt-CLAUDE.md und .claude/settings.json sauber genug sein, dass keine Mündliche-Tradition-Lücken bleiben. Wir reviewen unsere Projekt-CLAUDE.md alle paar Wochen mit der Frage: “Würde ein neuer Senior heute damit klarkommen?”

Was wir gelernt haben. Zwei Dinge haben wir erst beim zweiten Anlauf richtig gemacht. Erstens: Rules anfangs zu spezifisch geschrieben — wir hatten Anweisungen wie “verwende immer XYZ-Library für JSON-Parsing”, die nach drei Monaten falsch waren, weil sich die Stack-Entscheidungen verschoben hatten. Heute schreiben wir Rules eher als Prinzipien (“bevorzuge die jeweils gewählte Standard-Library; bei Konflikten frag nach”) als als feste Tool-Vorschriften. Zweitens: Skills zu generisch gebaut — ein /implement-feature ohne klaren Trigger und ohne Erwartung an Input wurde nie verwendet. Spezifische Skills mit klarem Use-Case (z. B. /story-implement, der einen GitHub-Issue erwartet) werden gut adoptiert.

Fazit & Ausblick

Permissions, path-scoped Rules und Skills sind die drei Hebel, die Claude Code vom Solo-Werkzeug zur Team-Plattform machen. Wer alle drei sauber aufsetzt, bekommt eine KI-Unterstützung, die sich im Repo wie ein eingearbeiteter Entwickler verhält — mit Konventionen, mit Rückfragen an den richtigen Stellen, mit Reaktionen auf den Kontext, nicht auf pauschale Anweisungen.

Was wir in Teil 1 bewusst weggelassen haben:

• Subagents — wie man parallele Sub-Tasks an spezialisierte Sub-KIs delegiert, z. B. getrennte Backend- und Frontend-Agenten für eine User-Story.
• Hooks — automatisierte Quality-Gates, die vor oder nach KI-Aktionen Linter, Tests oder eigene Checks laufen lassen.

Beide kommen in den nächsten Teilen der Serie.

Wenn Sie tiefer in die Frage einsteigen wollen, wie sich die Rolle erfahrener Entwickler im KI-Zeitalter generell verschiebt — und was das für Software-Investitionen bedeutet — empfehlen wir unseren Artikel Wie KI die moderne Softwareentwicklung verändert.

---

Claude Code ist heute eines der mächtigsten Werkzeuge im Engineering-Alltag — wenn es richtig aufgesetzt ist. Der Unterschied zwischen “kleines Produktivitäts-Plus” und “Team-Plattform” liegt selten am Tool selbst, sondern an Permissions, Rules und Skills, die zum Team und seinem Code-Kontext passen.