Claude Code CLI effizient nutzen: 7 Tipps und Automatisierung in der Praxis

Im Terminal lief der Test zum 18. Mal fehl. Hätte ich /clear früher gekannt, wäre es nicht so spät geworden.

Offizielle Daten: Claude Code löst im SWE-bench-Test autonom 80,9 % der Code-Probleme. Die Frage ist – nutzen Sie wirklich die Kernfunktionen? Die meisten starten Claude Code, tippen claude, chatten kurz, ändern etwas Code – fertig. Von über 50 Befehlen nutzen sie 3–5 und verschenken rund 90 % des Effizienzpotenzials.

Dieser Artikel teilt 7 CLI-Tipps und 3 Automatisierungs-Praxisfälle – systematisch nach Szenario, von Basisbefehlen über Kontextverwaltung bis Hooks und CI/CD. Danach steigen Sie von „kann es“ zu „nutzt es wirklich effizient“.

Kapitel 1: CLI-Basis – Start, Modi, Befehle

Ohne solide Basis bringen spätere Tricks wenig.

1.1 Drei Startarten, jeweils mit Zweck

claude              # Interaktiv im aktuellen Verzeichnis
claude -c           # Letzte Session fortsetzen
claude --print "Typdefinition dieser Funktion prüfen"  # Einmalabfrage, dann Ende

Viele kennen nur die erste. -c ist besonders praktisch: Session gerade geschlossen, noch eine Frage offen – claude -c knüpft am Kontext an, ohne das Projekt neu zu erklären.

--print nutze ich für schnelle Checks – z. B. ob eine Typdefinition stimmt, ein Befehl, kein voller Chat. Spart Zeit.

1.2 Drei Arbeitsmodi nach Szenario

Kernkonzept in der offiziellen Doku, auch in Tiefgang-Artikeln zu Cloud-Angeboten:

Im Default-Modus bestätigen Sie jede Datei- und Befehlsänderung. Umständlich, aber sicher – ideal zum Erkunden fremder Repos.

Auto-Accept: Dateiänderungen laufen automatisch, Shell-Befehle weiter mit Bestätigung. Bei Batch-Refactoring in der eigenen Codebasis arbeitet Claude durch, Sie prüfen am Ende – oft doppeltes Tempo.

Plan-Modus für komplexe Fragen: Claude liest das Projekt, liefert einen detaillierten Plan, ändert noch nichts. Plan passt? Dann auf Auto-Accept wechseln und ausführen.

1.3 Drei Slash-Befehle, die Sie kennen sollten

Von über 50 Befehlen nutzen die meisten unter 10 %. Diese drei am häufigsten:

/init     # Projekt scannen und CLAUDE.md erzeugen
/clear    # Session-Verlauf leeren
/compact  # Kontext komprimieren, Token sparen

/init beim ersten Start in einem neuen Projekt – Scan der Codebasis, Config mit Struktur, Abhängigkeiten, Konventionen.

/clear behandeln wir gleich – für mich der größte Effizienzhebel.

/compact wenn der Kontext voll ist: Wesentliches bleibt, Redundanz fliegt raus. Sinnvoll nach vielen Runden in einer Session.

Kapitel 2: Kontextverwaltung – Leeren, Komprimieren, Parallel

Builder.io nennt /clear den „größten Produktivitätshebel“. Eine Woche Test – stimmt.

2.1 /clear richtig einsetzen

Wann leeren?

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Beim Taskwechsel.

Sie haben mit Claude 20 Runden einen Bug eingegrenzt – dann kommt ein dringendes Issue. Viele wechseln einfach das Thema in derselben Session.

Falsch.

Jetzt /clear – alter Verlauf weg. Warum? Er frisst Token und passt nicht zur neuen Aufgabe. Claude wird vom alten Kontext „verschmutzt“, die Qualität für das neue Thema sinkt.

Meine Gewohnheit: neuer Task → /clear, kurz Kontext zur neuen Aufgabe. Deutlich besser als im alten Thread weiterzureden.

2.2 Wann /compact

Eine Aufgabe, viele Runden – dutzende Dateien, 30+ Nachrichten – der Kontext ist lang.

/compact presst die Historie: geänderte Dateien, wichtige Entscheidungen bleiben, Ballast weg.

Faustregel: ab etwa 30 Nachrichten einmal compact. Nicht exakt messen – „fühlt sich lang an“ reicht.

2.3 Parallele Sessions

Laut Claude Help Center: 3–5 Sessions parallel, je eine in einem eigenen git worktree, verschiedene Teile der Codebasis.

git worktree: ein Repo, mehrere Arbeitsverzeichnisse, je eigenes Branch.

# Worktree anlegen
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# Claude in verschiedenen Worktrees
cd ../feature-A && claude
cd ../feature-B && claude

Zwei Terminals: Claude an Feature A, parallel Feature B – getrennte Kontexte.

Praktisch: Ctrl+B schiebt lange Bash-Befehle in den Hintergrund – bei npm install oder langen Tests blockiert die Oberfläche nicht.

Kapitel 3: Automatisierung – Hooks, Routines, CI/CD

Bisher manuell. Jetzt Automatisierung – Claude erledigt Wiederholungen nebenbei.

3.1 Hooks als Task-Trigger

Hooks sind das Automatisierungszentrum von Claude Code. Drei Haupttypen:

Am nützlichsten: PostToolUse – nach jeder Codeänderung automatisch Tests.

// Beispiel in settings.json
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

Effekt: Nach jedem Write-Tool-Lauf npm test. Scheitert etwas, sieht Claude die Ausgabe und kann nachbessern.

