Die komplette .cursorrules-Anleitung: Vom Anfänger zum Profi

.cursorrules ist eine einfache Textdatei, die Sie in Ihr Projektverzeichnis legen und die der KI in Cursor vorgibt, wie sie sich verhalten soll – welchen Coding-Stil sie einhalten soll, welche Frameworks Sie verwenden und welche Muster sie vermeiden soll. Stellen Sie es sich als projektspezifischen System-Prompt vor, der bei jeder KI-Interaktion mit einbezogen wird.

Wenn Sie schon einmal im Cursor Forum unterwegs waren, ist Ihnen dieselbe Frage bestimmt schon wöchentlich aufgefallen: „Wie richte ich .cursorrules richtig ein?“ Die offizielle Dokumentation deckt die Grundlagen ab, aber die Feinheiten erfährt man erst durch den täglichen Einsatz. Diese Anleitung fasst zusammen, was die Community bisher herausgefunden hat.

Drei Arten von Regeln: Welche brauchen Sie?

Das ist die häufigste Verwirrung im Forum. Cursor hat tatsächlich drei verschiedene Regelmechanismen, die jeweils unterschiedliche Zwecke erfüllen. Hier die Übersicht:

Rules for AI (Global)

Zu finden unter Einstellungen > Allgemein > Rules for AI. Das sind globale Regeln, die für jedes Projekt gelten, das Sie in Cursor öffnen. Sie sind in Ihren lokalen Einstellungen gespeichert und nicht in einem Projektverzeichnis.

Geeignet für:

• Persönliche Präferenzen („immer TypeScript Strict Mode verwenden“)
• Universelle Konventionen, die Sie in allen Projekten einhalten
• Verhaltensanpassungen der KI („antworte prägnant, ohne Erklärungen, es sei denn, danach wird gefragt“)

Rules for AI (Global)

Always use functional components with TypeScript.
Prefer named exports over default exports.
When fixing bugs, explain the root cause briefly before showing the fix.

.cursorrules (Projektebene)

Eine Datei namens .cursorrules, die im Stammverzeichnis Ihres Projekts liegt. Das ist der klassische Ansatz – eine einzelne Datei, entweder als reiner Text oder als Markdown, die beschreibt, wie die KI in diesem spezifischen Projekt arbeiten soll.

Geeignet für:

• Projektspezifischen Tech-Stack und Konventionen
• Team-geteilte Regeln (per Git committen)
• Framework-spezifische Muster (Next.js, Django, Rails usw.)

.mdc-Regeln (Modern, eingrenzbar)

Das neuere Format. Sie legen .mdc-Dateien im Verzeichnis .cursor/rules/ ab. Jede Datei kann auf bestimmte Dateimuster eingegrenzt werden, und einzelne Regeln können über die Benutzeroberfläche ein- und ausgeschaltet werden.

Geeignet für:

• Feingranulare Kontrolle darüber, wann Regeln greifen
• Große Projekte, in denen verschiedene Verzeichnisse unterschiedliche Konventionen haben
• Teams, die Regeln selektiv aktivieren oder deaktivieren möchten

Projektstruktur mit .mdc-Regeln

.cursor/
  rules/
    react-components.mdc
    api-endpoints.mdc
    database.mdc
    testing.mdc

Vergleichstabelle

Merkmal	Rules for AI	.cursorrules	.mdc-Regeln
Geltungsbereich	Global (alle Projekte)	Einzelnes Projekt	Einzelnes Projekt
Speicherort	Cursor-Einstellungen	Projektstamm	.cursor/rules/
Dateimuster	N/A	N/A	Pro Regel einstellbar
In UI umschaltbar	Ja	Nein	Ja
Per Git teilbar	Nein	Ja	Ja
Mehrere Dateien	Nein	Nein (eine Datei)	Ja
Status	Stabil	Stabil (Legacy)	Empfohlen

tipp

Sie können alle drei gleichzeitig verwenden. Rules for AI legen Ihre persönliche Basis fest, .cursorrules- oder .mdc-Dateien übernehmen die projektspezifischen Details. Bei Konflikten haben projektspezifische Regeln Vorrang.

