Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

End-to-End Leitfaden: Softwareentwicklung mit Claude Code CLI¶

Vollständiger Praxis-Guide: Von der Ersteinrichtung (claude init), Skills (SKILL.md), Subagenten (.claude/agents/) und Hooks über den Agentic Coding Workflow bis hin zum fertigen Production-Release mit Claude Code.

Übersicht des Claude Code Entstehungs-Workflows¶

graph TD
    S1["1. Installation &amp; CLI-Auth"] --> S2["2. Projektsystem: claude init,<br/>CLAUDE.md, Skills, Subagenten,<br/>Hooks &amp; MCP"]
    S2 --> S3["3. Subagenten-Delegation<br/>&amp; Architektur-Planung"]
    S3 --> S4["4. Autonomer TDD-Loop<br/>&amp; Coding"]
    S4 --> S5["5. Multi-File Edits<br/>&amp; Debugging"]
    S5 --> S6["6. Linter, Quality<br/>&amp; Security Audits"]
    S6 --> S7["7. Dokumentation<br/>&amp; Git Integration"]
    S7 --> S8["8. Production Build,<br/>Packaging &amp; Release"]
    S8 --> S9["9. Skalierung: Permissions,<br/>Plugins, Headless-CI<br/>&amp; Team-Rollout"]

1. Phase: Installation, Authentifizierung & claude init (Setup)¶

1.1 Systemvoraussetzungen & Installation¶

• Voraussetzungen: Node.js (v18+) & Git im Terminal installiert.
• Globale Installation via npm:

  npm install -g @anthropic-ai/claude-code
  

1.2 Authentifizierung & API Key¶

• Starten von Claude Code im Terminal:

  claude
  

• Erstmalige Authentifizierung über das Web-Terminal oder durch Hinterlegung des Anthropic API-Keys (ANTHROPIC_API_KEY).

1.3 Automatische Projekt-Initialisierung mit claude init¶

Führe im Wurzelverzeichnis deines Projekts den Befehl /init (bzw. claude init aus der Shell heraus) aus:

claude
> /init

1.4 Wer erstellt die CLAUDE.md? (Mensch vs. KI-Agent)¶

• Vom KI-Agenten (Automatisch): Bei der Ausführung von /init scannt der KI-Agent das Repository und generiert automatisch das Erst-Setup der CLAUDE.md mit allen erkannten Build-, Test- und Linter-Befehlen.
• Vom Menschen (Manuell & Verfeinerung): Der Entwickler kann die CLAUDE.md von Hand anlegen oder die von der KI generierte Datei um projektspezifische Qualitäts-, Style- und Architekturregeln ergänzen.
• Best Practice (Zusammenspiel Mensch & KI):
  1. Der KI-Agent generiert das Grundgerüst automatisch via /init.
  2. Der Mensch verfeinert und ergänzt individuelle Richtlinien (z. B. Verbot von unwrap(), Durchsetzung Hexagonaler Architektur), an die sich der KI-Agent bei allen zukünftigen Sitzungen hält.
  3. Faustregel für den Umfang: unter 200 Zeilen pro CLAUDE.md. Längere Dateien kosten mehr Kontext und werden weniger zuverlässig befolgt — Details gehören stattdessen in .claude/rules/ (pfadgebunden) oder in einen Skill (siehe 2.6).

1.5 Vollständige Referenz aller Projekteinstellungen & Konfigurationsdateien¶

Für eine maximale Kontrolle über Claude Code und Agentic-AI-Projekte stehen alle folgenden Konfigurationsebenen und Dateien zur Verfügung. Alle Pfade sind die tatsächlich von der Claude Code CLI gelesenen Speicherorte.

1. CLAUDE.md (Projekt-Prompts & Verhaltensregeln)¶

• Dateipfad (nach Priorität):
  • /etc/claude-code/CLAUDE.md bzw. plattformspezifischer Managed-Policy-Pfad — organisationsweit, per MDM verteilt
  • ~/.claude/CLAUDE.md — persönliche Vorlieben für alle Projekte
  • ./CLAUDE.md oder ./.claude/CLAUDE.md — teamweite Projektregeln (versioniert)
  • ./CLAUDE.local.md — persönliche, nicht versionierte Projekt-Notizen (gehört in .gitignore)
