Lesenswert

Claude Code als System: Regeln, Rituale und ein Gedächtnis, das lernt

Veröffentlicht 03.07.2026 Aktualisiert 04.07.2026

Von Darth Vaper

13 Minuten Lesezeit

Claude Code ist schon ohne jede Konfiguration nützlich. Aber ein KI-Assistent ohne Rahmen vergisst nach jeder Session alles, trifft Annahmen statt deine Konventionen zu kennen und wiederholt dieselben Fehler. Mit ein wenig Struktur wird aus dem Werkzeug ein mitdenkender Kollege, der deine Arbeitsweise, deine Projekte und deine Vorlieben kennt.

Dieser Leitfaden zeigt einen praxiserprobten Rahmen: klare Regeln, ein Projekt-Gerüst und ein Gedächtnis, das über Sessions hinweg Bestand hat und dazulernt. Ziel ist, dir den langen Weg des Ausprobierens zu ersparen.

Dieser Beitrag baut auf der Einführung in Claude Code auf. Wenn du Claude Code noch nie benutzt hast, fang am besten dort an.

Die vier Bausteine

Ein gutes Setup steht auf vier Säulen. Jede löst ein eigenes Problem, und zusammen ergeben sie einen Assistenten, der mit jeder Session ein Stück besser wird.

Globale Regeln – gelten für alle Projekte (wer du bist, wie du arbeitest).
Projekt-Regeln – gelten nur im jeweiligen Repository (Architektur, Deployment, Konventionen).
Rituale – wiederkehrende Abläufe (Tagesstart, Aufräumen, Doku).
Gedächtnis – persistente Notizen, die über Sessions Bestand haben und wachsen.

1. Die Konfigurationsebenen verstehen

Claude Code liest Anweisungen aus mehreren Dateien. Wichtig ist zu wissen, welche Datei wofür zuständig ist – sonst landet alles in einer riesigen Datei, die niemand mehr pflegt.

flowchart TB
    subgraph G["~/.claude/ · global"]
        A["CLAUDE.md<br/>persönliche Arbeitsregeln"]
        S["settings.json<br/>Berechtigungen · Hooks · Env"]
        M["memory/ + MEMORY.md<br/>persistentes Gedächtnis"]
    end
    subgraph P["&lt;projekt&gt;/ · pro Repo"]
        PC["CLAUDE.md<br/>Architektur · Deployment"]
    end
    A --> CC(["Claude Code<br/>Session"])
    S --> CC
    M --> CC
    PC --> CC

Datei	Geltungsbereich	Inhalt
`~/.claude/CLAUDE.md`	Alle Projekte	Persönliche Arbeitsregeln, Vorlieben, Konventionen
`<projekt>/CLAUDE.md`	Nur dieses Projekt	Architektur, Deployment, projektspezifische Regeln
`~/.claude/settings.json`	Harness-Verhalten	Berechtigungen, Hooks, Umgebungsvariablen
`~/.claude/*.md` (ausgelagert)	Bei Bedarf nachgeschlagen	Details, die die Hauptdatei aufblähen würden

Faustregel: Alles, was in jedem Projekt gelten soll → global. Alles, was nur dieses eine Repo betrifft → ins Projekt. Details, die man selten braucht → in eine separate Datei auslagern und aus der CLAUDE.md nur darauf verweisen.

Die CLAUDE.md wird bei jeder Session in den Kontext geladen. Halte sie schlank. Lange Referenzen (Infrastruktur-Details, seltene Abläufe) gehören in ausgelagerte Dateien, die gezielt nachgeschlagen werden.

2. Globale Arbeitsregeln

In ~/.claude/CLAUDE.md definierst du einmalig, wie Claude grundsätzlich für dich arbeiten soll. Bewährte Abschnitte:

Wer du bist & wie du arbeitest – Rolle, technische Tiefe, Sprache der Antworten.
Git-Konventionen – welche Identität für Commits, welcher Stil für Commit-Messages, ob automatische Signaturen erwünscht sind. Der Hinweis „Messages sollen aussehen wie von einem Menschen geschrieben” spart späteres Aufräumen.
Berechtigungs-Etikette – was tun, wenn ein Tool-Aufruf abgelehnt wird? Nicht stur wiederholen, keine Umgehung suchen, sondern erklären was gebraucht wird und eine Alternative anbieten.
Umgang mit Secrets – Grundsatz: Werte niemals lesen, ausgeben oder loggen; nur über Umgebungsvariablen referenzieren. Wertberührende Schritte macht der Mensch selbst.
Wiederkehrende Werkzeuge – ein kanonisches Skript pro Aufgabe (z. B. Mailversand, Bildgenerierung), per absolutem Pfad aus jedem Projekt aufrufbar. Das spart Setup pro Projekt.

