Claude Code Konfiguration: Rules, Skills & Workflow richtig kombinieren

Kurzantwort: Claude Code konfigurieren heißt nicht, Prompts in eine Datei zu kippen. Es sind vier Schichten mit klaren Rollen — CLAUDE.md für Projekt-Fakten, die Claude immer kennen soll, Rules für harte Grenzen und pfadbezogene Konventionen, Skills für wiederverwendbare Mehrschritt-Abläufe und Workflow als Verdrahtung von Skills, Hooks, Cron und CI zu etwas, das das Team wiederholen kann. Der häufigste Fehler: Schichten vermischen. Eine 40-zeilige Deploy-Checkliste in CLAUDE.md frisst jeden Sitzungsstart tausende Token; eine „kein force push“-Grenze in einem Skill geht nach Kontext-Compaction verloren.

Dieser Leitfaden richtet sich an iOS-, Flutter- und AI-App-Entwickler, die Claude Code nutzen oder evaluieren — besonders Teams, die die Hauptentwicklung auf einen Cloud Mac oder Remote-Mac-Mietplatz verlagern wollen. Wir orientieren uns an offizieller Dokumentation und Praxisstand August 2026: Verzeichnisstruktur, YAML-Frontmatter-Beispiele, Entscheidungstabelle und Hinweise zum Dauerbetrieb auf Apple-Silicon-Hardware.

Datenstand: 6. August 2026. Verhalten gemäß Claude Code Skills Dokumentation und Anthropic-Steering-Blog; Frontmatter-Felder können zwischen Versionen leicht abweichen.

Warum Schichten statt einer riesigen CLAUDE.md

Die erste Reaktion vieler Teams: Claude Code liest das Repo — also alle Konventionen in die Root-CLAUDE.md, fertig. Das Problem ist das geteilte Kontextbudget: Je mehr bei jeder Sitzung mitgeladen wird, desto weniger Platz bleibt für Diffs und Tool-Ausgaben. Schlimmer noch, wenn prozedurale Inhalte („Tests, Version bumpen, taggen, pushen“) mit Fakten („Haupt-Scheme heißt MyApp-Prod, Profil XYZ im Schlüsselbund“) vermischt werden — eine kleine Änderung zieht alles mit.

In Anthropics Steering-Leitfaden gibt es sieben Mechanismen: CLAUDE.md, Rules, Skills, Subagents, Hooks, Output Styles und System-Prompt-Erweiterungen. Für die meisten Engineering-Teams reichen die ersten vier plus Workflow-Orchestrierung für rund 90 % der Fälle. Wer bereits den Cursor + Claude Code + OpenRouter-Stack fährt, kann die Terminal-Schichtung mit IDE-.cursor/rules vergleichen — Pfade und Ladezeitpunkte sind aber anders; blind kopieren funktioniert nicht.

Ein typischer Fehlerfall: Ein fünfköpfiges Flutter-Team packt Review-Checklisten, Archive-Schritte und Branch-Policy in CLAUDE.md, bis die Datei 400 Zeilen überschreitet. Claude schleppt das Runbook mit, während es ein Widget anfasst — Antworten werden langsam, nach Compaction „vergisst“ es Testanforderungen aus der zweiten Hälfte. Nach Aufteilung in path-scoped Rules und drei Skills sanken die Eingabe-Token im Schnitt um etwa 30 %, Review-Lücken nahmen ab.

Kernkonzepte: Was jede Schicht löst

CLAUDE.md: das dauerhafte Projektgedächtnis

CLAUDE.md (oder .claude/CLAUDE.md) wird bei jedem Sitzungsstart geladen. Hier gehören kurze, stabile, teamweite Fakten hin:

• Einzeiler für Build und Tests (z. B. xcodebuild -scheme MyApp test)
• Monorepo-Karte (apps/ios, packages/core — wer macht was)
• Index aktiver Skills und Rules (eine Zeile Beschreibung + Pfad)
• Kurzfassungen teamweiter Tabus (Details in Rules)

Offizielle Empfehlung: lesbare Kurzform, kein Wiki. Ab 200 Zeilen prüfen, ob versehentlich Prozeduren reingerutscht sind. CLAUDE.md ist Claudes Boot-Checkliste, nicht euer internes Handbuch.

Rules: Grenzen und pfadbezogene Konventionen

Rules sind Markdown-Dateien unter .claude/rules/. Im Vergleich zu CLAUDE.md:

• Pfad-Scope möglich — laden nur bei passenden Dateien (z. B. paths: ["**/*.swift"])
• Re-Injektion nach Kontext-Compaction — geeignet für Sicherheitsgrenzen
• Ton: „muss / darf nicht“, nicht „hier sind 12 Vorschläge“

