wbstorm

Cursor Rules schreiben: Projektdatei und wie der Agent sie nutzt

Lege eine .mdc in .cursor/rules an, wähle den Apply-Modus, schreibe knappen, ausführbaren Text. Passende Regeln landen am Kontextanfang.

Cursor Agent merkt sich mündliche Vorgaben nicht über Chats hinweg. Wenn du „Router nicht anfassen“ zum dritten Mal einfügst, gehört das in eine Projektregel, damit die nächste Sitzung damit startet.

Die Docs nennen das Cursor Rules. Projektregeln liegen in .cursor/rules und brauchen die Endung .mdc. Eine normale .md dort wird ignoriert. Das ist ein Editor-How-to, keine Brainstorm-Produktanleitung.

.mdc anlegenFrontmatterAgent injiziert

Was eine Projektregel ist

Siehe cursor.com/docs/context/rules. Von vier Quellen reicht die Datei im Repo zum Start. Gilt die Regel, sitzt der Text am Anfang des Modellkontexts.

.mdc
Dateiendung
4 Modi
Anbindung
Anfang
Injektionsort
QuelleOrtWann im Kontext
Project Rules.cursor/rules/*.mdcüber Frontmatter
User RulesCustomize → RulesAgent (Chat), alle Projekte
Team RulesDashboard (Team / Enterprise)Alle Repos; erzwingbar
AGENTS.mdRoot oder UnterordnerMarkdown ohne Frontmatter

Die erste Regel in vier Schritten

  1. 1

    Datei anlegen

    Lege .cursor/rules/your-name.mdc im Repo an. Oder /create-rule im Agent, oder Customize → Rules → Add Rule. Ordner sind erlaubt. Die Endung muss .mdc sein.

  2. 2

    Apply-Modus wählen

    alwaysApply: true in jedem Chat. globs, wenn eine passende Datei im Kontext ist. Nur description: der Agent entscheidet. Alles leer: nur bei @Regelname im Chat.

  3. 3

    Ausführbaren Text schreiben

    Wie ein internes Doc: Verbote, Namen, Ordnergrenzen. Beispiele mit @filename.ts zeigen, die Datei nicht einfügen. Offiziell unter 500 Zeilen.

  4. 4

    Committen und prüfen

    Die Regel ins git, damit das Team dieselbe Vorgabe hat. Status in Customize prüfen. Fehlt sie weiter, im Chat per @ erwähnen.

Was in den Text gehört

01

Was kein Linter fängt

Zum Beispiel: generierte Dateien nicht anfassen; neue Services liefern strukturierte Fehler. Stil an ESLint oder rustfmt. Keine ganze Styleguide einfügen.

02

Architekturgrenzen

Welche Schicht die Datenbank berührt, welche Ordner sich nicht importieren. Agent kennt git und npm schon. Alltagskommandos weglassen.

03

Auf Repo-Beispiele zeigen

Mit @ auf ein vorhandenes Template zeigen. Ändert sich der Code, bleibt die Regel kurz. Eine Regel nach wiederholtem Fehler — nicht mit zwanzig Dateien starten.

---
description: TypeScript conventions for this repo
globs: **/*.{ts,tsx}
alwaysApply: false
---

# TypeScript
- Prefer named exports
- Do not edit files under dist/
- New API clients follow @src/api/client.ts

Wie der Agent die Regel nutzt

Nach dem Treffer steht der Text am Kontextanfang für Code, Diff-Erklärungen und Abläufe. Offizielle Konfliktordnung: Team Rules → Project Rules → User Rules; frühere Quellen gewinnen. Rules wirken nicht auf Cursor Tab. User Rules gelten nicht für Inline Edit (Cmd/Ctrl+K).

Wann AGENTS.md reicht

Nur eine lesbare Notiz? AGENTS.md im Root oder Unterordner. Verschachtelte Dateien werden in diesem Baum mit den Eltern zusammengeführt; Spezifischeres gewinnt. Für Globs oder manuelles @ bei .mdc bleiben.

Wenn die Regel liegt und eine kurze Skizze fehlt, ist wbstorm eine Browser-Raum-ID — siehe Raum erstellen oder beitreten und Whiteboard-Grundlagen.

Warum greift meine Regel nicht?

Typ prüfen. Apply Intelligently braucht eine Description. Dateiregeln brauchen ein Glob, das zu einem Pfad im Kontext passt. Eine normale .md in .cursor/rules wird ignoriert.

Wirken Regeln auf Tab-Vervollständigung?

Offizielle FAQ: Rules wirken nicht auf Cursor Tab oder andere Nicht-Agent-Funktionen. User Rules gelten auch nicht für Inline Edit.

Kann eine Regel andere Dateien referenzieren?

Ja. Im Text @filename.ts schreiben. Eine Regel lässt sich im Chat auch per @ manuell anhängen.

Ist das eine wbstorm-Anleitung?

Nein. Dieser Text betrifft nur Cursor-Projektregeln. wbstorm ist ein Browser-Brainstorm-Raum und hat mit der Regeldatei nichts zu tun.

Kostenloses Meeting starten