So sieht ein Ausschnitt aus einer echten globalen CLAUDE.md aus – kurz, konkret und jeweils mit Begründung:

        
      
## Git-Commits
- Commit-Identität: immer die globale git-Config verwenden, NIE per `-c` überschreiben.
- Commit-Messages OHNE automatische Signaturen ("Generated with …", "Co-Authored-By: …").
- Grund: Die Messages sollen aussehen wie von einem Menschen geschrieben.

## Berechtigungen
- Wird ein Tool-Aufruf abgelehnt: NICHT stur wiederholen, KEINE Umgehung suchen.
- Stattdessen kurz erklären, was gebraucht wird und wofür – und eine Alternative anbieten.

## Sprache
- Antworten immer auf Deutsch; Code-Bezeichner im Original belassen.

Man sieht das Muster: jede Zeile ist eine Entscheidung, versehen mit einem knappen Warum.

Formuliere Regeln als Entscheidungen mit Begründung, nicht nur als Verbote. „Nie X, weil Y” hilft Claude, den Sinn auf neue Situationen zu übertragen.

3. Projekt-Regeln

Pro Repository eine schlanke CLAUDE.md mit dem, was nur hier gilt:

Architektur-Eckpunkte – wo läuft was? (z. B. „Apps laufen auf separaten VMs, nicht lokal”.)
Deployment-Workflow – die konkreten Schritte von „lokal geändert” bis „läuft in Produktion”.
Konventionen – Namensschema für Dateien, Ablageorte, projektspezifische Kommandos.

Ein Beispiel, wie das für eine typische Web-App aussehen kann:

        
      
# Meine-App

## Architektur & Deployment
- App läuft auf einer separaten VM (NICHT lokal!). Lokal ist nur Entwicklung.
- Reverse Proxy terminiert SSL; die App hört nur intern auf Port 8080.
- Deploy: `scp` auf die VM → dort `docker compose up -d --build`.

## Konventionen
- Branch-Namen: `feature/<kurz>`, `fix/<kurz>`.
- Datenbank-Änderungen immer über Migrations, nie direkt.
- Vor jedem Commit: `npm test`.

Solche Sätze klingen banal – aber genau sie verhindern, dass Claude die App versehentlich lokal startet oder direkt auf der Datenbank herumschreibt.

Ein guter Startpunkt ist der eingebaute Befehl /init – er scannt das Repository und legt eine erste CLAUDE.md mit Codebase-Dokumentation an, die du dann verfeinerst.

        
      
# Im Projektverzeichnis
cd ~/mein-projekt
claude
# dann in der Session:
/init

4. Rituale – wiederkehrende Abläufe automatisieren

Der größte Produktivitätssprung entsteht durch benannte Rituale: kurze Trigger-Wörter, die einen festgelegten Ablauf auslösen. So musst du den Ablauf nicht jedes Mal neu erklären.

flowchart LR
    T1["Stand?<br/>Wo waren wir?"] --> R1["Tagesstart:<br/>offene Punkte + letztes<br/>Session-Log + git status"]
    T2["merk: ...<br/>nicht vergessen: ..."] --> R2["Doku-Merker:<br/>sofort in<br/>OFFENE-PUNKTE.md"]
    T3["Feierabend<br/>Schluss für heute"] --> R3["Aufräumen:<br/>Code sichern, Doku,<br/>Session-Log, Gedächtnis"]

Bewährte Rituale:

Ritual	Trigger (Beispiele)	Was passiert
Tagesstart	„Stand?”, „Wo waren wir?”, „Los geht’s”	Offene Punkte + letztes Session-Log + `git status`/`log` → kompakte Übersicht
Doku-Merker	„merk: …”, „nicht vergessen: …”	Sofort in eine `OFFENE-PUNKTE.md` notieren, später abarbeiten
Aufräumen	„Feierabend”, „Schluss für heute”	Code sichern → Doku aktualisieren → Session-Log schreiben → Gedächtnis pflegen. Erst Übersicht zeigen, dann loslegen.