• Format: Markdown, wird als User-Message zu Sessionbeginn geladen (nicht Teil des System-Prompts)
• Inhalt & Parameter:
  • Build- & Testkommandos: Vordefinierte CLI-Befehle (cargo build, cargo test, npm test, pytest).
  • Code-Style & Konventionen: Formatting-Regeln, Naming Conventions, Fehlerbehandlungs-Policies (z. B. „Keine unwrap() in Produktion").
  • Architektur-Vorgaben: Hexagonale Architektur, Domain-Driven Design (DDD), Modularisierungsregeln.
  • @pfad-Imports: Weitere Dateien lassen sich per @README oder @docs/git-instructions.md einbinden (max. 4 Verschachtelungsebenen).
• AGENTS.md-Kompatibilität: Claude Code liest AGENTS.md nicht nativ. Existiert im Repo bereits ein tool-übergreifendes AGENTS.md (z. B. für Cursor/Copilot), bindet man es per Import ein, statt Inhalte zu duplizieren:

  @AGENTS.md
  
  ## Claude Code
  Nutze den Plan-Modus für Änderungen unter `src/billing/`.
  

  Alternativ funktioniert ein Symlink (ln -s AGENTS.md CLAUDE.md), unter Windows nur mit Admin-Rechten/Dev-Mode — dort lieber den Import nutzen.

2. .claude/settings.json (CLI-Laufzeiteinstellungen & Rechte)¶

• Dateipfad & Geltungsbereich (Priorität von niedrig nach hoch):
  • ~/.claude/settings.json — User-weit
  • .claude/settings.json — Projekt, versioniert, teamweit gültig
  • .claude/settings.local.json — Projekt, lokal, nicht versionieren (persönliche Overrides)
  • Managed Policy (managed-settings.json unter /etc/claude-code/, /Library/Application Support/ClaudeCode/ bzw. C:\Program Files\ClaudeCode\) — höchste Priorität, IT-verwaltet
• Format: JSON
• Reales Schema (Auszug der wichtigsten Keys):

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "claude-sonnet-5",
  "effortLevel": "high",
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(cargo check)", "Read(~/.zshrc)"],
    "deny": ["Bash(curl *)", "Read(./.env*)", "Read(./**/*.pem)"]
  },
  "env": {
    "RUST_LOG": "debug",
    "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb_dev"
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "cargo fmt --check" }
        ]
      }
    ]
  },
  "outputStyle": "default",
  "statusLine": { "type": "command", "command": "./scripts/statusline.sh" },
  "cleanupPeriodDays": 30
}

3. .mcp.json (Model Context Protocol Konfiguration)¶

• Dateipfad: ./.mcp.json im Projekt-Root (teamweit, versioniert) — Server auf User-Ebene werden dagegen in ~/.claude.json registriert.
• Format: JSON
• Zweck: Registrierung von externen Werkzeugen, Datenbanken, APIs und Dateisystem-Kontexten.
• Vollständiges Schema:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://user:pass@localhost/db"],
      "env": { "PGPORT": "5432" }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx..." }
    }
  }
}

4. .claude/agents/ (Subagenten-Definitionen)¶

• Dateipfad: .claude/agents/<name>.md (Projekt) bzw. ~/.claude/agents/<name>.md (User-weit, projektübergreifend)
• Format: Markdown mit YAML-Frontmatter (name, description, tools, model)
• Zweck: Wiederverwendbare, spezialisierte Subagenten mit eigenem System-Prompt, eigenem Kontextfenster und eingeschränkten Tool-Rechten — siehe 2.4.

5. .claude/skills/ (Skill-System) & .claude/commands/ (Slash Commands)¶

• Dateipfad Skills: .claude/skills/<skill_name>/SKILL.md (Projekt) bzw. ~/.claude/skills/<skill_name>/SKILL.md (User-weit)
• Bestandteile eines Skills:
  • SKILL.md (YAML-Frontmatter: description, optional disable-model-invocation, argument-hint + Markdown-Anweisungen)
  • Beliebige Zusatzdateien im selben Ordner (Skripte, Vorlagen, Referenzdokumente) — werden erst bei Bedarf nachgeladen, nicht bei Sessionstart.
• Dateipfad Commands (Legacy-/Kurzform): .claude/commands/<name>.md (Projekt) bzw. ~/.claude/commands/<name>.md (User-weit) — eine einzelne flache Markdown-Datei statt eines ganzen Ordners.
  • .claude/commands/deploy.md und .claude/skills/deploy/SKILL.md erzeugen beide denselben Befehl /deploy und funktionieren technisch identisch (Slash Commands wurden mit dem Skill-System zusammengeführt).
  • Nutze .claude/commands/ für kurze Ein-Datei-Befehle ohne Zusatzdateien; nutze .claude/skills/<name>/ sobald du Skripte/Vorlagen mitliefern, disable-model-invocation setzen oder Claude den Skill selbstständig triggern lassen willst.
  • $ARGUMENTS im Dateitext wird durch den Text ersetzt, der nach /name folgt, z. B. /deploy staging.