Eine effektive .cursorrules-Datei schreiben

Die meisten Tutorials empfehlen, .cursorrules in Markdown zu verfassen. Das funktioniert, aber der Forum-Nutzer razbakov hat überzeugend für strukturiertes JSON plädiert. Die Begründung: Große Sprachmodelle verarbeiten strukturierte Daten zuverlässiger als Fließtext, sodass Ihre Regeln konsequenter befolgt werden.

Hier ist eine echte .cursorrules-Datei für ein Next.js + TypeScript-Projekt im JSON-Format:

.cursorrules

{
  "project": {
    "name": "My SaaS App",
    "stack": ["Next.js 14", "TypeScript", "Tailwind CSS", "Prisma"],
    "packageManager": "pnpm"
  },
  "conventions": {
    "naming": {
      "components": "PascalCase",
      "functions": "camelCase",
      "files": "kebab-case",
      "constants": "SCREAMING_SNAKE_CASE"
    },
    "imports": {
      "order": ["react", "next", "lib/*", "components/*", "relative paths"],
      "noCircularImports": true,
      "alias": "@/ for src/"
    },
    "components": {
      "preferFunctional": true,
      "folderByFeature": true,
      "colocateStyles": true
    }
  },
  "rules": [
    "Always define TypeScript interfaces for component props",
    "Use 'use client' directive only when component needs interactivity or hooks",
    "Prefer server components by default in Next.js app router",
    "No default exports -- use named exports for everything",
    "API routes go in app/api/ following REST conventions",
    "Database queries use Prisma client from lib/db.ts only",
    "Error handling: use try/catch with proper error types, never swallow errors",
    "Environment variables must be validated with zod in env.ts"
  ],
  "antiPatterns": [
    "Never use 'any' type -- use 'unknown' and narrow with type guards",
    "Never put business logic in page.tsx files",
    "Never use inline styles -- use Tailwind classes or CSS modules",
    "Never import from relative paths like '../../' -- use @/ alias"
  ]
}

Warum das besser funktioniert als reiner Text

Wenn Sie Regeln als natürliche Sprache verfassen, muss die KI erst interpretieren, was Sie meinen. Mit strukturiertem JSON hingegen:

• Jede Regel ist eine eigenständige, eindeutige Anweisung
• Die KI muss nicht raten, welche Teile Regeln und welche Kontext sind
• Sie können nach Kategorien sortieren, was die Wartung erleichtert
• Das Hinzufügen oder Entfernen von Regeln zerstört das Format nicht

Hinweis: Wenn Sie Markdown bevorzugen, ist das auch in Ordnung. Die wichtige Erkenntnis ist: Struktur vor Fließtext. Selbst in Markdown sollten Sie Aufzählungspunkte und klare Überschriften verwenden, statt langer Absätze.

Eine Markdown-Alternative

Wenn Ihnen JSON zu starr erscheint, hier eine gut strukturierte Markdown-Version, die das Problem der „Textwand“ vermeidet:

.cursorrules (Markdown-Version)

# Projektregele

## Tech-Stack
- Next.js 14 (App Router)
- TypeScript (Strict Mode)
- Tailwind CSS
- Prisma ORM

## Namensgebung
- Komponenten: PascalCase (UserProfile.tsx)
- Hilfsfunktionen: camelCase (formatDate.ts)
- Konstanten: SCREAMING_SNAKE_CASE (MAX_RETRY_COUNT)
- Dateien: kebab-case (user-profile.tsx)

## Harte Regeln
- Immer Named Exports verwenden
- Jede Komponente braucht TypeScript-Prop-Typen
- Server-Komponenten als Standard, 'use client' nur wenn nötig
- Kein `any`-Typ, niemals
- Alle Umgebungsvariablen mit Zod validieren

## Dateistruktur
- Komponenten in src/components/[feature]/
- Hooks in src/hooks/
- API-Hilfsfunktionen in src/lib/
- Typen in src/types/

Lassen Sie die KI Ihre .cursorrules schreiben

