Sessionübergreifende KI-Regeln: Von .cursorrules bis .claude

Das Problem: Jede Session beginnt bei Null

Wer ohne Regeln arbeitet, verliert jeden Tag Zeit durch Wiederholungen und Inkonsistenzen.

Wer täglich mit KI-Coding-Assistenten arbeitet, kennt das Ritual:

Neue Session starten. Erstmal erklären: “Wir nutzen TypeScript im strict mode, Tailwind v4 für Styling, keine any-Types, Komponenten in PascalCase…”

Drei Stunden später, neue Session: Wieder von vorne.

Das kostet nicht nur Zeit – es sorgt für inkonsistenten Code, nervige Korrekturen und ständige Kontextwechsel. Genau hier setzen Rule-Dateien an.

Und genau deshalb ist man manchmal in der Versuchung, Sessions nicht vorzeitig zu beenden. Man klappt den Laptop einfach zu, öffnet ihn am nächsten Tag wieder, lässt die Session laufen. Denn jeder Session-Wechsel bedeutet: Kontext weg, alles neu aufbauen, Token verbraucht.

Am liebsten wäre es: Laptop zuklappen, wieder aufmachen, in der Session weitermachen. Klappt leider nicht immer. Manchmal bettelt die KI sogar darum, die Session schließen zu dürfen – Context Window voll, Performance im Keller.

Das Dilemma: Eigentlich sollte man für jedes neue Issue, jede neue Aufgabe eine frische Session starten. Klarer Kontext, keine Altlasten. Aber dann fehlen die grundlegenden Informationen über das Projekt. Tech-Stack? Naming Conventions? Architektur-Entscheidungen? Alles weg.

Man wechselt also zwischen zwei schlechten Optionen:

Lange Sessions: Kontext wird zu groß, Performance leidet, KI vergisst frühere Teile
Kurze Sessions: Jedes Mal bei Null anfangen, alles neu erklären

Es gibt eine andere Strategie mit einem weiteren Kostenfaktor: Der KI ein echtes Gedächtnis geben. Wie das mit ByteRover funktioniert, habe ich im vorhergehenden Artikel dieser Serie erklärt.

Eine günstigere Lösung wird in diesem Artikel beschrieben, die auch schon was bewirken kann.

Die KI hat kein Projektgedächtnis.

Sie weiß nicht:

Welchen Tech-Stack du nutzt
Welche Naming Conventions gelten
Welche Patterns du bevorzugst
Was du explizit NICHT willst

Das Ergebnis: Inkonsistenter Code, ständiges Korrigieren, Zeit verschwenden.

Die Lösung: Projektregeln als Code

Moderne KI-Tools haben eine Lösung: Rule-Dateien. Kleine Text-Dokumente, die der KI einmalig erklären, wie dein Projekt funktioniert.

Die KI liest diese Dateien automatisch bei jeder Session und verhält sich entsprechend.

Kein manuelles Wiederholen mehr.

Schauen wir uns die wichtigsten Rule-Systeme an.

.cursorrules – Der Klassiker von Cursor IDE

Cursor war einer der Ersten, die Rule-Files populär machten. Das alte Format: .cursorrules im Projekt-Root.

Beispiel .cursorrules:

# Project: E-Commerce Dashboard

## Tech Stack
- React 18 + TypeScript (strict mode)
- Tailwind CSS v4
- Zustand für State Management
- Zod für Validierung
- Vitest für Tests

## Code Organization
- Components: `/src/components/` (PascalCase)
- Business Logic: `/src/stores/` (camelCase)
- Types: `/src/types/` (mit Type-Suffix, z.B. UserType)
- Utils: `/src/utils/` (pure functions only)

## Naming Conventions
- Files: kebab-case.tsx
- Components: PascalCase
- Hooks: useXxx
- Stores: xxxStore
- Constants: SCREAMING_SNAKE_CASE

