CCAR-F Kapitel 3: Claude Code konfigurieren und im Team nutzen

Dieses Kapitel deckt den Prüfungsbereich „Claude Code Configuration & Workflows“ ab (20 % der CCAR-F). Es geht darum, Claude Code für ein Team so einzurichten, dass es verlässlich nach den Regeln des Projekts arbeitet.

Ziel

Nach dem Kapitel kannst du

• Anweisungsdateien auf Benutzer-, Projekt- und Ordnerebene sinnvoll schneiden,
• Regeln nur für passende Dateien laden lassen,
• wiederverwendbare Abläufe als Skills anlegen,
• entscheiden, wann der Planmodus lohnt,
• Claude Code in eine CI/CD-Pipeline einbauen, ohne Fehlalarme zu erzeugen.

Das Wichtigste in Kürze

• CLAUDE.md ist dauerhafter Kontext. Jede Sitzung beginnt mit einem leeren Kontextfenster. Die Datei CLAUDE.md trägt das Wissen, das Claude in jeder Sitzung braucht: Konventionen, Befehle, Architekturentscheidungen. Claude behandelt sie als Kontext und nicht als erzwungene Konfiguration; Verbote, die immer gelten müssen, setzt du per Hook durch.
• Mehrere Ebenen, alle zusammen. Eine Datei kann für die ganze Organisation gelten (verwaltet von der IT), für dich persönlich (~/.claude/CLAUDE.md) oder für das Projekt (./CLAUDE.md, im Repository und damit für alle). Private Projektnotizen stehen in CLAUDE.local.md, die du nicht einchecken solltest. Claude lädt alle Dateien vom Wurzelverzeichnis bis zu deinem Arbeitsordner und hängt sie aneinander; nahe Anweisungen stehen zuletzt. Dateien in Unterordnern werden erst geladen, wenn Claude dort arbeitet.
• Kurz halten. Als Richtwert gelten weniger als 200 Zeilen je Datei; längere Dateien verbrauchen Kontext und mindern die Befolgung. Widersprüche zwischen Dateien führen dazu, dass Claude beliebig eine Variante wählt.
• Aufteilen mit Importen und Regeln. Mit @pfad/zur/datei bindest du andere Dateien ein (bis vier Ebenen tief); das spart keinen Kontext, hilft aber der Ordnung. Im Ordner .claude/rules/ legst du Themendateien an (zum Beispiel Tests oder API-Stil). Mit einer paths:-Angabe im Dateikopf laden sie nur, wenn Claude mit passenden Dateien arbeitet.
• Skills und Befehle. Eine Skill-Datei (SKILL.md) beschreibt einen wiederholbaren Ablauf; Claude nimmt ihn in seinen Werkzeugkasten auf, und sie lässt sich auch als Schrägstrichbefehl wie /deploy aufrufen. So teilt ein Team gemeinsame Abläufe wie das Prüfen eines Pull Requests.
• Planmodus für grössere Entscheidungen. Im Planmodus liest Claude und schlägt einen Plan vor, ändert aber nichts, bis du ihn freigibst. Du schaltest ihn mit Shift+Tab oder claude --permission-mode plan ein. Er lohnt sich bei Änderungen über viele Dateien oder bei mehreren möglichen Lösungswegen; ein Einzeiler braucht ihn nicht.
• Verfeinern in Schritten. Konkrete Beispiele für Ein- und Ausgabe, ein Test als Massstab und das Bearbeiten in Etappen führen schneller zu guten Ergebnissen als ein grosser Auftrag.
• Subagenten halten den Kontext sauber. Eine umfangreiche Erkundung kannst du an einen Subagenten auslagern; er liest in seinem eigenen Fenster und liefert nur die Ergebnisse zurück.
• In der Pipeline nicht-interaktiv. Mit claude -p "…" läuft Claude Code ohne Dialog, auch mit eingeleiteter Standardeingabe. --output-format json liefert Ergebnis und Metadaten, --json-schema erzwingt eine Struktur. Mit --allowedTools und einem Berechtigungsmodus legst du fest, was ohne Rückfrage laufen darf; --bare sorgt für gleiche Ergebnisse auf jeder Maschine, weil es lokale Konfiguration auslässt. Für GitHub und GitLab gibt es fertige Integrationen.
• Prompts für Reviews brauchen Kriterien. Wer Fehlalarme vermeiden will, nennt ausdrücklich, was gemeldet werden soll und was nicht, statt „sei gründlich“ zu schreiben (mehr dazu in Kapitel 4).

