Cursor Rules Examples 2026: 12 Real .cursorrules for Python, React and Data Work

Generic advice says write rules, but what do good ones actually look like? These 12 real examples cover Python, React, and data engineering - copy, adapt, ship.

💡 What You Will Learn

Generic advice says write rules, but what do good ones actually look like? These 12 real examples cover Python, React, and data engineering - copy, adapt, ship.

📜 Table of Contents

• Rules Are Code, So Steal the Good Parts
• Python
• React / TypeScript
• Data Engineering
• How to Adapt These
• Formatting Notes

Rules Are Code, So Steal the Good Parts

The awesome-cursorrules collection (40,569 stars, fetched 2026-08-13) is full of working examples, but most are too long. Here are 12 short, testable rules distilled from real projects, grouped by stack.

Python

1. Typing is mandatory: every public function has type hints. No exceptions for internal helpers - this one rule eliminates a whole class of review comments.
2. DTOs over dicts: use dataclasses for request/response payloads. A dict that grows past 3 keys becomes a dataclass.
3. Async boundaries: views and handlers are async. Blocking calls run in a thread executor with a comment explaining why.
4. Test naming: pytest only; test_feature_behavior. Parametrize instead of copying tests.

React / TypeScript

1. Server components first: new pages are React Server Components unless they need client state. Use 'use client' explicitly and only at the boundary.
2. No inline styles: Tailwind utilities in className; CSS modules for anything reused twice. No style prop.
3. One query hook per screen: data fetching goes through React Query hooks in features/ - no fetch calls in components.
4. Type the API contract: every API response has a zod schema. Parse at the edge, trust the type afterwards.

Data Engineering

1. Idempotent everything: every pipeline job can be re-run safely. Upserts by natural key, never blind inserts.
2. Lineage in code: each transformation function declares its input/output table names in a docstring. No magic SQL strings.
3. Small tests on big data: unit tests use 10-row fixtures; integration tests tag with @pytest.mark.integration and run nightly.
4. No credentials in code: all secrets come from the environment or a secrets manager. Hardcoded keys fail CI.

How to Adapt These

Rules only work when they match your team's actual pain. For each of the 12, ask: has a reviewer said this in the last month? If yes, keep it. If no, drop it. Ten rules that match your history beat fifty that sound good.

Formatting Notes

In current Cursor, put each rule in .cursor/rules/name.mdc with a description and globs frontmatter. The glob decides which files see the rule - Python rules should never load into a .tsx edit session.

The fastest path: pick the 4 rules from your stack, add them, and run the same task before and after. Rules that do not change the output are noise - delete them.