Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Configure Cursor project rules using .cursor/rules/*.mdc files and legacy .cursorrules. Triggers on "cursorrules",
".cursorrules", "cursor rules", "cursor config", "cursor project settings", ".mdc rules", "project rules".
allowed-tools
Read, Write, Edit, Bash(cmd:*)
version
1.18.0
license
MIT
author
Jeremy Longshore <jeremy@intentsolutions.io>
tags
["saas","cursor","cursor-rules"]
compatibility
Designed for Claude Code, also compatible with Codex and OpenClaw
Cursor Rules Config
Configure project-specific AI behavior through Cursor's rules system. The modern approach uses .cursor/rules/*.mdc files; the legacy .cursorrules file is still supported but deprecated.
Rules System Architecture
Modern Project Rules (.cursor/rules/*.mdc)
Each .mdc file contains YAML frontmatter followed by markdown content:
---description:"Enforce TypeScript strict mode and functional patterns"globs:"src/**/*.ts,src/**/*.tsx"alwaysApply:false---# TypeScript Standards-Use`const`over`let`,never`var`-Preferpurefunctionsoverclasses-Allfunctionsmusthaveexplicitreturntypes-Usediscriminatedunionsoverenums
Frontmatter fields:
Field
Type
Purpose
description
string
Concise rule purpose (shown in Cursor UI)
globs
string
Gitignore-style patterns for auto-attachment
alwaysApply
boolean
true = always active; false = only when matching files referenced
Rule Types by alwaysApply + globs Combination
alwaysApply
globs
Behavior
true
empty
Always injected into every prompt
false
set
Auto-attached when matching files are in context
false
empty
Manual only -- reference with @Cursor Rules in chat
File Naming Convention
Use kebab-case with .mdc extension. Names should describe the rule's scope:
## Legacy .cursorrules Format
Place a `.cursorrules` file in project root. Plain markdown, no frontmatter:
```markdown
# Project Rules
You are working on a Django REST Framework API.
## Stack
- Python 3.12, Django 5.1, DRF 3.15
- PostgreSQL 16 with pgvector extension
- Redis for caching and Celery broker
- pytest for testing
## Conventions
- ViewSets over function-based views
- Always use serializer validation
- Custom exceptions inherit from `APIException`
- All endpoints require authentication unless explicitly marked
- Use `select_related` and `prefetch_related` to avoid N+1 queries
## Code Style
- Type hints on all function signatures
- Docstrings on all public methods (Google style)
- Max function length: 30 lines
Migration: .cursorrules to .cursor/rules/
Split a monolithic .cursorrules into scoped .mdc files:
Create .cursor/rules/ directory
Extract global context into an alwaysApply: true rule
Extract language/framework rules into glob-scoped rules
Delete .cursorrules after verifying all rules load
Referencing Files in Rules
Use @file syntax to include additional context files when a rule is applied:
---description:"Database schema context for migration files"globs:"prisma/**/*.prisma,drizzle/**/*.ts"alwaysApply:false---Reference these files for schema context:@prisma/schema.prisma@docs/data-model.md
Debugging Rules
Open Chat and type @Cursor Rules to see which rules are active
Check glob patterns match your files: open a file, then verify the rule appears in context pills
Rules with alwaysApply: true always show; glob rules only appear when matching files are in context
Enterprise Considerations
Version control: Commit .cursor/rules/ to git -- rules are project documentation
Team alignment: Use alwaysApply: true for team-wide standards
Sensitive data: Never put API keys, secrets, or credentials in rules files
Rule size: Keep individual rules focused and under 200 lines; split large rules into multiple files
Audit trail: Rules changes appear in git history for compliance review