• Kein Registrierungs-JSON nötig: Beide werden automatisch erkannt. Für teamweite/geteilte Skills bzw. Commands nutzt man stattdessen Plugins (siehe 9.2).

6. .claude/rules/ (Pfadgebundene Zusatzregeln)¶

• Dateipfad: .claude/rules/*.md, rekursiv (auch Unterordner wie frontend/, backend/)
• Zweck: Regeln, die nur geladen werden, wenn Claude an passenden Dateien arbeitet — hält CLAUDE.md schlank.
• Beispiel mit Pfadbindung:

  ---
  paths:
    - "src/api/**/*.ts"
  ---
  # API Development Rules
  - Alle Endpoints benötigen Input-Validierung.
  - Fehlerantworten folgen dem Standardformat.
  

  Regeln ohne paths-Feld laden unconditional, mit derselben Priorität wie .claude/CLAUDE.md.

7. Umgebungsvariablen (CLI Environment Variables Overrides)¶

Im Terminal können globale CLI-Einstellungen durch Umgebungsvariablen überschrieben werden:

Übersichtstabelle aller Konfigurationsdateien¶

2. Phase: Agent-Dateien, Skills (SKILL.md), Subagenten & Hooks¶

2.1 CLAUDE.md als zentrale Regeldatei¶

Claude Code liest ausschließlich CLAUDE.md (nicht AGENTS.md) für projektweite Verhaltensregeln — siehe 1.5 Punkt 1 zur Ladereihenfolge und AGENTS.md-Kompatibilität per Import.

• Beispiel CLAUDE.md:

  # Projektregeln
  
  ## Code-Qualität & Safety
  - Nutze in Rust niemals `unsafe` ohne explizite Sicherheitsbegründung in Kommentaren.
  - Verwende keine Platzhalter oder Stubs; jede Funktion muss vollständig implementiert werden.
  - Führe nach jeder Änderung `cargo check` und `cargo test` durch.
  
  ## Architektur-Vorgaben
  - Halte strikt die Hexagonale Architektur (Ports & Adapters) ein.
  

