Cursor rules for Python
pytest, ruff, virtual environments and migrations.
.cursor/rules/python.mdc
--- description: Conventions and guardrails for the Python codebase globs: **/*.py alwaysApply: false --- # Python project ```bash python -m venv .venv && source .venv/bin/activate # create and enter a virtual environment pip install -e .[dev] # install the project and dev tools pytest # run the tests ruff check . # lint ``` Run the tests after every code change. - Type hints on public functions. Prefer dataclasses or pydantic models over loose dicts. - Raise specific exceptions. No bare except and no silent pass. - Write a failing test first for a bug fix, then fix it. Rules for every edit: - Never read, print, edit or commit .env files, credentials, API keys or private keys. - Database schema changes go through migrations (Alembic, Django migrations or the equivalent), checked into the repo. Never edit a migration that has shipped. - Never deploy to production. I run production deploys myself. - Never run git push --force, git reset --hard, git clean, git checkout -- <file>, git stash or git rebase, and never use --no-verify. Ask first. - Lock files (poetry.lock, uv.lock, requirements.txt pins): do not edit by hand, and do not add or upgrade dependencies without asking.
Why it says what it says
Environment and commands
Without the setup and test commands the agent installs packages globally or runs the wrong runner. Writing them down keeps the environment clean.
Tests first for bugs
A failing test proves the bug exists and proves the fix. It is the cheapest check an agent can run on itself.
Migrations
Schema drift and edited migrations are hard to unwind. The rule keeps changes additive and reviewable.
Deploys are yours
Production changes are rarely something to delegate. One line removes the ambiguity.
Do not touch list
Lock files and shipped migrations are the files where an automatic edit does the most harm for the least visible gain.