Umsetzung: Beschreibe jedes Ritual einmal (am besten in einer ausgelagerten rituale.md) und verweise in der globalen CLAUDE.md mit einer kleinen Trigger-Tabelle darauf.

Konkret sieht das so aus. In der ausgelagerten rituale.md steht der Ablauf einmal ausführlich:

        
      
## Aufräumen / Feierabend
Trigger: "Feierabend", "Schluss für heute", "Aufräumen".
Ablauf (erst Übersicht zeigen, dann auf Go warten):
1. Uncommittete Änderungen sichten und committen.
2. README/Doku aktualisieren, falls nötig.
3. Session-Log schreiben – inkl. Ursache → Lösung der gelösten Probleme.
4. Offene Punkte notieren, Erledigtes streichen.

Im Alltag genügt dann ein einziges Wort:

Du:     Feierabend
Claude: Heute berührt: Projekt-A (offener Commit + README), Projekt-B (nur Log).
        Räume ich so auf?
Du:     ja

Statt den kompletten Ablauf jedes Mal zu diktieren, tippst du „Feierabend” – den Rest kennt Claude.

Für echte Automatik („immer wenn X, dann Y”) brauchst du Hooks in der settings.json – die führt der Harness aus, nicht Claude selbst. Ein reiner Merksatz in der CLAUDE.md ist eine Bitte, kein garantierter Auslöser.

5. Hooks – wenn Automatik wirklich automatisch sein muss

Rituale sind Merksätze: Claude soll sie befolgen, tut es aber nur, wenn der Kontext stimmt. Für Abläufe, die garantiert und jedes Mal laufen müssen, gibt es Hooks – Shell-Kommandos, die der Harness selbst zu definierten Zeitpunkten ausführt, unabhängig davon, was das Modell gerade „denkt”.

Hooks stehen in der settings.json (global unter ~/.claude/ oder pro Projekt unter .claude/). Jeder Hook hängt an einem Event:

Event	Feuert …	Typischer Nutzen
`SessionStart`	beim Start einer Session	Kontext laden, „woran haben wir gearbeitet?” einblenden
`PreToolUse`	vor jedem Tool-Aufruf	riskante Kommandos abfangen oder blocken
`PostToolUse`	nach jedem Tool-Aufruf	automatisch formatieren, linten, Tests anstoßen
`Stop`	wenn Claude fertig antwortet	Benachrichtigung, Log-Eintrag

Ein bewusst harmloses Beispiel – eine Desktop-Benachrichtigung, sobald Claude eine Antwort abschließt:

        
      
{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "notify-send 'Claude Code' 'Antwort fertig'" }
        ]
      }
    ]
  }
}

Der Unterschied zum Ritual: Diese Benachrichtigung kommt immer, weil der Harness sie ausführt – nicht Claude. Genau deshalb sind Hooks das Werkzeug für „immer wenn X, dann Y”, während Rituale für „bei Bedarf sinnvoll” gedacht sind.

Ein praktischeres Beispiel ist Auto-Formatierung nach jeder Änderung. Dieser PostToolUse-Hook läuft, sobald Claude eine Datei per Edit oder Write verändert hat, und formatiert genau diese Datei:

        
      
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }
        ]
      }
    ]
  }
}

Zwei Details lohnen den Blick: Der matcher ist ein Regex auf den Tool-Namen – Edit|Write trifft beide Schreib-Tools. Das Kommando selbst bekommt die Details des Tool-Aufrufs als JSON über stdin; jq -r '.tool_input.file_path' fischt daraus den Pfad der geänderten Datei und reicht ihn per xargs an prettier weiter. So ist dein Code nach jeder Änderung sauber – ganz ohne dass Claude daran denken muss.

Hooks laufen mit deinen Rechten und ohne Rückfrage. Trag nur Kommandos ein, die du verstehst, und niemals etwas, das ungefragt Daten löscht oder nach außen sendet. Umgekehrt eignet sich gerade ein PreToolUse-Hook hervorragend, um genau solche Aktionen abzufangen.

Du musst Hooks nicht von Hand basteln: /update-config richtet Hooks, Berechtigungen und Umgebungsvariablen in der settings.json für dich ein.

6. Das Gedächtnis – der eigentliche Gewinn