• Für Regeln, die zwingend und ohne Interpretationsspielraum durchgesetzt werden müssen (z. B. „niemals direkt auf main pushen"), reicht CLAUDE.md nicht aus — Claude behandelt den Inhalt als Kontext, nicht als harte Vorgabe. Dafür sind Hooks (siehe 2.6) oder permissions.deny das richtige Werkzeug.

2.2 Custom Skills (SKILL.md) – Modulare Fähigkeiten¶

Skills erlauben es, Claude Code wiederverwendbare Anweisungen, Workflows und Skripte beizubringen. Sie werden entweder automatisch von Claude aufgerufen (modellgesteuert, basierend auf der description) oder explizit per /skill-name getriggert.

• Struktur eines Skills: .claude/skills/<skill_name>/

  • SKILL.md (Enthält YAML-Frontmatter mit description sowie Anweisungen)
  • Optional beliebige Zusatzdateien (Skripte, Vorlagen, Referenzdokumente) im selben Ordner

• Beispiel .claude/skills/rust_security_audit/SKILL.md:

  ---
  description: Führt ein vollständiges Security-Audit mit cargo audit, clippy und Miri durch. Nutzen bei Sicherheits-Reviews oder vor Releases.
  ---
  
  # Rust Security Audit Workflow
  
  1. Führe `cargo audit` aus und fange bekannte Vulnerabilities ab.
  2. Führe `cargo clippy -- -D warnings` aus.
  3. Prüfe alle `unsafe`-Blöcke im Codebase und starte `cargo miri test`.
  

• Argumente an Skills übergeben: $ARGUMENTS im Skill-Text wird durch den Text ersetzt, der nach /skill-name folgt, z. B. /rust_security_audit src/worker.rs.

• Nur manuell aufrufbar machen: disable-model-invocation: true im Frontmatter verhindert, dass Claude den Skill selbstständig triggert — sinnvoll für destruktive oder teure Workflows.
• Teilen im Team: Für Skills, die über ein einzelnes Projekt hinaus verteilt werden sollen, siehe Plugins statt Kopieren des .claude/skills/-Ordners.

2.3 Custom Slash Commands¶

Slash Commands und Skills wurden technisch zusammengeführt: eine flache Datei .claude/commands/deploy.md und ein Skill-Ordner .claude/skills/deploy/SKILL.md erzeugen beide denselben Befehl /deploy und funktionieren identisch. Für neue Commands empfiehlt sich die Skill-Ordnerstruktur, weil sie zusätzlich Zusatzdateien, Tool-Beschränkungen und automatische Modellauswahl erlaubt.

• Eingebaute Commands (Auswahl): /init, /context, /compact, /memory, /cost, /resume, /rewind, /permissions, /plugin, /agents, /doctor.

2.4 Subagenten-Dateien & Subagenten-Workflow¶

Für komplexe, vielschichtige Aufgaben kann Claude Code Subagenten spawnen. Jeder Subagent läuft in seinem eigenen isolierten Kontextfenster mit eigenem System-Prompt, eigenen Tool-Rechten und ggf. eigenem Modell, und gibt nur eine Zusammenfassung an den Hauptagenten zurück.

• Definitionsdatei: .claude/agents/<name>.md (Projekt) oder ~/.claude/agents/<name>.md (User-weit)
• Beispiel .claude/agents/code-auditor.md:

  ---
  name: code-auditor
  description: Prüft Code-Qualität, Linter-Compliance und Borrow-Checker-Warnungen. Proaktiv nach größeren Refactorings einsetzen.
  tools: Read, Grep, Glob, Bash
  model: sonnet
  ---
  
  Du bist ein spezialisierter Code-Auditor für Rust-Projekte. Prüfe jede Datei
  auf Clippy-Warnungen, unsauberes Error-Handling und fehlende Tests, bevor
  du eine Zusammenfassung an den Hauptagenten zurückgibst.
  

• Typische Rollen:

  • Research-Subagent: Durchsucht die Codebase oder Dokumentation, ohne Dateien zu verändern.
  • Test-Generator-Subagent: Erstellt isoliert Unit-Tests für neue Module.
  • Code-Auditor-Subagent: Prüft Code-Qualität, Linter-Compliance und Borrow-Checker.

• Subagenten per Prompt beauftragen:

  "Starte einen Subagenten zur Recherche der Datenbank-Migrationen. Lass einen zweiten Subagenten parallel die API-Tests in tests/api.rs schreiben."

• Persistentes Gedächtnis pro Subagent: Über das Frontmatter-Feld memory kann ein Subagent ein eigenes Auto-Memory-Verzeichnis führen, getrennt von dem des Hauptagenten.

• Sichtbarkeit prüfen: /context zeigt registrierte Subagenten unter „Custom Agents" an.

2.5 Model Context Protocol (MCP) Integration¶

Binde externe Tools und Datenbanken über MCP in Claude Code ein:

claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres postgresql://user:password@localhost/mydb

2.6 Hooks — ereignisgesteuerte Automatisierung¶

Hooks führen bei definierten Lebenszyklus-Ereignissen automatisch ein Shell-Kommando aus — unabhängig davon, was das Modell „entscheidet". Sie sind das richtige Werkzeug für harte Vorgaben, die CLAUDE.md nicht garantieren kann (z. B. „nach jedem Edit automatisch formatieren" oder „rm -rf immer blockieren").

• Konfiguriert in: hooks innerhalb von .claude/settings.json (oder hooks/hooks.json in einem Plugin)
• Wichtige Ereignisse (Auswahl von über 30):

• Beispiel: Nach jedem Schreib-/Edit-Zugriff automatisch cargo fmt prüfen:

  {
    "hooks": {
      "PostToolUse": [
        {
          "matcher": "Write|Edit",
          "hooks": [
            { "type": "command", "command": "cargo fmt --check", "timeout": 30 }
          ]
        }
      ]
    }
  }
  

• Blockieren statt nur beobachten: Ein PreToolUse-Hook kann per Exit-Code bzw. JSON-Antwort (permissionDecision: "deny") einen Tool-Aufruf verhindern — z. B. um rm -rf in Bash-Kommandos hart zu unterbinden, egal was das Modell vorschlägt.

2.7 Auto Memory — selbstständiges Lernen¶

Neben CLAUDE.md (von Menschen geschrieben) führt Claude Code ein zweites, komplementäres Gedächtnis: Auto Memory. Claude speichert dort eigenständig Erkenntnisse aus Korrekturen und Präferenzen, die es im nächsten Gespräch wiederverwendet — vollautomatisch, ohne dass jemand eine Datei pflegt.

• Speicherort: ~/.claude/projects/<project>/memory/ — ein MEMORY.md als Index plus optionale Themendateien (z. B. debugging.md).
• Was hineingehört: Build-Befehle, Debugging-Erkenntnisse, entdeckte Präferenzen — nicht redundant zu dem, was ohnehin im Code oder in CLAUDE.md steht.
• Ladeverhalten: Nur die ersten 200 Zeilen / 25 KB von MEMORY.md laden automatisch zu Sessionbeginn; Themendateien liest Claude bei Bedarf nach.
• Ein-/Ausschalten: autoMemoryEnabled in settings.json, oder Umschalter im /memory-Command.
• Einsehen & bearbeiten: /memory öffnet CLAUDE.md-Dateien und den Auto-Memory-Ordner zum direkten Editieren — alles ist normales Markdown.

3. Phase: Projekt-Initialisierung & Architektur-Planung¶

3.1 Workspace-Scan & Analyse¶

Starten der interaktiven CLI-Session:

claude

"Analysiere die aktuelle Projektstruktur. Lies die CLAUDE.md und verfügbaren Skills aus .claude/skills/."

3.2 Generierung des Architektur-Plans¶

Lass Claude Code vor der Implementierung einen detaillierten implementation_plan.md erstellen — idealerweise im Plan-Modus (siehe 9.1), damit dabei noch keine Dateien verändert werden:

"Erstelle einen meilensteinbasierten Implementierungsplan für ein verteiltes REST-Backend in Rust mit Axum und SQLx. Gliedere den Plan in Datenmodell, Business-Logik, API-Endpoints und Tests."

4. Phase: Autonomer TDD-Loop & Subagentic Coding¶

4.1 Test-Driven Development (TDD)¶

"Schreibe zuerst die Unit-Tests für das Benutzer-Authentifizierungs-Modul in tests/auth_test.rs. Führe danach cargo test aus, damit die Tests fehlschlagen (Red-Phase)."

4.2 Autonome Iterationsschleife¶

Claude Code führt den folgenden Zyklus eigenständig aus:

1. Dateiänderung vorschlagen & anwenden (über File-Editor-Tools).
2. Kompilierungs- & Test-Befehl ausführen (cargo test).
3. Compiler- & Borrow-Checker-Ausgaben lesen und Code anpassen.
4. Schleife wiederholen, bis alle Tests grün sind.

5. Phase: Multi-File Refactoring & Debugging¶

5.1 Dateiübergreifendes Refactoring¶

"Refaktorisier das Error-Handling im gesamten Projekt. Erstelle einen zentralen AppError-Enum in src/error.rs und passe alle Datenbank- und API-Aufrufe an."

5.2 Debugging mit Subagenten¶

"Beauftrage einen Debugger-Subagenten, um den Stacktrace der Panik in src/worker.rs zu analysieren und eine Behebung vorzuschlagen."

6. Phase: Qualitäts-Audits & Sicherheit (Quality Engineering)¶

6.1 Ausführen des Custom Security Skills¶

"Führe den Skill rust_security_audit aus .claude/skills/ aus."

6.2 Linter- & Formatting-Checks¶

"Führe cargo clippy -- -D warnings und cargo fmt aus. Behebe alle Warnungen."

7. Phase: Dokumentation & Git-Workflow¶

7.1 Generierung von Rustdoc & Doctests¶

"Erstelle für alle öffentlichen Funktionen in src/ Rustdoc-Kommentare (///) inklusive ausführbarer Code-Beispiele (Doctests)."

7.2 Automatisierter Git-Commit & Pull Request Process¶

1. Git Status & Diff analysieren: git status / git diff
2. Commit mit Conventional Message: git commit -m "feat(auth): implement JWT validation"
3. Pull Request via GitHub CLI: gh pr create

8. Phase: Production Build, Packaging & Release (Fertiges Produkt)¶

8.1 Release Build & Docker-Containerisierung¶

"Erstelle ein Multi-Stage Dockerfile für eine statisch gelinkte Rust-Anwendung (musl target) auf scratch."

8.2 CI/CD-Pipeline Erstellung¶

"Erstelle einen GitHub Actions Workflow .github/workflows/ci.yml, der bei jedem Push Tests, Linter (clippy), Formatting (fmt) und Docker-Builds ausführt."

9. Phase: Skalierung — Permissions, Plugins, Headless-CI & Team-Rollout¶

9.1 Permission-Modi & Plan Mode¶

Claude Code fragt standardmäßig vor riskanten Aktionen (Dateischreibzugriffe, Shell-Kommandos) nach. Das Verhalten lässt sich fein steuern:

• Plan Mode: Claude analysiert und plant, verändert aber keine Dateien und führt keine Kommandos aus — ideal für die Architekturphase (siehe 3.2).
• permissions.allow / .deny / .ask in settings.json: Tool-Pattern-Strings wie "Bash(npm run *)" oder "Read(./.env*)" erlauben granulare Freigaben, statt pauschal „Auto-Approve" zu setzen.
• /permissions: Zeigt und verwaltet die aktuell wirksamen Regeln in der Session.
• Sandbox-Isolation: sandbox.enabled (i. d. R. über Managed Settings gesetzt) kapselt Tool-Ausführung zusätzlich auf Betriebssystemebene.

9.2 Plugins & Marketplaces¶

Skills, Subagenten, Hooks und MCP-Server lassen sich zu einem Plugin bündeln und darüber teamweit oder öffentlich verteilen — die Alternative zum manuellen Kopieren von .claude/-Ordnern.

• Struktur: .claude-plugin/plugin.json (Manifest mit name, description, version) plus skills/, agents/, hooks/hooks.json, .mcp.json auf Plugin-Root-Ebene.
• Lokal testen:

  claude --plugin-dir ./my-plugin
  

• Verteilen: Über eine Marketplace-Registrierung (/plugin marketplace add <repo>) installieren Teammitglieder das Plugin mit /plugin install. Anthropic pflegt zusätzlich eine offizielle (claude-plugins-official) und eine kuratierte Community-Marketplace (claude-community).
• Schnellstart im eigenen Skills-Ordner: claude plugin init my-tool legt ein Plugin direkt unter ~/.claude/skills/ an, das ohne Marketplace automatisch lädt.

9.3 Headless-Modus für CI/CD & Skripting¶

Neben dem interaktiven Terminal lässt sich Claude Code nicht-interaktiv aus Skripten und Pipelines heraus aufrufen:

claude -p "Prüfe, ob alle öffentlichen Funktionen Doctests haben, und liste Lücken auf." --output-format json

9.4 Session-Management & Kontextkontrolle¶

• --resume / /resume: Eine unterbrochene Session fortsetzen.
• /rewind: Datei-Änderungen einer Session gezielt zurückrollen (Checkpoints).
• /context: Zeigt, was aktuell tatsächlich im Kontextfenster geladen ist (CLAUDE.md-Dateien, Subagenten, Rules) — das zentrale Debugging-Werkzeug, wenn Instruktionen scheinbar ignoriert werden.
• /compact und autoCompactWindow: Steuern, wann und wie der Gesprächsverlauf komprimiert wird, ohne projektweite CLAUDE.md-Regeln zu verlieren (diese werden nach Compaction automatisch neu geladen).
• /cost: Laufende Kostenübersicht der Session.

9.5 Team- & Enterprise-Rollout¶

• Managed Settings: IT-Abteilungen verteilen managed-settings.json sowie eine organisationsweite CLAUDE.md zentral (macOS: /Library/Application Support/ClaudeCode/, Linux/WSL: /etc/claude-code/, Windows: C:\Program Files\ClaudeCode\) — per MDM, Group Policy oder Ansible, nicht überschreibbar durch Nutzereinstellungen.
• claudeMdExcludes: In großen Monorepos lassen sich fremde, irrelevante CLAUDE.md-Dateien anderer Teams gezielt ausschließen.
• IDE-Integration: VS Code-Extension und JetBrains-Plugin spiegeln denselben Agenten inklusive CLAUDE.md/Skills/Hooks in die jeweilige IDE.

Checkliste: Vom Setup bis zum Release mit Claude Code¶

Verwandte Themen¶

• Claude Code Praxis-Handbuch — bestehendes, thematisch überlappendes Praxis-Handbuch zu Claude Code
• Entwickler-Curriculum: Software Engineering, Systems Programming mit Rust & Agentic AI — übergeordnetes Curriculum
• KI-Entwicklungsworkflow für Rust — der 9-phasige Rust-spezifische Workflow, den dieser Leitfaden mit Claude-Code-Werkzeugen unterlegt
• Rust-Praxisprojekte mit Claude Code — wendet Skills, Subagenten und Hooks aus dieser Seite auf drei konkrete Projekte an

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).