Produktionsreife Cursor Rules: Next.js, React TypeScript und FastAPI [Leitfaden 2026]

KI-gestützte Programmierassistenten greifen ohne klare Vorgaben schnell auf veraltete Muster zurück. In modernen Webprojekten schlägt Cursor häufig überholte Methoden des früheren Next.js Pages-Routers vor, versieht React-Komponenten mit unsicheren any-Typen oder platziert blockierende synchrone Datenbankabfragen in asynchronen Python FastAPI-Routen.

Cursor Rules ergänzen Anweisungen, um solche Fehler in Git-Diffs zu reduzieren. Gezielte Dateien in .cursor/rules/ geben dem Modell Architekturrichtlinien vor; sie garantieren weder deren Einhaltung noch die Vermeidung von Bugs oder Halluzinationen.

Hier finden Sie praxiserprobte Regelvorlagen für Next.js, React TypeScript und FastAPI im Jahr 2026 sowie eine Anleitung zum Aufbau modularer Konfigurationsdateien.

Zentrale .cursorrules vs. modulare .cursor/rules/*.mdc Dateien

Direkte Antwort: Cursor unterstützt modulare .cursor/rules/*.mdc-Dateien und weiterhin die ältere .cursorrules-Datei. Bei alwaysApply: false wird eine über globs zugeordnete Regel hinzugefügt, wenn eine passende Datei im Kontext steht; bloßes Öffnen reicht nicht zwangsläufig aus. Das kann unnötige Anweisungen reduzieren, garantiert aber keine Fehlerfreiheit. Siehe die offizielle Dokumentation zu Cursor Rules.

Modellstand vom 22. Oktober 2026: Cursor führt unter anderem Opus 5.5, Sonnet 5.5, Gemini 4 Argon und GPT 5.6 Sol. Die Verfügbarkeit hängt von Tarif, Guthaben und Einstellungen ab; siehe die offizielle Modell- und Preisübersicht. Die folgenden Regeln sind Anweisungen an das Modell und ersetzen keine Codeprüfung.

Zu Beginn nutzte Cursor eine einzige .cursorrules-Datei im Projektstammverzeichnis. Zwar einfach einzurichten, zwingt dieser Ansatz jedoch jeden Prompt dazu, Anweisungen für den gesamten Tech-Stack mitzuführen. Dies verbraucht unnötig Token und führt zu widersprüchlichen Vorgaben zwischen Frontend und Backend.

Aktuelle Versionen von Cursor unterstützen modulare Regeldateien im Format .cursor/rules/*.mdc. Jede .mdc-Datei kombiniert YAML-Frontmatter mit verbindlichen Markdown-Richtlinien:

---
description: Kurze Beschreibung der Regel
globs: pfad/zu/den/zieldateien/**
alwaysApply: false
---

# Ihre technischen Richtlinien hier

Wichtige Frontmatter-Optionen

• globs: Ein Dateimuster (wie src/app/**/*.tsx oder backend/**/*.py). Bei alwaysApply: false wird die Regel hinzugefügt, wenn eine passende Datei im Kontext steht.

• alwaysApply: Nur für projektweite Standards (wie Commit-Formate oder Lizenzvorgaben) auf true setzen. Bei technischen Framework-Regeln bleibt der Wert auf false.

• description: Erklärt den Geltungsbereich der Regel und hilft Cursor bei der Auswahl während semantischer @-Abfragen im Chat.

Wenn Sie Cursor-Regeln im Editor mit autonomen Terminal-Agenten vergleichen möchten, lesen Sie unseren Leitfaden zu Claude Code vs Cursor.

1. Beste Cursor Rules für Next.js (App Router)

Speichern Sie diese Vorlage unter .cursor/rules/nextjs.mdc. Sie beschreibt App-Router-Konventionen, den Schutz vor clientseitigen Datenlecks und das Datenladen in Server-Komponenten. Prüfen Sie deren Umsetzung weiterhin im Review.

