Cursor Rules – Vollständiger Leitfaden: KI-Code nach Projektstandards (mit Praxis-Konfiguration)

Der Finger schwebt über Enter – zum dritten Mal.

Beim ersten Mal nutzte Cursor var, beim zweiten eine Klassenkomponente, diesmal fehlten alle TypeScript-Typen und überall stand any. Code löschen, selbst tippen wollen.

Dann wurde klar: Die KI ist nicht „zu dumm“ – wir haben ihr unsere Regeln nie mitgeteilt.

Am Anfang dachte ich, gute KI „wüsste von selbst“, was sauberer Code ist. Erst als im Team die Frage kam, warum Cursor-Komponenten so anders aussehen als der Rest, verstand ich: Die KI braucht klare Vorgaben.

Dieser Artikel löst genau das. In 5 Minuten Cursor Rules einrichten – danach passt der generierte Code zu Ihrem Projekt: richtiger Stack, einheitlicher Stil, keine Überraschungen mehr.

Was sind Cursor Rules – und warum brauchen Sie sie?

Das Prinzip: Der KI Regeln geben

Kurz gesagt: Cursor Rules sind Konfigurationsdateien, die der KI Ihre Coding-Standards mitteilen.

Wie ein Entwickler-Handbuch für neue Kolleginnen und Kollegen: Tech-Stack, Namenskonventionen, Ordnerstruktur. Cursor Rules sind dasselbe – ein Onboarding für die KI.

Beim Chat hängt Cursor den Regelinhalt an den Prompt. Die KI sieht dann z. B. „React Hooks, keine Klassenkomponenten“ und generiert entsprechend.

Ohne Rules: meine schmerzhaften Erfahrungen

Beim ersten Cursor-Projekt wirkte alles perfekt – die KI tippte im Turbo. Nach drei Tagen der Schock:

Chaotischer Stil. Mal camelCase, mal PascalCase, mal snake_case – ich verlor selbst den Überblick.

Falscher Stack. Ich wollte Funktionskomponenten, Cursor lieferte class Component extends React.Component. „Hooks verwenden“ half eine Datei – in der nächsten war es wieder vorbei.

Projektstandards ignoriert. Kommentare Pflicht? Cursor lieferte blanken Code. try-catch bei API-Calls? Die KI rief APIs „nackt“ auf.

Zwei Tage Refactoring – Hände wie Gelatine.

Mit Rules: der Unterschied

Fünf Minuten für eine .cursorrules-Datei:

• React 18 + TypeScript
• Nur Funktionskomponenten und Hooks
• Einheitlich camelCase
• Typen Pflicht, any verboten

Ab dann passte jede generierte Komponente. Code-Konsistenz deutlich höher (schätzungsweise 80 %+), Code-Review halbiert. Im Team kam die Frage: „Wie hast du Cursor so diszipliniert?“

Community-Daten: Gute Rules verbessern Konsistenz und senken Refactoring-Kosten. awesome-cursorrules hat 2000+ Stars – ein echtes Entwickler-Thema.

Cursor Rules konfigurieren (Stand 2026)

Alt vs. neu

In Tutorials finden Sie .cursorrules oder .cursor/rules – beides stimmt, nur unterschiedliche Generation.

Alt (vor 2025): Eine .cursorrules im Root, alles in einer Datei.

Neu (2026 empfohlen): Verzeichnis .cursor/rules mit mehreren .mdc-Dateien nach Thema.

Offiziell soll migriert werden: splitten, Geltungsbereiche setzen. Alt funktioniert noch, wird aber abgelöst.

Empfehlung: Neues Projekt → .cursor/rules. Bestehendes → migrieren, wenn Zeit da ist.

Zwei Ebenen: global vs. Projekt

User Rules (global)

Persönliche Präferenzen für alle Projekte.

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

15 % Rabatt sichern →Anzeige

Pfad: File → Preferences → Cursor Settings → Rules → User Rules

Typisch:

• „Überall TypeScript“
• „Kein var, nur const/let“
• „Async immer mit async/await“

Ihre persönlichen Code-Gewohnheiten.

Project Rules

Nur für das aktuelle Projekt.

Anlegen:

1. .cursor im Root
2. darin rules
3. .mdc-Dateien, z. B. frontend.mdc, typescript-rules.mdc