Gute Rule-Inhalte: keine Secrets im Commit, Swift-Namenskonventionen, Migrationen müssen rückrollbar sein, Agenten dürfen kein git push --force ausführen. In unserer Black Hat USA 2026 AI-Agent-Sicherheitscheckliste für Remote Macs betonen wir dasselbe: Grenzen für Terminal-Agenten gehören in auditierbare Rules, nicht in Flur-Absprachen.

Skills: wiederverwendbare Playbooks

Skills liegen in ~/.claude/skills/ (Nutzer) oder .claude/skills/ (Projekt). Jeder Skill ist ein Ordner mit SKILL.md. Laut Skills-Dokumentation gilt progressive Offenlegung:

• Sitzungsstart: nur name und description
• Bei Aufruf: Volltext und gebündelte Skripte
• Mehrere Skills teilen ein Token-Budget; frühere Aufrufe können verdrängt werden

Skill-taugliche Aufgaben: TestFlight-Release-Checkliste, PR-Review-Schritte, Flutter-i18n-Batch, OpenAPI-Client-Regenerierung. YAML-Frontmatter kann allowed-tools (vorab autorisierte Tools), disable-model-invocation: true (nur manuell per /skill-name) und context: fork (Sub-Agent) setzen.

Workflow: die Teile zum Team-Rhythmus verbinden

Workflow ist kein fünfter Ordner, sondern wer wann welche Schicht auslöst. Hooks formatieren vor git commit; Cron oder launchd ruft nachts /refactor-module auf; CI startet Claude Code non-interaktiv für Migrationsskripte; ein Cloud Mac hält dieselbe .claude-Struktur per Git. Workflow beantwortet: „Wer triggert was, wann?“

Kombinationstabelle: Was wohin gehört

Praxis: iOS-Team-Konfiguration von null auf

Diese Struktur funktioniert in gemischten iOS-/Flutter-Repos mit 2–6 Personen — anpassbar:

your-repo/
├── CLAUDE.md                    # Build-Befehle, Schemes, Skill-Index
├── .claude/
│   ├── settings.json            # Team-Settings (keine Secrets)
│   ├── settings.local.json      # lokal, gitignore
│   ├── rules/
│   │   ├── global-security.md   # kein .env, kein force push
│   │   ├── ios-swift.md         # paths: ["**/*.swift"]
│   │   └── flutter-dart.md      # paths: ["lib/**/*.dart"]
│   └── skills/
│       ├── release-testflight/
│       │   └── SKILL.md
│       └── pr-review/
│           └── SKILL.md

Schritt 1: CLAUDE.md (80–120 Zeilen). Oben Tabelle mit Schemes, Mindest-iOS-Version, Test-Einstieg; Mitte Verzeichnisübersicht; unten Bullet-Liste der Skills (Name + ein Satz). Keine Schritt-für-Schritt-Prozeduren hier.

Schritt 2: Rules aufteilen. Globale Sicherheit in eigene Datei; Sprachregeln nach Pfad. Beispiel-Frontmatter für path-scoped Rules:

---
paths:
  - "**/*.swift"
  - "**/*.xcodeproj/**"
---

# iOS / Swift Grenzen
- Neue UI braucht Preview oder Begründung für Ausnahme
- Team ID unter Signing & Capabilities nicht ändern
- Netzwerk-Änderungen brauchen passende Unit-Tests

Schritt 3: ersten Skill anlegen. Starten Sie mit dem häufigsten, fehleranfälligsten Ablauf — bei iOS-Teams oft TestFlight oder PR-Review:

---
name: release-testflight
description: "Haupt-Scheme archivieren und TestFlight hochladen; an Release-Tagen oder bei «Release»"
disable-model-invocation: true
allowed-tools: Bash(xcodebuild *) Bash(fastlane *)
---

## Vor dem Release
1. `main` merged, CI grün
2. `CHANGELOG`-Eintrag passt zur Versionsnummer
3. `xcodebuild -scheme MyApp -destination 'generic/platform=iOS' archive`
4. fastlane `upload_testflight`
5. Build-Nummer im PR kommentieren

disable-model-invocation: true lädt den Skill nur bei manuellem /release-testflight — Claude triggert kein Release beim UI-Tweak. Für sensible Ops Pflicht.

Schritt 4: Workflow anschließen. In .claude/settings.json Hooks konfigurieren (z. B. PreToolUse blockiert gefährliche Befehle). Dasselbe .claude-Verzeichnis auf Cloud Mac und lokal — SSH auf Remote Mac verhält sich wie lokal. Team-Config per Git; API-Keys und settings.local.json per gitignore.

Cloud Mac / Apple Silicon: wo es im Alltag zählt

Claude Code ist ein Terminal-Agent — die Qualität der Laufzeit entscheidet, wie weit Sie ihm vertrauen. In VPSSpark-Cloud-Mac- oder Remote-Mac-Szenarien bringt Schicht-Konfiguration drei konkrete Vorteile:

• Umgebung einfrieren: .claude/, Homebrew, fastlane-Version ins Image — neuer Knoten, keine Skill-Neuinstallation.
• Lange Sitzungen stabiler: Apple Silicon M4 Unified Memory für Xcode, Simulator und Claude Code parallel; Standby ~4 W — geeignet für nächtliche /refactor-Skills.
• Isolation: eigener Systemnutzer für den Agent auf dem Cloud Mac; Rules begrenzen Schlüsselbund-Pfade — sicherer als auf dem privaten Hauptrechner.

Typischer Workflow: Code in Cursor lokal → Push → Cloud-Mac-CI zieht und führt Migrations-Skill non-interaktiv aus → fastlane-Upload. Rules verhindern force push in CI; Skills halten Schritte identisch zum manuellen Release. Flutter-Teams können flutter build ipa und iOS-Signatur ebenfalls skillen und dieselben Security-Rules teilen.

Bei OpenRouter-Routing für API-Kosten sind allowed-tools und Modellwahl unabhängig — im Workflow aber Speicher beobachten: zwei fork-Skills plus Xcode-Archive auf M4 mit 16 GB können kollidieren. In Rule oder Skill festhalten: „Kein zweiter fork-Skill während Archive“.

Kosten, Performance und Risiken

Token-Kosten: Aufgeblähtes CLAUDE.md zahlt „Hintergrundsteuer“ pro Sitzung; Skills sparen durch progressive Offenlegung — aber mehrere Skills in einer Session teilen sich Budget. Regelmäßig /context oder offizielle Token-Stats prüfen, welche Schicht dominiert.

Wartung: Rules und Skills sind reviewbar und versionierbar — günstiger als mündliche Übergabe. Ab 15 Skills braucht es einen Index-Verantwortlichen, sonst finden Neue den richtigen Skill nicht.

Risiken: allowed-tools senkt Bestätigungshürden in der Skill-Runde — nur für vertrauenswürdige Skills. Geteilte Cloud-Mac-Knoten: persönliche Keys in settings.local.json. Fehlkonfigurierte Hooks blockieren Commits — zuerst auf Branch testen.

Verglichen mit „gar nicht konfigurieren und jedes Mal neu erklären“ amortisiert sich 2–4 Stunden Setup meist in Woche drei durch weniger Wiederholung und Fehlversuche. Gegen „alles in CLAUDE.md“ sind Token-Rechnung und Auslassungsrate langfristig kontrollierbarer.

FAQ

Können Claude Code Rules und Cursor Rules geteilt werden?

Konzept ähnlich, Pfade und Format nicht. Cursor nutzt .cursor/rules, Claude Code .claude/rules/. Eine Markdown-Quelle per Skript in beide spiegeln geht — automatische Synchronisation gibt es nicht.

Dürfen Skills externe Skripte aufrufen?

Ja. Unter scripts/ im Skill-Ordner; mit allowed-tools: Bash(./scripts/*) weniger Rückfragen. Skripte wie Produktionscode reviewen — keine unauditierten Shells durch den Agenten.

Wie reviewt das Team neue Rules oder Skills?

Im selben PR wie Code: neue .claude/rules/foo.md oder skills/bar/SKILL.md braucht menschlichen Review auf Konflikte mit Security-Rules und Dopplungen in CLAUDE.md. Laut Claude Code Settings können skillOverrides Skills temporär deaktivieren ohne Löschen.

Vergisst Claude Skill-Schritte nach Compaction?

Frühe Skill-Aufrufe können aus dem Shared Budget fallen. Gegenmaßnahmen: kritische Schritte als Hook; Skill endet mit Checkliste in Datei; Release-Skills mit disable-model-invocation: true und kurzer Sitzung.

Lohnt sich das auch solo?

Ja, minimal: 50 Zeilen CLAUDE.md, zwei Rules (Security + Sprache), ein Skill für den häufigsten Job (z. B. /ship). Vorteil: schnelle Iteration — 15 Minuten pro Woche spart wiederholtes Tippen von Build-Befehlen.

Fazit: Workflow skizzieren, dann Dateien schreiben

Die Kombination aus Rules, Skills und Workflow in Claude Code teilt menschliche Erfahrung in ladefähige Module. CLAUDE.md beantwortet „was ist dieses Projekt“, Rules „was ist tabu“, Skills „wie läuft der komplexe Ablauf“, Workflow „wann passiert das automatisch“. Vier Schichten klären, dann konfigurieren — deutlich entspannter als 500 Zeilen Prompt am ersten Tag.

Empfohlene Reihenfolge: diese Woche CLAUDE.md-Skelett → nächste Woche zwei Security-Rules → häufigster Skill → zuletzt Hook auf Cloud Mac oder CI. Jede Schicht einmal in echter Arbeit messen: Token und Auslassungen.