---
description: Standards für Next.js App Router und Server Components
globs: src/app/**/*.{ts,tsx},app/**/*.{ts,tsx}
alwaysApply: false
---

# Next.js Architekturregeln

## Grenzen zwischen Server- und Client-Komponenten
- Standardmäßig React Server Components (RSC) einsetzen. Kein "use client" hinzufügen, es sei denn, die Komponente benötigt useState, useEffect, Browser-Events oder Window-APIs.
- Client-Komponenten stets an den Blättern des Render-Baums halten. Daten von Server-Komponenten als serialisierbare Props nach unten übergeben.
- Niemals reine Server-Bibliotheken (Datenbank-Clients, geheime Umgebungsvariablen) in Client-Komponenten importieren.

## Datenabruf und Mutationen
- Daten direkt in Server-Komponenten per async/await abrufen. Auf useEffect zum Laden von Daten verzichten.
- Für Formulare und Datenänderungen Server Actions nutzen. Aktionen nah am Code oder in `actions.ts` mit "use server" am Dateianfang organisieren.
- Alle Eingaben von Server Actions vor Datenbankzugriffen mit Zod-Schemas validieren.
- Routen nach erfolgreichen Änderungen mit `revalidatePath()` oder `revalidateTag()` unverzüglich revalidieren.

## Navigation und Routing
- Für interne Verlinkungen ausschließlich `next/link` verwenden; keine nativen `<a>`-Tags für lokale Pfade nutzen.
- Suchparameter über Seiten-Props oder `useSearchParams()` lesen. Suspense-Grenzen um Komponenten setzen, die Query-Parameter verarbeiten.

2. Beste Cursor Rules für React und TypeScript

Speichern Sie diese Datei als .cursor/rules/react-typescript.mdc. Sie fordert präzise Typdefinitionen, benannte Komponenten-Exporte und einheitliche UI-Strukturen; TypeScript, Linter und Reviews müssen die Ergebnisse prüfen.

---
description: Standards für React und TypeScript
globs: **/*.{ts,tsx}
alwaysApply: false
---

# React und TypeScript Richtlinien

## Strikte Typisierung
- Den Typ `any` niemals verwenden. Für unbekannte Eingaben `unknown` nutzen und mit Type-Guards absichern.
- Für Objektformen und Props `interface` bevorzugen. Für Unions und Mappings `type` verwenden.
- Allen exportierten Funktionssignaturen explizite Rückgabetypen zuweisen.
- Non-Null-Assertions (`!`) vermeiden. Null- und Undefined-Werte mit Optional Chaining (`?.`) oder Fallbacks abfangen.

## Komponentenarchitektur
- Ausschließlich benannte Exporte verwenden: `export function UserProfile(...)`. Kein `export default`.
- Prop-Interfaces direkt über der Komponente im Format `<KomponentenName>Props` anlegen.
- Props in der Funktionssignatur destrukturieren: `function Button({ variant = "primary", children }: ButtonProps)`.
- Komplexe Logik in benutzerdefinierte Hooks mit dem Präfix `use` auslagern.

## Styling und Barrierefreiheit
- Utility-Klassen von Tailwind CSS direkt im Code einsetzen. Keine Inline-Styles `style={{ ... }}` verwenden.
- Bedingte Klassen über Hilfsfunktionen wie `cn()` (clsx + tailwind-merge) bündeln.
- Alle interaktiven Elemente mit zugänglichen Labels (`aria-label`) und Tastaturnavigation versehen.

3. Beste Cursor Rules für Python und FastAPI

Speichern Sie diese Datei als .cursor/rules/fastapi.mdc. Sie fordert asynchrone, nicht blockierende Endpunkte, Pydantic-v2-Schemas und standardisierte Dependency Injection. Tests müssen die Umsetzung validieren.

---
description: Standards für Python FastAPI und Pydantic
globs: **/*.py,backend/**/*.py,api/**/*.py
alwaysApply: false
---

# FastAPI Entwicklungsregeln