Typisch:

• „Next.js 14 + TypeScript + Tailwind“
• „RESTful APIs“
• „Komponenten in components/, PascalCase“

Priorität: Projektregeln schlagen globale Regeln.

Geltungsbereich: nicht alles auf Always

In .mdc steuern Sie, wann Regeln gelten:

Always: Immer aktiv – für Kernverbote wie „kein var“. Sparsam nutzen, sonst voller Kontext.

Auto Attached: Nach Dateityp – z. B. .tsx → React, .py → Python. Meine Empfehlung für die meisten Regeln.

Agent Requested: KI entscheidet anhand des Gesprächs. Für optionale Hilfen.

Manual: Nur bei explizitem Aufruf – z. B. Performance- oder Test-Sonderregeln.

Praxis: ~80 % Auto Attached, ~10 % Always, Rest nach Bedarf.

Neu Januar 2026: /rules-Befehl

Am 8. Januar 2026 brachte Cursor CLI den Befehl /rules: Regeln im Terminal schnell anlegen und bearbeiten, ohne Ordner zu suchen.

Details: Cursor-Forum – Update 8. Jan. 2026.

Effektive Cursor Rules schreiben

Qualität der Regeln = Gehorsam der KI.

Drei Ebenen des Inhalts

A. Technik und Architektur

Zuerst: Was ist das für ein Projekt?

Projekt-Stack:
- Frontend: React 18 + TypeScript 5.3
- State: Zustand
- Styling: Tailwind CSS 3.4
- Build: Vite 5.0
- Node.js: 18+

Architektur:

Architektur:
- Frontend/Backend getrennt
- RESTful APIs
- Ordner:
  - components/ – wiederverwendbare Komponenten
  - pages/ – Seiten
  - utils/ – Hilfsfunktionen
  - hooks/ – Custom Hooks

Warum so detailliert?

Nur „React“ reichte nicht – mal React-16-, mal React-18-Stil. Mit Versionsnummern war Schluss.

B. Code-Standards

Code-Standards:

Namenskonventionen:
- Komponenten: PascalCase (UserProfile)
- Dateien: kebab-case (user-profile.tsx)
- Variablen/Funktionen: camelCase (getUserData)
- Konstanten: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)

Stil:
- Nur Funktionskomponenten
- const > let, kein var
- Arrow Functions (außer this nötig)
- TypeScript-Typen Pflicht

Dateilänge:
- Datei max. 300 Zeilen
- Funktion max. 50 Zeilen

Kommentare:
- Wichtige Funktionen: JSDoc
- Komplexe Logik: Inline
- „Warum“, nicht „Was“

C. Qualität und Tests

Fehlerbehandlung:
- Async mit try-catch
- API-Fehler: nutzerfreundliche Meldung
- Fehler nicht schlucken – mindestens console.error

Performance:
- Listen mit key
- Große Listen: Virtualisierung
- Bilder mit width/height

Tests:
- Utils: Unit-Tests
- Kernlogik: Abdeckung

Goldene Regeln

1. Konkret, ausführbar, prüfbar

❌ „Guter Code“, „Best Practices“, „Performance beachten“

✅

• „Funktionskomponenten, keine Klassenkomponenten“
• „Props als interface, nicht type“
• „Async mit async/await, kein .then()“

Gute Regeln sind Befehle, keine Wunschliste.

2. Unter 500 Zeilen

Zu lang → schwer verständlich, viel Kontext. Splitten:

• frontend.mdc, backend.mdc, typescript.mdc, testing.mdc

3. Beispielcode statt Floskeln

❌ Nur Text: „Funktionskomponente mit Typen“

✅ Mit Beispiel:

interface UserCardProps {
  name: string;
  email: string;
}

