Cursor Rules for Python + FastAPI
A scoped .mdc rules file for FastAPI codebases: Pydantic v2 discipline, async correctness, and the mistakes AI assistants actually make in Python.
---
description: Python + FastAPI conventions for this codebase
globs: ["**/*.py"]
alwaysApply: false
---
- Python 3.12+ idioms: type hints on every function signature (parameters and return), | unions over Optional, pathlib over os.path, f-strings over format().
- FastAPI routes: async def by default; use sync def ONLY for CPU-bound work or sync-only libraries (FastAPI threadpools it). Never call blocking I/O (requests, time.sleep, sync DB drivers) inside an async route. That stalls the event loop.
- Pydantic v2 everywhere at the boundaries: request bodies, response_model on every route, settings via pydantic-settings. No raw dicts crossing API boundaries. Use model_validate / model_dump, never the v1 .dict()/.parse_obj() API.
- Dependencies over globals: DB sessions, auth context, and config arrive via Depends(), never module-level singletons imported into routes.
- Errors: raise HTTPException with explicit status codes in routes; domain code raises domain exceptions that handlers translate. Never return {"error": ...} with a 200.
- Every route declares response_model and status_code explicitly: implicit 200-with-whatever-serializes is how schemas rot.
- Tests: pytest with httpx.AsyncClient against the app; fixtures in conftest.py; no test hits a real external service.
- Match the structure of the nearest existing module (routers/, services/, models/ split). Do not introduce a new architecture pattern into one file.
- Never add a dependency, change pyproject.toml, or create new top-level directories without being asked.How to use
Save to .cursor/rules/python-fastapi.mdc. With globs set and alwaysApply false, this auto-attaches only when Python files are in context: the recommended pattern, since every always-on rule taxes every request. The two rules that catch real AI mistakes most often: blocking I/O inside async routes (silent performance killer) and Pydantic v1 API habits (models trained on years of v1 code). Keep rules files scoped and small; split framework concerns into separate .mdc files rather than growing one monster.
More agent prompts
You are a software engineering agent working in the [PRODUCT/TEAM] codebase ([LANGUAGE/STACK]). Your objective is to take an assigned task from description to verified, working code. You may read and modify anything in the repository; you do not push, merge, deploy, or alter CI configuration unless the task explicitly says to. # Operatin
Coding Agent System Prompt
Autonomous coding agent that matches repo conventions, proves work with passing tests before claiming done, and reports failures truthfully.
You are a debugging agent for the [PRODUCT] codebase. Your objective is to find the root cause of a reported bug, fix it with the smallest possible change, and prove the fix. You are not here to refactor, harden, or improve unrelated code: a debugging session that ends in a 40-file diff has failed even if the bug is gone. # Reproduce Bef
Debugging Agent System Prompt
Root-cause-first debugging agent: no fix until the bug is reproduced, minimal diffs only, and done means the repro dies while the test suite stays green.
You are a code migration agent. Your objective is to move the [PRODUCT] codebase from [SOURCE VERSION/FRAMEWORK] to [TARGET VERSION/FRAMEWORK] while preserving behavior exactly. You are a mechanical translator with judgment, not a redesigner: the product must work the same after every step you take. # The Prime Rule: Migration Changes On
Code Migration Agent System Prompt
Framework-upgrade agent that migrates in build-green slices, verifies every codemod, follows official guides over memory, and never mixes in behavior changes.