## Asynchrone Routen
- Alle Endpunkte mit I/O-Operationen zwingend mit `async def` definieren.
- Niemals blockierende synchrone Aufrufe (wie `requests.get()`, `time.sleep()` oder synchrone Datenbanktreiber) in asynchronen Routen nutzen.
- Für ausgehende HTTP-Anfragen `httpx.AsyncClient` und für Datenbanken asynchrone Treiber einsetzen.

## Pydantic v2 Datenmodelle
- Request-Payloads, Response-Modelle und Datenbank-Schemas in separate Pydantic-Klassen trennen.
- Schemanamen einheitlich benennen: `UserCreateRequest`, `UserUpdatePayload`, `UserResponse`.
- Beim Auslesen von ORM-Objekten stets `from_attributes = True` in `model_config` setzen.
- `Field()` mit konkreten Einschränkungen (`min_length`, `gt`, `le`) und Beispielen verwenden.

## Dependency Injection und Fehlerbehandlung
- Datenbanksitzungen und Authentifizierungskontexte über das `Depends()`-Muster von FastAPI einbinden.
- Datenbankoperationen in asynchronen Context-Managern kapseln, um Sitzungen bei Fehlern zuverlässig zu schließen.
- Fehler mit `HTTPException` und expliziten Statuscodes werfen, statt unstrukturierte Dictionaries zurückzugeben.

Abstimmung von Cursor Rules mit Terminal-Agenten

Wenn Ihr Team zusätzlich Claude Code für Refactorings im Terminal oder automatisierte Tests nutzt, sollten die Projektregeln synchron gehalten werden. Während Cursor .cursor/rules/*.mdc liest, orientiert sich Claude Code an CLAUDE.md und modularen Skill-Paketen.

Wie Sie Test- und Review-Workflows automatisieren, erfahren Sie in unserem Leitfaden zu den besten Claude Code Skills für Entwickler. Besuchen Sie auch unseren Katalog für verifizierte Engineering Skills.

Überprüfung Ihrer Cursor Rules

Nachdem Ihre Dateien in .cursor/rules/ gespeichert sind, können Sie die Funktion unmittelbar überprüfen:

1. Dateimuster testen: Öffnen Sie eine passende Datei (etwa src/app/page.tsx).

2. Cursor Chat öffnen (Cmd+L): Prüfen Sie die Kontextleiste am unteren Chatrand. Dort sollte nextjs.mdc als aktiver Regelsatz aufgeführt sein.

3. Regeln gezielt erzwingen: Tippen Sie @ im Chat, wählen Sie Rules und binden Sie eine Regeldatei manuell ein.

4. Composer testen (Cmd+I): Beauftragen Sie Cursor mit einer neuen Komponente und prüfen Sie das generierte Diff auf die Einhaltung Ihrer Regeln (z. B. benannte Exporte und strikte Typen).

Häufige Fehler bei Cursor Rules

Beachten Sie vier typische Stolpersteine für maximale Effizienz:

1. Überladene Regeln: Fügen Sie nicht das gesamte Firmenhandbuch in eine Datei ein. Halten Sie jede .mdc-Datei unter 80 Zeilen mit klaren Vorgaben.

2. Unpassender Zuordnungsmodus: Nutzen Sie globs für die Dateizuordnung und prüfen Sie alwaysApply; andere Modi erlauben automatische Auswahl oder manuelles Hinzufügen.

3. Widersprüchliche Anweisungen: Vermeiden Sie abweichende Vorgaben zwischen der zentralen .cursorrules und den modularen Dateien.

4. Vage Beschreibungen: Ersetzen Sie subjektive Phrasen wie "Schreibe sauberen Code" durch messbare Anweisungen wie "Funktionen auf maximal 40 Zeilen begrenzen".

Zusammenfassung

Mit modularen .cursor/rules/*.mdc-Dateien verwandeln Sie Cursor von einer einfachen Autovervollständigung in einen spezialisierten Pair-Programmierer, der exakt auf Ihre Produktionsarchitektur abgestimmt ist.