Ohne Gedächtnis beginnt jede Session bei null. Es gibt zwei komplementäre Mechanismen, die zusammen ein wachsendes Langzeitgedächtnis ergeben.

a) Session-Logs (die Chronik)

Am Ende jeder nennenswerten Session eine kurze Zusammenfassung schreiben – mit Erkenntnissen, nicht nur einer Tätigkeitsliste:

Was wurde gemacht? (geänderte Dateien mit Kurzbeschreibung)
Ursache → Lösung bei gelösten Problemen – das ist das Wertvollste
Offene Punkte

Ablage nach festem Schema, z. B. YYYY-MM-DD_HH-MM_claude-<modell>_<beschreibung>.md in einem eigenen sessions/-Verzeichnis oder Repository. Beim nächsten Tagesstart wird hier nachgeschlagen – so knüpft Claude nahtlos an.

b) Strukturiertes Faktengedächtnis (das Wissen)

Ergänzend zu den Logs ein durchsuchbares Gedächtnis aus einzelnen Fakten. Bewährtes Muster: ein Verzeichnis, in dem jede Notiz eine eigene Datei ist, plus eine Index-Datei (MEMORY.md) mit je einer Zeile pro Notiz. Jede Notiz bekommt einen kleinen Kopf (Front Matter) mit Typ und Kurzbeschreibung:

        
      
---
name: deploy-immer-auf-vm
description: Apps werden nie lokal, sondern auf separaten VMs deployt
metadata:
  type: project   # user | feedback | project | reference
---

Deployment läuft grundsätzlich über separate VMs.
**Warum:** Die lokale Maschine ist nur Entwicklung.
**Wie anwenden:** Änderung bauen und auf die Ziel-VM ausrollen, nicht lokal starten.

Verwandt: [[reverse-proxy-setup]]

Sinnvolle Typen:

Typ	Wofür
`user`	Wer du bist – Rolle, Vorlieben
`feedback`	Korrekturen/Bestätigungen zu wie Claude arbeiten soll – immer mit Begründung
`project`	Laufende Vorhaben, Ziele, Randbedingungen, die nicht aus dem Code ablesbar sind
`reference`	Zeiger auf externe Ressourcen (Links, Dashboards, Tickets)

Ein feedback-Beispiel – entstanden, weil Claude einmal ungefragt auf main committet hat:

        
      
---
name: kein-direkt-commit-auf-main
description: Nie ungefragt auf main committen – immer Branch + Rückfrage
metadata:
  type: feedback
---

Nie direkt auf `main` committen.
**Warum:** main ist geschützt; Änderungen laufen über Review.
**Wie anwenden:** Branch anlegen, committen, Merge vorschlagen und auf Go warten.

Der Index MEMORY.md hält pro Notiz nur eine Zeile – das ist der Katalog, den Claude beim Start überfliegt und aus dem heraus er bei Bedarf die volle Notiz nachlädt:

        
- [Deploy immer auf VM](deploy-immer-auf-vm.md) – nie lokal starten
- [Kein Direkt-Commit auf main](kein-direkt-commit-auf-main.md) – Branch + Rückfrage

Wie es dazulernt: Wenn du Claude korrigierst („nein, mach das bitte so …”), lass es die Erkenntnis als feedback-Notiz festhalten. Beim nächsten Mal ist die Lektion präsent. Regelmäßig prüfen: Gibt es schon eine passende Notiz? Dann aktualisieren statt duplizieren. Falsches löschen.

Ein solcher Lernmoment im Zeitraffer:

Session 1
Du:     Warum hast du direkt auf main committet? Bitte nie ohne Rückfrage.
Claude: Verstanden – ich halte das als feedback-Notiz fest.
        (schreibt kein-direkt-commit-auf-main.md)

Session 2 – Tage später, neuer Chat ohne gemeinsamen Verlauf
Claude: Die Änderung ist fertig. Ich lege dafür einen Branch an und
        schlage den Merge vor – ok?

Zwischen beiden Sessions liegt keine Erinnerung im Chatverlauf – nur die Notiz auf der Festplatte. Genau das ist der Unterschied zu einem Assistenten, der bei null beginnt.

Was nicht ins Gedächtnis gehört: alles, was das Repository ohnehin festhält (Code-Struktur, Git-Historie, bereits dokumentierte Fixes). Sonst verwässert das Gedächtnis und wird unbrauchbar.

