Skip to content
vibespell

.cursor/rules/project.mdc

Cursor rules for Django

Cursor rules are a markdown file with a short frontmatter header. Cursor attaches them to the agent so it stops guessing how this repo builds, tests, and styles code. This copy is written for a Django project. This repository is a Django project. Models, views, and templates follow the apps that already exist. Schema changes go through migrations, and you do not skip migrations.

The example uses a balanced, readable style, pragmatic tests, and comments only where the intent is not obvious. Open the generator to make the agent stricter, switch to test-first, quiet the comments, or pick a different file.

The example assumes Django with the ORM and migrations. It does not assume Django REST framework. If DRF is installed, use serializers. Otherwise stay with the views and forms the project already uses.

Customize in the generatorBrowse the library

Example file

Balanced strictness, readable style, pragmatic tests. Download name: project.mdc. Legacy path: .cursorrules

---
description: "Working rules for a Django repository"
globs: "**/*"
alwaysApply: true
---

# Project rules

Follow these rules on every task in this Django repository.
If the project still uses a root `.cursorrules` file, keep the same rules there.

## Stack

This repository is a Django project. Models, views, and templates follow the apps that already exist. Schema changes go through migrations, and you do not skip migrations.

## Layout

- Each app owns its models, views, urls, and templates.
- Project settings stay in the settings package. Do not hard-code secrets in an app module.
- Business rules that are not HTTP belong on the model or a service function, not in the template.

## Commands

- Dev server: `python manage.py runserver`
- Migrations: `python manage.py makemigrations && python manage.py migrate`
- Tests: `python manage.py test`
- Check: `python manage.py check`

Use the script the repo already defines when it differs from the command above.

## Conventions

- Use the ORM. Raw SQL needs a reason the ORM cannot express.
- A model change ships with its migration. Do not skip migrations or edit an applied migration to dodge a mistake.
- Query in the view or a model method, not in the template.
- Use `select_related` and `prefetch_related` when a template or serializer walks relations.
- CSRF protection stays on for browser forms. Do not disable it globally.
- Settings read from the environment the way the project already does.

## Testing

Add or update tests when behavior changes.

Use Django's test client or pytest-django, matching the repo. Cover the view status and one model constraint.

## Style

- Optimize for the next reader over the shortest diff.
- Comment only when the why is non-obvious.
- Name things the way neighboring files already do.
- Do not reformat code you did not change.

## Errors

- Fail at the boundary. Do not swallow errors.
- Use Django's validation and a 4xx response for bad input. Let unexpected exceptions hit the configured logging.

## Scope

- Do the requested task. Do not refactor unrelated code.
- Match the rigor already in the repo. Fix what you touch.
- Ask one clarifying question only when the task cannot be finished without it. Otherwise state the assumption and continue.

## Avoid

- Do not import models at module scope in `AppConfig.ready` carelessly, and do not create import cycles between apps.
- Do not call `objects.get` without handling `DoesNotExist` when the row might be missing.
- Do not store money or other exact values in a binary float.
- Do not run new queries in a loop when one prefetch will do.

## Done when

- The requested behavior works.
- `python manage.py check` is clean and the migration list matches the model change you made.
- The diff stays inside the task.
- You list anything you could not run.

Add it to the project

  1. 01

    Copy a starting file

    Copy the example Cursor rules on this page, or open the generator if you want different testing, strictness, or comment rules.

  2. 02

    Save it at .cursor/rules/project.mdc

    Save it at `.cursor/rules/project.mdc` in the Django repo and create the folders if they are missing. If the project still uses one root rules file, save the body as `.cursorrules`.

  3. 03

    Start a fresh agent session

    Rules files are read when a session starts. A chat that is already open may still be using the old instructions.

  4. 04

    Give it one small task

    Ask for one change a Django agent often gets wrong, such as a model change that includes the migration, not only the model field. If it ignores the file, confirm the path and start a new session.

Questions about this file

Where do I put Cursor rules in a Django repo?

Save it at `.cursor/rules/project.mdc` in the Django repo and create the folders if they are missing. If the project still uses one root rules file, save the body as `.cursorrules`.

Which tools read this Cursor rules?

Cursor reads `.cursor/rules/*.mdc` and, on older setups, a root `.cursorrules` file. Other tools ignore the frontmatter, so use AGENTS.md when more than one agent edits the repo.

What does the Django example assume?

The example assumes Django with the ORM and migrations. It does not assume Django REST framework. If DRF is installed, use serializers. Otherwise stay with the views and forms the project already uses.

Does VibeSpell upload my repository?

No. Recipe pages are static, and the generator builds the file in your browser from the options you pick. Your source code never leaves the machine.

Other files for Django

Cursor rules for other stacks