3.2 Routines: wiederkehrende Abläufe

Routines für wiederkehrende Prozesse.

Offizielles Beispiel: Bedingung erkannt (z. B. Datei existiert) → vordefinierte Befehlskette.

Die Konfiguration ist noch etwas schwer – ich nutze es nicht flächendeckend in Produktion. Die Richtung lohnt sich: feste Checks automatisieren statt Claude jedes Mal zu erinnern.

3.3 CI/CD: GitHub Actions in der Praxis

Headless-Modus der Doku: claude -p.

In GitHub Actions: automatisches PR-Review, Issue-Umsetzung, Security-Audit.

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Im GitLab-Blog drei Workflows skizziert:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

1. MR aus Issue
2. Performance-Regression analysieren
3. Feature implementieren und per CI prüfen

Ich bin noch am Ausarbeiten – das Potenzial ist klar: Claude Code als Teil der CI/CD-Pipeline.

Kapitel 4: Praxisfälle – von Config bis Automatisierung

Theorie reicht – so sieht es in der Praxis aus.

Fall 1: Git-Commit in einem Satz

Mein häufigstes Szenario.

Klassisch: git add, git status, Message schreiben, git commit – Minuten.

Mit Claude Code:

claude
> commit these changes

Ein Satz. Claude liest die Änderungen, formuliert eine passende Commit-Message, committed. Es liest den Diff und trifft die Message auf die eigentliche Absicht.

In Tests waren die Messages oft besser als meine – weil wirklich der Diff gelesen wurde, nicht geschätzt.

Fall 2: PostToolUse-Hook mit automatischen Tests

Die vollständige Hook-Config:

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write" nur bei Dateiänderungen. npm run test:related ist mein Skript – nur Tests zu geänderten Dateien, nicht die ganze Suite.

Effekt: Innerhalb von 30 Sekunden nach einer Änderung das Testergebnis. Scheitert etwas, repariert Claude oft selbst.

Stolperfalle: anfangs npm test Vollsuite – zu langsam, Timeouts. Auf related Tests umgestellt – Problem weg.

Fall 3: GitHub Actions für automatisches PR-Review

Config aus der offiziellen Doku:

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Bei PR-Erstellung oder Update reviewt Claude und kommentiert – Qualität, Bugs, Security, Performance.

Ein Monat Nutzung: mehr gefundene Bugs als bei manuellem Review – weil nichts übersprungen wird.

Kapitel 5: Produktivität – schlanke Config und Toolchain

Aus Marmelab und Builder.io: den gesamten Workflow glätten.

5.1 Kurze CLAUDE.md

Viele schreiben CLAUDE.md endlos – Hintergrund, Stack, Stil, Verbote … tausende Zeichen.

Marmelab sagt das Gegenteil: CLAUDE.md so kurz wie möglich.

Lange Configs → „überbefolgen“: Claude liest ständig Regeln und wird unflexibel. Außerdem kosten sie Token.

Empfehlung: 3–5 Kernregeln, Config als „Vereinfachungsfunktion“ für die Codebasis:

# CLAUDE.md
- TypeScript strict, alle Variablen typisiert
- Komponenten unter src/components/
- Tests im selben Ordner wie Quellcode
- Kein var, nur const und let

Das reicht.

5.2 Bash-Wrapper statt Doku

Builder.io: Keine langen READMEs – Bash-Wrapper.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Statt „npm install, Env setzen, dev server“ in einem README:

#!/bin/bash
# dev.sh - Entwicklungsumgebung schnell starten

npm install
source .env.local
npm run dev

In Claude Code: „run dev.sh“. Einfach.

Gleiches für Claude: häufige Befehlsketten als Alias oder Skript – kein langer Befehl jedes Mal.

5.3 MCP-Server: Security und Output-Filter

MCP (Model Context Protocol) für die Toolchain.

Zwei Beispiele:

Snyk MCP Server: Claude prüft beim Coden Sicherheitslücken und Dependencies – ohne manuellen Hinweis bei neuen Paketen.

rtk: CLI-Ausgaben filtern und komprimieren. Lange Logs (z. B. npm install) fressen Token – rtk behält das Wesentliche.

Beide noch nicht voll integiert – Richtung klar: Claude Code nicht nur zum Schreiben, sondern an Security und Dependency-Tools.

Fazit

Kernpunkte:

Basisbefehle sitzen – drei Startarten, drei Modi, je nach Szenario. Nicht nur claude ohne Optionen.

Kontext nicht vernachlässigen – Taskwechsel → /clear, lange Threads → /compact. Spart viel Token.

Automatisierung lohnt sich – Hooks, GitHub Actions: Anfangslernen, später mehrfacher Zeitgewinn.

Config knapp – kurze CLAUDE.md, komplexe Abläufe als Skripte. Länger ≠ besser.

Empfehlungen:

1. Heute: /clear in der aktuellen Session – spüren, wie „aufgeräumt“ es wirkt
2. Diese Woche: einen PostToolUse-Hook – nach jeder Änderung Tests
3. Langfristig: Claude Code in CI/CD, Standard-Tool im Team

Zur Vertiefung der Claude-Code-Config: Serie Teil 1 – CLAUDE.md und höhere Trefferquote. Teil 2 – Subagents statt endloser Antworten. Dieser Artikel ist Teil 7 der Serie, Fokus CLI.

Alles hier habe ich selbst erst nach Fehlern gelernt. Hoffentlich sparen Sie ein paar Umwege und holen Tempo früher rein.