Hier ist ein Trick vom Forum-Nutzer tomredman, der wirklich nützlich ist: Anstatt Regeln von Grund auf zu schreiben, nutzen Sie den Agent-Modus von Cursor, um Ihre Codebasis zu analysieren und sie automatisch zu generieren.

Die Methode

1. Öffnen Sie das Chat-Panel in Cursor
2. Wechseln Sie in den Agent-Modus
3. Geben Sie diesen Prompt ein:

Analyze this codebase and generate a comprehensive .cursorrules file.
Look at:
- Existing files and directory structure
- Package.json dependencies
- Config files (tsconfig, eslint, prettier, etc.)
- Existing code patterns and conventions

Output a .cursorrules file that captures the actual conventions
already used in this project. Use JSON format with clear categories
for tech stack, naming conventions, coding rules, and anti-patterns.

4. Prüfen Sie die Ausgabe sorgfältig – die KI erkennt Muster, von denen Sie nicht einmal wussten, dass Sie sie befolgen
5. Bearbeiten Sie die generierte Datei, um Ungenauigkeiten zu entfernen und Übersehenes hinzuzufügen
6. Speichern Sie sie als .cursorrules im Projektstamm

info

Das funktioniert am besten bei Projekten, die schon eine Weile bestehen und konsistente Muster haben. Für brandneue Projekte schreiben Sie Regeln besser manuell oder starten mit einer Vorlage.

Generierte Regeln iterieren

Erwarten Sie nicht gleich ein perfektes Ergebnis. So sieht mein Workflow aus:

1. Mit dem Agent-Modus generieren
2. Testen, indem Sie Cursor bitten, eine neue Komponente zu schreiben – befolgt sie die Regeln?
3. Notieren Sie, wo die KI abweicht, und fügen Sie explizite Regeln für diese Fälle hinzu
4. Einige Iterationen wiederholen, bis die Ausgabe konsistent korrekt ist

Der gesamte Prozess dauert etwa 15–20 Minuten und spart später stundenlanges „Mach das, nein, nicht so“ hin und her.

Community-Ressourcen

Sie müssen nicht bei Null anfangen. Die Community hat bereits mehrere Regelbibliotheken erstellt, die sich einen Blick lohnen:

cursor.directory

cursor.directory ist eine kuratierte Sammlung von .cursorrules-Dateien, sortiert nach Framework und Sprache. Es ist die beliebteste Ressource im Forum für Starter-Regeln.

cursorrules.agnt.one

cursorrules.agnt.one konzentriert sich auf agent-spezifische Regeln. Wenn Sie stark im Agent-Modus unterwegs sind, lohnt sich ein Blick.

GitHub-Sammlungen

Suchen Sie auf GitHub nach .cursorrules und Sie finden Tausende von Beispielen aus der Praxis:

GitHub-Suchanfrage

filename:.cursorrules stars:>5

Filtern Sie nach Sprache oder Framework, um Regeln von Projekten zu finden, die Ihrem ähnlich sind.

Forum-Thread: Teilt eure .cursorrules

Es gibt einen angepinnten Thread im Cursor Forum mit dem Titel „Share your .cursorrules“, in dem Nutzer ihre Konfigurationen mit Erklärungen posten. Das ist Gold wert, um zu sehen, was in der Produktion funktioniert.

warnung

Kopieren Sie niemals eine .cursorrules-Datei unverändert in Ihr Projekt. Passen Sie sie immer an Ihren tatsächlichen Stack und Ihre Konventionen an. Eine React Native-Regeldatei richtet in einem Django-Projekt mehr Schaden an als Nutzen.

Häufige Fehler

Nach dem Durchlesen Dutzender Forum-Threads sind das die Probleme, die am häufigsten auftauchen:

1. Zu lange Regeln = schlechtere Performance

Es gibt einen hartnäckigen Mythos, dass mehr Regeln = besseres KI-Verhalten bedeuten. Das Gegenteil ist der Fall. Cursor fügt Ihre Regeln dem Kontextfenster neben Ihrem Code und dem Gespräch hinzu. Längere Regeln bedeuten weniger Platz für den eigentlichen Code-Kontext.