Kernaussagen im Detail

Hierarchie im Alltag

Lege Teamregeln ins Repository, persönliche Vorlieben in dein Benutzerverzeichnis und Experimente in CLAUDE.local.md. Prüfe von Zeit zu Zeit alle Dateien auf Widersprüche und Überholtes; Claude kann dabei helfen. Neben der von dir geschriebenen Datei legt Claude auch eigene Notizen an (Auto Memory), die ebenfalls bei jedem Start geladen werden.

Regeln mit Pfad

Ein Beispielkopf einer Regeldatei: paths: ["src/api/**/*"]. Die Regel steht dann nur im Kontext, wenn Claude Dateien in diesem Pfad liest oder ändert. Das hält den Kontext klein und die Regeln treffsicher, besonders in grossen Repositories mit verschiedenen Sprachen und Stilen.

Planmodus oder direkt?

Eine einfache Faustregel: Direkt ausführen, wenn der Weg klar ist und die Änderung klein. Planmodus, wenn mehrere Dateien betroffen sind, wenn es mehrere vernünftige Lösungen gibt oder wenn eine Fehlentscheidung teuer wäre. Den Plan kannst du vor der Freigabe ändern.

Claude Code in der Pipeline

Eine Pipeline kennt keinen Menschen für Rückfragen. Lege deshalb vorab fest, welche Werkzeuge erlaubt sind und ob unerlaubte Aufrufe verweigert werden sollen. Gib dem Review konkrete Prüfkriterien und ein Ausgabeformat vor. Trenne die Prüfung eines Autors von der Prüfung durch eine zweite, unabhängige Sitzung, damit sich Fehler nicht gegenseitig bestätigen.

Verständnisfragen

1. Dein Team will, dass Claude für Dateien unter tests/ bestimmte Konventionen beachtet, im Rest des Projekts aber nicht. Wie setzt du das um, und warum nicht einfach in die CLAUDE.md schreiben?
2. Eine Anweisung in CLAUDE.md („Nie in den Hauptzweig pushen“) wird gelegentlich ignoriert. Was folgt daraus für die Wahl des Mittels?
3. Ein Pull-Request-Review in der Pipeline meldet viele Kleinigkeiten, die niemand will. Welche Änderungen am Auftrag helfen?

Kurzantworten

1. Eine Regeldatei in .claude/rules/ mit paths: ["tests/**/*"]. In der CLAUDE.md würde sie bei jeder Sitzung Kontext beanspruchen und die Befolgung verwässern.
2. CLAUDE.md ist Kontext, keine Durchsetzung. Für ein Verbot, das immer gelten muss, braucht es einen Hook (PreToolUse) oder eine Berechtigungsregel.
3. Ausdrücklich benennen, was gemeldet werden soll (zum Beispiel Fehler mit Folgen) und was nicht (Stilfragen), ein festes Ausgabeformat verlangen und Beispiele für berechtigte und unberechtigte Befunde mitgeben.

Weiter lernen

• Wie Claude sich dein Projekt merkt
• Skills
• Gängige Arbeitsabläufe (Planmodus, Sitzungen)
• Nicht-interaktiver Betrieb
• GitHub Actions
• Bewährte Vorgehensweisen
• Übung: Lege eine Projekt-CLAUDE.md, zwei pfadgebundene Regeln und einen Skill an, binde einen MCP-Server per .mcp.json ein und vergleiche Planmodus und direktes Arbeiten an drei Aufgaben unterschiedlicher Grösse.

Quellen

• Wie Claude sich dein Projekt merkt (CLAUDE.md, Regeln, Auto Memory)
• Skills
• Gängige Arbeitsabläufe
• Claude Code programmatisch ausführen
• Claude Code mit GitHub Actions
• Exam Guide CCAR-F, Bereich 3 (Anthropic Partner Academy)

Titelbild: StockSnap auf Pixabay (Pixabay Content License).