Gedächtnis spiegelt den Stand zum Zeitpunkt des Aufschreibens. Wenn eine Notiz eine Datei, Funktion oder ein Flag nennt, vor dem Empfehlen kurz prüfen, ob es das noch gibt.

7. Berechtigungen & Sicherheit

Berechtigungen bewusst vergeben. In der settings.json kannst du häufige, unkritische Kommandos erlauben (spart Nachfragen) und riskante ausdrücklich verweigern (Deny-Regeln). Der Befehl /fewer-permission-prompts schlägt sinnvolle Allowlist-Einträge vor.
Secrets nie im Klartext in Prompts, Dateien oder Logs. Verschlüsselt ablegen (z. B. mit sops/age) und nur als Umgebungsvariable referenzieren.
Unumkehrbares nur mit Bestätigung. Löschen, Überschreiben, nach außen senden – im Zweifel erst zeigen, dann tun.

8. Empfohlene Reihenfolge zum Aufsetzen

/init in einem bestehenden Projekt ausführen → erste Projekt-CLAUDE.md.
Globale ~/.claude/CLAUDE.md anlegen: Wer du bist, Git-Konventionen, Berechtigungs-Etikette, Sprache der Antworten.
Ein Ritual definieren (fang mit „Aufräumen/Feierabend” an) und ausprobieren.
Session-Logs einführen: festes Namensschema, eigenes Verzeichnis.
Faktengedächtnis starten: Verzeichnis + MEMORY.md-Index anlegen, die ersten drei bis fünf Fakten festhalten.
Iterieren: Immer wenn du Claude etwas erklärst, das dauerhaft gelten soll → als Regel oder Gedächtnis-Notiz festhalten. So wächst das Setup organisch mit.

Beispiel: das Setup an einem Arbeitstag

Wie greifen die Bausteine im Alltag ineinander? Ein typischer Ablauf:

Morgens tippst du „Stand?”. Claude liest die offenen Punkte und das letzte Session-Log und fasst zusammen: „Zuletzt: Login-Bug gefixt. Offen: Tests fehlen noch.”
Während der Arbeit greifen die globalen Regeln automatisch: Claude committet auf einem Branch statt auf main, weil eine feedback-Notiz genau das vorschreibt.
Beim Speichern läuft ein Hook und formatiert den Code – ohne dass jemand daran denken muss.
Du korrigierst eine Kleinigkeit („Fehlermeldungen bitte auf Deutsch”). Claude hält das als neue Gedächtnis-Notiz fest.
Abends sagst du „Feierabend”. Das Ritual sichert den Code, schreibt ein Session-Log mit der Erkenntnis des Tages und aktualisiert die offenen Punkte.

Am nächsten Morgen beginnt der Kreis von vorn – nur dass Claude jetzt eine Notiz mehr kennt und die deutschen Fehlermeldungen selbstverständlich sind. Kein einzelner Baustein ist spektakulär; ihr Zusammenspiel ist es.

Do & Don’t

✅ Do	❌ Don’t
Regeln kurz und mit Begründung formulieren	Alles in eine riesige `CLAUDE.md` stopfen
Große Referenzen auslagern, `CLAUDE.md` schlank halten	Code-Struktur oder Git-Historie ins Gedächtnis kopieren
Erkenntnisse (Ursache → Lösung) festhalten	Nur Tätigkeiten protokollieren
Ein kanonisches Werkzeug pro wiederkehrender Aufgabe	Secrets in Prompts/Dateien/Logs
Wenige, gelebte Rituale	Trigger definieren, die nie benutzt werden

Fazit

Dieser Leitfaden beschreibt ein bewährtes Muster, kein Dogma. Nimm, was zu deiner Arbeitsweise passt, und lass den Rest weg. Der eigentliche Wert entsteht über Zeit – durch ein Setup, das mit jedem Projekt und jeder Session ein Stück besser wird.

Der Unterschied zwischen „ein KI-Tool benutzen” und „einen mitdenkenden Kollegen haben” liegt genau hier: in den Regeln, die du einmal festlegst, den Ritualen, die du lebst, und dem Gedächtnis, das du wachsen lässt.

Entwicklung, KI

claude-code ai llm anthropic cli automation workflow productivity

Dieser Eintrag ist vom Autor unter CC BY 4.0 lizensiert.