## Code Style
- Funktionale Komponenten (keine Class Components)
- Named Exports bevorzugen (keine Default Exports)
- Early Returns statt verschachtelte If-Blöcke
- Destructuring für Props

## Hard Rules (NIE tun)
- NIEMALS `any` Types verwenden
- KEINE Inline-Styles (nur Tailwind)
- KEINE fetch-Calls direkt in Komponenten
- KEINE Mutations in Zustand Stores

## Testing
- Jede Business-Logik braucht Tests
- Components: Rendering + User Interactions
- Utils: Edge Cases abdecken

Was passiert?

Cursor liest diese Datei bei jeder Anfrage und generiert Code, der diesen Regeln folgt.

Update 2025: Cursor migriert zu .cursor/rules/*.mdc (Markdown Components) – strukturierter, versionierbar, teamfähig.

.cursor/
  rules/
    coding-style.mdc
    architecture.mdc
    testing.mdc
    deployment.mdc

Jede Datei kann Frontmatter haben (Metadaten) und ist modular.

.claude – Claude Desktop & Claude Code

Claude hat mit Custom Instructions und .claude-Dateien ein ähnliches System.

Custom Instructions (global, account-weit):

In den Claude-Einstellungen festlegbar
Gelten für alle Chats
Gut für persönliche Präferenzen

Beispiel Custom Instructions:

Ich arbeite als Full-Stack-Entwickler mit TypeScript, React und Node.js.

Wenn ich Code-Fragen stelle:
- Nutze TypeScript (strict mode)
- Bevorzuge funktionale Patterns
- Zeige Error Handling
- Füge kurze Kommentare für komplexe Logik hinzu

Wenn ich Architekturfragen stelle:
- Denke in modularen, skalierbaren Systemen
- Berücksichtige Performance und Sicherheit
- Nenne Alternativen mit Trade-offs

.claude-Dateien (projektspezifisch):

In Claude Code (dem VS Code-ähnlichen Editor von Anthropic) können .claude-Dateien im Projekt liegen.

Beispiel .claude:

version: 1.0
project:
  name: "Task Management App"
  stack:
    - TypeScript
    - React 18
    - Tailwind CSS v4
    - Supabase

rules:
  codeStyle:
    - "Functional components only"
    - "Named exports preferred"
    - "Early returns over nested conditions"

  naming:
    files: "kebab-case.tsx"
    components: "PascalCase"
    hooks: "useXxx"
    types: "XxxType"

  forbidden:
    - "any types"
    - "inline styles"
    - "default exports"
    - "class components"

testing:
  required: true
  framework: "Vitest"
  coverage: ">80%"

Der Unterschied zu Cursor:

YAML-basiert statt Markdown
Strukturierter, maschinell besser parsebar
Kombinierbar mit Custom Instructions

warp.md – Die Meta-Ebene

warp.md ist kein offizielles Tool-Format, sondern ein Konzept aus der Community.

Die Idee: Eine Meta-Datei, die nicht nur Regeln definiert, sondern wie das Projekt gedacht ist.

Beispiel warp.md:

# warp.md – Project Meta-Layer

## Single Source of Truth
- spec.md enthält alle Feature-Specs
- tasks.md ist die aktuelle To-Do-Liste
- .cursorrules definiert Tech-Stack & Code-Style

## Review Gates
Jede Phase braucht Bestätigung:
1. Spec schreiben → Review
2. Implementierung → Tests laufen durch
3. Deployment → Smoke Tests bestanden

## KI-Workflow
- Bei neuen Features: Erst spec.md updaten
- Dann tasks.md aus Spec ableiten
- Dann Implementation
- Tests aus Spec ableiten (BDD-Style)

## Automatisierung
- Tests automatisch aus Specs generieren
- Code-Reviews durch KI-Agent vor PR
- Deployment nur nach erfolgreichen Tests

Was bringt das?

warp.md synchronisiert Intention, Spezifikation, Plan und Tasks. Es ist die Brücke zwischen “was du willst” und “was die KI macht”.

Vergleich: Welches System wofür?

System	Scope	Format	Use Case
`.cursorrules`	Projekt	Markdown	Cursor IDE, Tech-Stack & Code-Style
`.cursor/rules/*.mdc`	Projekt	Markdown Components	Modulare, versionierte Rules
`.claude`	Projekt	YAML	Claude Code, strukturierte Projektregeln
Custom Instructions	Global	Freitext	Persönliche Präferenzen über alle Chats
`warp.md`	Projekt	Markdown	Meta-Layer, Workflow-Steuerung

Welches System nutze ich wann?

Cursor → Stark im Code-Kontext, weniger Meta-Ebene. Gut für Tech-Stack, Naming, Code-Style. Wenn du täglich in Cursor arbeitest, start hier.
Claude (Custom Instructions + .claude) → Stark im strukturierten YAML + Editor-Kontext. Custom Instructions für persönliche Defaults (über alle Projekte), .claude für projektspezifische Rules. Wenn du Claude Code nutzt, ideal.
warp.md → Meta-Intention, Team-Denken, Workflow-Steuerung. Nicht tool-spezifisch, sondern konzeptionell. Gut für komplexe Projekte mit mehreren Beteiligten.
Custom Instructions → Persönliche Defaults, die du in jedem Projekt haben willst (“Nutze TypeScript”, “Erkläre Code in deutscher Sprache”). Nicht projektspezifisch.
ByteRover (siehe Artikel 2) → Echtes Gedächtnis, High-End-Lösung. Wenn Rules nicht reichen und du sessionübergreifendes Langzeitgedächtnis brauchst. Kostenintensiver, aber mächtiger.

Beispiel aus meiner Praxis

Ich nutze inzwischen hauptsächlich Claude Code (mehr zu meinem aktuellen Setup in diesem Artikel). Hier ein Beispiel für eine .claude-Datei, reduziert auf allgemeine technische Anforderungen.

Wichtig: Das ist bewusst ein Basis-Beispiel. In der Praxis wird das noch ergänzt durch:

Projektspezifische Architektur-Regeln (z.B. “API-Calls nur über apiClient.ts”)
Workflow-Vorgaben (Testskripte nach Build, Commit-Message-Format)
Security-Patterns (Secrets-Handling, Input-Validation)
Modulare Aufteilung in mehrere Dateien (wenn .cursor/rules/ genutzt wird)

So vermeidest du die Fehler “zu generisch” und “zu umfangreich”.

version: 1.0
project:
  name: "Web Project"
  stack:
    - TypeScript (strict mode)
    - Astro (Static Sites)
    - Svelte (Interactive Components)
    - Tailwind CSS v4
    - Cloudflare Pages

rules:
  codeOrganization:
    components: "/src/components/"
    layouts: "/src/layouts/"
    content: "/src/content/ (MDX)"
    utils: "/src/utils/ (Pure Functions)"

  naming:
    files: "kebab-case.astro / kebab-case.svelte"
    components: "PascalCase"
    utils: "camelCase"

  codeStyle:
    - "Functional over Class"
    - "Named Exports (no default)"
    - "Early Returns"
    - "Explicit Types (kein any)"

  forbidden:
    - "any types"
    - "inline styles"
    - "console.logs in production"
    - "utils without JSDoc"

testing:
  unit: "Vitest"
  e2e: "Playwright"
  coverage: ">80%"

Ergebnis:

Die KI generiert Code, der sofort passt. Keine Nachkorrekturen mehr wegen falschen Naming Conventions oder vergessener Types.

Was ich dabei gelernt habe

Nach einem Jahr täglicher Nutzung von Rule-Systemen:

1. Je spezifischer, desto besser

Nicht schreiben: “Nutze TypeScript” Sondern: “TypeScript strict mode, keine any, explizite Return-Types bei Functions”

2. Hard Rules explizit machen

Die KI muss wissen, was absolut verboten ist. “NIEMALS any verwenden” wirkt besser als “Vermeide any”.

3. Regeln dokumentieren Architektur

.cursorrules ist auch Dokumentation für neue Team-Mitglieder. Zeigt sofort: “So arbeiten wir hier.”

4. Regelmäßig updaten

Tech-Stack ändert sich. Tailwind v3 → v4. React 17 → 18. Rules müssen mit.

5. Don’ts sind wichtiger als Do’s

Die KI macht vieles richtig. Aber sie macht auch Fehler. “KEINE Inline-Styles” verhindert nervige Korrekturen.

6. Rules wachsen mit meinen Erfahrungen

Wenn man schon im KI-Zeitalter lebt, kann man das natürlich nutzen: Ich behebe mit der KI zusammen einen Fehler. Dabei merke ich: “Das könnte wiederkommen.” Oder ich habe die Erfahrung schon gemacht – bei mehreren Anfragen verfällt die KI immer wieder in dasselbe fehlerhafte Verhalten, landet in derselben Sackgasse.

Die Lösung ist einfach: Ich sage der KI, dass sie diesen Lernpunkt als Regel in die Konfigurationsdatei schreiben soll. “Schreib das als Rule in die .claude-Datei, damit du das nicht nochmal machst.”

Dann schaue ich kurz das Ergebnis an, ob es ausreicht. Meine Erfahrung: Das funktioniert gut. Ich kann damit längerfristig im selben Kontext an einem größeren Projekt arbeiten, ohne ständig denselben Kontext neu aufbauen zu müssen.

Wichtig zu verstehen: Auch im KI-Zeitalter sind die Ressourcen begrenzt – Input-Token, Output-Token, Context Window. Wir müssen momentan immer noch kleinteilig arbeiten. Die komplexe Lösung wird nicht zu 100% von der KI erbracht. Rules helfen dabei, die KI innerhalb der Leitplanken zu halten – ohne jedes Mal alles neu erklären zu müssen.

Typische Fehler beim Erstellen von Rules

Bevor wir zu den Grenzen kommen, hier die klassischen Anfängerfehler – damit du sie vermeiden kannst:

1. Regeln zu generisch

❌ “Schreibe guten Code” ✅ “Funktionale Komponenten (keine Class Components), Named Exports, max. 200 Zeilen pro Datei”

Die KI braucht konkrete, messbare Vorgaben.

2. Regeln widersprechen sich

❌ “Nutze TypeScript strict mode” + “any ist erlaubt für externe APIs” ✅ “TypeScript strict mode, NIEMALS any – nutze unknown für externe APIs und validiere mit Zod”

Widersprüche verwirren die KI. Sei eindeutig.

3. Regeln zu umfangreich (statt modular)

❌ Eine 2.000-Zeilen .cursorrules mit allem ✅ Aufgeteilt in .cursor/rules/coding-style.mdc, architecture.mdc, testing.mdc

Modulare Rules sind wartbar. Monolithen werden ignoriert.

4. Regeln als Erwartung an KI-Intelligenz

❌ “Verstehe die Business-Logik und handle entsprechend” ✅ “Bei User-Aktionen immer Audit-Log schreiben: auditLog.track(userId, action, timestamp)”

Die KI versteht nichts. Sie folgt Mustern. Gib ihr Muster vor.

Grenzen von Rule-Systemen

Rules sind mächtig, aber nicht allmächtig:

1. Token-Limit

Zu lange Rule-Files fressen Context Window. Halte sie unter 1.000 Wörtern.

2. Keine Garantie

Die KI “versteht” Rules nicht. Sie generiert nur wahrscheinlicheren Code. Fehler passieren trotzdem.

3. Kein Ersatz für Wissen

Rules helfen bei Code-Style, nicht bei Architektur-Entscheidungen. Die KI kann nicht wissen, welches Pattern in deinem speziellen Fall besser ist.

4. Wartungsaufwand

Veraltete Rules sind schlimmer als keine Rules. Du musst sie pflegen.

Die Zukunft: KI lernt dein Projekt

Rule-Dateien sind der erste Schritt. Aber die Zukunft sieht anders aus:

Automatische Rule-Generierung: KI analysiert dein Projekt, generiert Rules selbst
Adaptive Rules: Rules passen sich an, je nachdem, in welchem Teil des Projekts du arbeitest
Multi-Layer Context: Kombination aus globalen, Projekt-, Team- und persönlichen Rules

Tools wie ByteRover (siehe Artikel 2) gehen schon in diese Richtung: Statt statischer Rules dynamisches Gedächtnis.

Was gehört noch alles in eine Rule-Datei?

Die bisherigen Beispiele zeigen das Grundgerüst – aber Rule-Dateien können weit mehr enthalten. Hier einige Ideen, was noch Sinn macht:

Workflow & Prozesse:

Git-Workflow (Feature-Branches, Commit-Messages-Format, PR-Template)
Deployment-Prozess (Build-Schritte, Test-Pipeline, Staging-Umgebung)
Review-Richtlinien (Was muss vor einem Merge passieren?)
CI/CD-Integration (Welche Tests müssen durchlaufen?)

Architektur-Entscheidungen:

Design Patterns (welche nutzen, welche vermeiden)
State-Management-Strategie (wann lokaler State, wann global)
API-Design (REST, GraphQL, Conventions)
Error-Handling-Strategie (wie mit Fehlern umgehen)
Performance-Budgets (Bundle-Size-Limits, Ladezeit-Ziele)

Security & Compliance:

Sicherheitsrichtlinien (keine Secrets im Code, Input-Validation)
DSGVO-relevante Punkte (Logging, Analytics, Cookie-Consent)
Accessibility-Standards (WCAG-Level, Screen-Reader-Support)

Team-Konventionen:

Kommunikationskanäle (wo Issues diskutiert werden)
Code-Review-Prozess (wer muss approven)
Branching-Strategie (Git-Flow, Trunk-Based Development)
Release-Prozess (Versionierung, Changelog)

Tooling & Dependencies:

Welche Packages bevorzugt/verboten sind
Welche Tools für welchen Zweck (Prettier, ESLint, Vitest)
Update-Policy (wann Dependencies updaten)
License-Compliance (welche Lizenzen erlaubt sind)

Domänenspezifisches Wissen:

Business-Logik-Besonderheiten
Branchenspezifische Anforderungen
Kundenpräferenzen oder Styleguide-Vorgaben

Die KI wird diese Regeln nicht perfekt befolgen – aber sie werden die Wahrscheinlichkeit drastisch erhöhen, dass der generierte Code in deine Architektur passt.

Der Trick: Nicht alles auf einmal. Start mit Tech-Stack und Naming Conventions. Dann iterativ erweitern, wenn du merkst: “Das hätte die KI wissen müssen.”

Wie man ein Regelset iterativ aufbaut

Die 5-Schritte-Reihenfolge – so baust du dein Regelset auf, ohne dich zu verzetteln:

Schritt 1: Tech-Stack & Naming (Start hier)

Welche Sprache, welches Framework, welche Version?
Naming Conventions: Files, Components, Functions, Variables
Das ist die Basis. Ohne das wird jeder Code inkonsistent.

Schritt 2: Code-Style

Functional vs. OOP?
Destructuring, Early Returns, max. File-Länge?
Export-Strategie (named vs. default)?

Schritt 3: Verbote (Don’ts)

Was soll die KI NIEMALS tun?
any Types, Inline-Styles, direkte fetch-Calls?
Verbote sind wichtiger als Erlaubnisse.

Schritt 4: Architektur-Patterns

Wo liegen Daten, Business-Logik, UI?
State Management, API-Layer, Error-Handling?
Das ist projektspezifisch – keine Copy-Paste-Lösung.

Schritt 5: Workflow & Testing

Git-Workflow, Commit-Messages, PR-Prozess?
Welche Tests, welche Coverage?
Das kommt zuletzt, wenn die Basis steht.

Tipp für Teams: Jeder Schritt kann eine eigene Datei sein (.cursor/rules/01-tech-stack.mdc, 02-code-style.mdc usw.). So bleibt es wartbar.

Checkliste: Gute Rule-Datei

✅ Klarer Tech-Stack (Sprache, Framework, Version)
✅ Explizite Do’s + Hard Don’ts (Was NIEMALS tun)
✅ Naming Conventions (Files, Components, Functions)
✅ Projektstruktur (Wo liegt was?)
✅ Tests + Workflow (Welche Tests, welcher Prozess)
✅ Max. 800–1000 Wörter pro Datei (Sonst Context Window-Problem)
✅ Regelmäßiges Update (Bei Tech-Stack-Änderungen, neuen Learnings)

Integration in Teams

Rules allein zu nutzen ist eine Sache – im Team wird’s komplexer. Hier die wichtigsten Punkte:

Versionierung

Rules gehören ins Git-Repo. Committen wie Code. Bei .cursor/rules/ am besten mit Versionsnummern oder Changelog.

.cursor/rules/
  01-tech-stack-v2.mdc
  02-code-style.mdc
  CHANGELOG.md

Onboarding neuer Teammitglieder

Neues Teammitglied klont Repo → Rules sind da. Aber: Erkläre im README, was die Rules bedeuten.

# Projekt-Setup

## KI-Rules
Wir nutzen `.cursor/rules/` für konsistente KI-Vorschläge.
- `01-tech-stack.mdc`: Welchen Stack wir nutzen
- `02-code-style.mdc`: Wie wir Code schreiben
- Lies sie einmal durch, damit du weißt, was die KI "weiß"

Wer pflegt die Rules?

Klare Verantwortung definieren:

Option 1: Tech Lead pflegt zentral
Option 2: Jeder darf PR für Rule-Änderungen machen (Code-Review-Prozess)
Option 3: Quarterly Review – alle 3 Monate Rules checken

Wie verhindert man, dass Rules veralten?

Bei Tech-Stack-Änderungen: Rules updaten (z.B. React 17 → 18, Tailwind v3 → v4)
Bei wiederkehrenden Fehlern: Neue Rule hinzufügen
Bei Code-Reviews: “Das sollte in den Rules stehen” → PR erstellen

Konflikte vermeiden

Nicht jeder soll wild in Rules rumschreiben. Definiere Prozess:

Issue: “Rule-Vorschlag: Keine Default Exports”
Diskussion im Team
PR mit Rule-Änderung
Code-Review
Merge

Besonderheit bei Claude: Custom Instructions sind persönlich

Claude Custom Instructions sind account-gebunden, nicht projekt-gebunden. Das bedeutet:

Team-Lösung: Nutzt .claude-Dateien im Repo (projektspezifisch, für alle gleich)
Persönliche Präferenzen: Custom Instructions (z.B. “Erkläre auf Deutsch”, “Bevorzuge funktionale Patterns”)
Best Practice: .claude im Repo committen, Custom Instructions für persönliche Defaults nutzen

So hat jeder im Team dieselben Projekt-Rules, aber eigene Präferenzen.

Sicherheit und Datenschutz

Kurzer, aber wichtiger Hinweis:

Was gehört NICHT in Rules?

API-Keys, Secrets, Credentials
Kundennamen, sensible Projekt-Details
Interne Server-URLs, Deployment-Credentials

Was IST OK?

Tech-Stack, Naming Conventions, Code-Style
Architektur-Patterns (generisch)
Allgemeine Workflow-Vorgaben

Faustregel: Wenn es auf GitHub Public stehen könnte, ist es OK für Rules. Alles andere: .env, Secrets-Manager, nicht in Rules.

Ressourcen

Cursor Documentation – Offizielle Cursor Rules Docs
Claude Custom Instructions Guide – Anthropic’s Guide zu Custom Instructions
Spec-Driven Development – Spec Kit für strukturierte Entwicklung

Insights