Halten Sie es nach Möglichkeit unter 2000 Zeichen. Wenn Sie 5000+ erreichen, müssen Sie rigoros kürzen.

Schlecht: Zu ausführlich

When you are writing React components in this project, you should always make sure
to use functional components instead of class components, and you should define
your prop types using TypeScript interfaces rather than PropTypes, and you should...

Gut: Prägnant und direkt

- Use functional React components only
- TypeScript interfaces for all props
- Named exports, no defaults

2. Widersprüchliche Regeln

Wenn Sie global Rules for AI festgelegt haben UND eine .cursorrules-Datei in Ihrem Projekt, sind Konflikte unvermeidlich. Zum Beispiel:

• Globale Regel: „Verwende 2 Leerzeichen Einrückung“
• Projektregel: „Verwende 4 Leerzeichen Einrückung“

Cursor löst das, indem projektspezifische Regeln Vorrang haben, aber die KI kann sich trotzdem verwirrt fühlen, wenn beide vorhanden sind. Die Lösung: Halten Sie globale Regeln minimal und allgemein, und packen Sie Details in Projektdateien.

3. Regeln, die der KI sagen, was sie sowieso schon weiß

Verschwenden Sie Ihr Regel-Budget nicht für Dinge, die das Modell bereits gut beherrscht:

Unnötige Regeln, die Sie vermeiden sollten

- Write clean, readable code          # Das Modell macht das standardmäßig
- Follow best practices               # Zu vage, um nützlich zu sein
- Use proper error handling          # Bereits Standardverhalten
- Comment your code                  # Oft unnötiger Ballast

Konzentrieren Sie sich stattdessen darauf, was Ihr Projekt vom Standardverhalten des Modells unterscheidet:

Regeln, die tatsächlich Mehrwert bieten

- Use Zod schemas for all API input validation
- All database queries go through the repository pattern
- GraphQL resolvers must have @authenticated directive
- Use pnpm workspaces for monorepo package management

4. .cursorrules nicht committen

Wenn Sie in einem Team arbeiten und die .cursorrules-Datei nicht in der Versionskontrolle ist, profitieren nur Sie davon. Fügen Sie sie zu Git hinzu und machen Sie sie Teil Ihres Onboarding-Prozesses.

.cursorrules zu Git hinzufügen

git add .cursorrules
git commit -m "Add project AI rules for Cursor"

Hinweis: Manche Teams ziehen es vor, .cursorrules nicht in Git zu haben, wenn verschiedene Entwickler unterschiedliche Präferenzen haben. In diesem Fall verwenden Sie .cursorrules.example als Vorlage und fügen .cursorrules zur .gitignore hinzu.

5. Regeln nicht testen

Schreiben Sie Ihre Regeln und testen Sie sie sofort. Bitten Sie Cursor:

• Eine neue Komponente zu generieren
• Eine bestehende Funktion zu refactoren
• Einen Bug zu beheben

Wenn die Ausgabe nicht Ihren Erwartungen entspricht, müssen Ihre Regeln angepasst werden. Warten Sie nicht, bis Sie mitten in einem Feature stecken, um festzustellen, dass Ihre Regeln nicht funktionieren.

Schnellstart-Checkliste

Wenn Sie .cursorrules zum ersten Mal einrichten, hier der minimale Weg:

• Entscheiden zwischen .cursorrules (eine Datei) oder .mdc (mehrere Dateien)
• Den Agent-Modus nutzen, um die Codebasis zu analysieren und einen ersten Entwurf zu generieren
• Auf unter 2000 Zeichen kürzen
• Sich auf projektspezifische Regeln konzentrieren, nicht auf allgemeine Ratschläge
• Testen, indem Cursor eine Komponente oder Funktion generiert
• Iterieren, bis die Ausgabe konsistent ist
• In die Versionskontrolle committen
• Mit dem Team teilen

Verwandte Artikel

• Best Practices für .cursor/rules
• MDC-Regeln Best Practices
• Cursor-Regeln effektiv nutzen
• So ignorieren Sie sensible Dateien in Cursor