export const UserCard = ({ name, email }: UserCardProps) => {
  return (
    <div className="user-card">
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
};

Beispiele wirken bei Cursor besonders stark.

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

Jetzt starten →Anzeige

4. Wichtiges zuerst

Reihenfolge: Stack/Version → Stil → Struktur → optionale Optimierung.

Typische Fehler

1. Zu breit

„React Best Practices“ – welches Jahr?

Besser: „React Hooks, useState/useEffect, komplexer State mit useReducer“

2. Widersprüche

„TypeScript Pflicht“ und „any erlaubt“ – KI verwirrt, hält evtl. nichts ein.

3. Keine Version

„React“ reicht nicht – 16 vs. 18 ist ein anderer Planet.

Immer: React 18.2+, TypeScript 5.3+, Node.js 18+.

4. Essay statt Anweisung

❌ Drei Absätze, warum TypeScript toll ist …

✅ „TypeScript verwenden, any verboten“

Praxis: Rules für React + TypeScript

Stack:

• React 18, TypeScript 5.x, Tailwind 3.x, Vite 5.x

Team:

• Nur Funktionskomponenten
• Strikte Typen, kein any
• Einheitliche Namen
• Fehlerbehandlung Pflicht

Schritt 1: Dateien anlegen

mkdir -p .cursor/rules
cd .cursor/rules
touch react-typescript.mdc

Schritt 2: Tech-Stack

In react-typescript.mdc:

# React + TypeScript Projektregeln

## Tech-Stack

- React 18.2+
- TypeScript 5.3+
- Tailwind CSS 3.4+
- Vite 5.0+
- Node.js 18+

## Abhängigkeiten

- Paketmanager: pnpm
- Nicht npm oder yarn

Schritt 3: Code-Stil

## Code-Standards

### Komponenten

- Nur Funktionskomponenten
- Komponentenname: PascalCase
- Dateiname: kebab-case
- Named Export, kein Default Export

Beispiel:

// ❌ falsch
export default function userProfile() { }

// ✅ richtig
export const UserProfile = () => { }

### TypeScript

- Typen für alle Komponenten
- Props: interface, nicht type
- any verboten – unknown oder konkrete Typen
- Rückgabetypen explizit

Beispiel:

interface UserCardProps {
  name: string;
  email: string;
  age?: number;
}

export const UserCard = ({ name, email, age }: UserCardProps): JSX.Element => {
  return (
    <div className="p-4 border rounded">
      <h3 className="text-lg font-bold">{name}</h3>
      <p className="text-gray-600">{email}</p>
      {age && <p>Age: {age}</p>}
    </div>
  );
};

### Namenskonventionen

- Variablen/Funktionen: camelCase
- Komponenten: PascalCase
- Konstanten: UPPER_SNAKE_CASE
- Dateien: kebab-case
- CSS: Tailwind-Utilities, kein Custom-CSS

### Async

- async/await, kein .then()
- try-catch Pflicht

Beispiel:

const fetchUserData = async (userId: string): Promise<User> => {
  try {
    const response = await fetch(`/api/users/${userId}`);
    if (!response.ok) throw new Error('Failed to fetch user');
    return await response.json();
  } catch (error) {
    console.error('Error fetching user:', error);
    throw error;
  }
};

Schritt 4: Dateistruktur

## Dateiorganisation

### Verzeichnis

src/
├── components/     # wiederverwendbar
├── pages/          # Seiten
├── hooks/          # Custom Hooks
├── utils/          # Hilfsfunktionen
├── types/          # TypeScript-Typen
├── services/       # API
└── constants/      # Konstanten

### Dateinamen

- Komponente: user-card.tsx
- Utils: format-date.ts
- Typen: user.types.ts
- Hook: use-user-data.ts

### Import-Reihenfolge

1. React
2. Third-Party
3. interne Komponenten
4. Utils
5. Typen
6. Styles

Schritt 5: Qualität

## Qualität

### Fehlerbehandlung

- API: try-catch
- Nutzerfreundliche Fehlermeldungen
- Logging

### Performance

- Listen: key
- Keine neuen Objekte/Funktionen im Render
- React.memo wo sinnvoll
- Bilder: width und height

### Code-Qualität

- Datei max. 300 Zeilen
- Funktion max. 50 Zeilen
- Komplexes: Kommentar
- Wichtige Funktionen: JSDoc

Schritt 6: Fertige Datei

Alles in .cursor/rules/react-typescript.mdc – anpassen für Redux, React Query, Fachregeln.

Effekt testen

Prompt: „User-Card-Komponente mit Name, E-Mail, Avatar“

Ohne Rules oft:

export default function UserCard(props) {
  return <div>...</div>
}

Mit Rules:

interface UserCardProps {
  name: string;
  email: string;
  avatarUrl: string;
}

export const UserCard = ({ name, email, avatarUrl }: UserCardProps): JSX.Element => {
  return (
    <div className="p-4 border rounded shadow">
      <img src={avatarUrl} alt={name} className="w-16 h-16 rounded-full" width="64" height="64" />
      <h3 className="text-lg font-bold mt-2">{name}</h3>
      <p className="text-gray-600">{email}</p>
    </div>
  );
};

Passt: Funktionskomponente, Typen, Named Export, Tailwind, Bildmaße – ein Durchgang.

Fortgeschritten: Tipps und FAQ

Priorität bei Konflikten

Projekt > global

Global „einfache Anführungszeichen“, Projekt „doppelte“ → Projekt gewinnt.

Unterordner > übergeordnet

project/
├── .cursor/rules/general.mdc
└── frontend/
    └── .cursor/rules/react.mdc

In frontend/ hat react.mdc Vorrang.

Explizit im Chat > Auto

Manual-Regel, aber im Dialog klar benannt → wird bevorzugt.

Mehrere Regeldateien

.cursor/rules/
├── core.mdc              # Stack (Always)
├── frontend.mdc          # *.tsx, *.ts
├── backend.mdc           # *.py, *.go
├── testing.mdc           # *.test.*
└── performance.mdc       # Manual

Debug: Regeln greifen nicht

1. Geladen?

In Composer/Chat fragen: „Welche Regeln siehst du?“

Fehlt Ihre Datei → Pfad, Geltungsbereich, Format prüfen.

2. Konflikte

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

Preise ansehen →Anzeige

Widersprüchliche Regeln → KI ignoriert evtl. beide. Konflikt finden, schwächere entfernen oder „überschreibt andere Regeln“ schreiben.

3. KI hört nicht zu

• Regeln schärfen + Beispiele
• Wichtiges nach oben
• Prompt widerspricht Regeln? → „Nach Projektregeln“
• Auto Attached → Always für Kernregeln

Fertige Regeln aus der Community

awesome-cursorrules

2000+ Stars: React, Vue, Angular, Python, Go, Java, Next.js, Astro, Nuxt, TypeScript, Tests, Docker …

awesome-cursorrules-zh

Merge-Beispiele, z. B. React + FastAPI Full-Stack.

cursor.directory

Online-Bibliothek, 30+ Frameworks.

dotcursorrules.com

Weitere Praxisbeispiele.

Tipp: Community starten, dann projektbezogen schärfen – nicht bei null anfangen.

Team: Regeln als Asset

1. Git

git add .cursor/rules
git commit -m "Add Cursor rules for project standards"

Pull → gleiche KI-Standards im Team.

2. README

## Entwicklung mit Cursor

Regeln liegen in `.cursor/rules`.

Die KI hält u. a. ein:
- React 18 + TypeScript
- Funktionskomponenten + Hooks
- Tailwind CSS
- Strikte Typen

Regeländerungen bitte im Team abstimmen.

3. Quartals-Review

Stack und Standards ändern sich. Prüfen: veraltet? neue Practices? Feedback?

Regeln sind lebendes Dokument.

Fazit

Kernbotschaft: Klare Regeln – dann liefert die KI brauchbaren Code.

Vielleicht kennen Sie das:

• Komponente generieren → Stil-Chaos
• TypeScript gewünscht → überall any
• Code wirkt „KI-mäßig“, nicht wie Ihr Team

Das liegt selten an Cursor – an fehlenden Vorgaben.

Jetzt wissen Sie:

1. Regeldateien – neu: .cursor/rules, alt: .cursorrules
2. Stack konkret – Versionen, Tools
3. Standards + Beispiele – Namen, Stil, Fehler
4. Länge – unter 500 Zeilen, splitten
5. Pflege – mit dem Projekt mitwachsen

Jetzt:

• Noch keine Rules? 5 Minuten, erste Datei
• Schon Rules? Vage Stellen mit Beispielen schärfen
• Team? .cursor/rules committen

In einem Monat oft:

• Weniger Code-Review
• Einheitlicher Stil
• Schnelleres Onboarding
• KI als echter Assistent

Ressourcen:

• awesome-cursorrules
• awesome-cursorrules-zh
• cursorrules.org