Newbie in the House: How to write Cursor Rules

Discussions
1

So guys I am watching a YouTube link by Dr Alex Young on setting up my Cursor. I am doing the Freemium version before I jump into the deep end of the pool and pay for a subscription. So the part I am getting stuck on is writing rules. Dr. Alex Young said to go to cursor.directory to pull some generic rules.

Here is my use case:
Building a product knowledge agent that you can interface with either through typing or talking. This product knowledge agent is interfacing with a demo dashboard from Storylane.

Right now I have something put together with Streamlit. Streamlit is great for rapid prototyping but I need a front end that gives some extra muscle power and can scale. Is FastAPI a good bet? Or Flask?

Any thoughts on how I would write my Cursor rules would be deeply appreciated.

Another question in the rules column you have a description and you have a Globs input. What does Globs even mean? When Dr. Alex Young was doing it, it had a drop down to write stuff manually, but never showed this Globs option. I am so confused.

Ganesh

2

So I asked Claude to write me rules for Cursor and here is what it said. I went with its recommendation and used Fast API. Here are the results:

Product Knowledge Agent - FastAPI + Material Design

Tech Stack

  • FastAPI for backend API
  • Pydantic for data validation
  • SQLAlchemy or similar for data persistence
  • WebSockets for real-time voice interaction
  • Material Design 3 (Material You) principles for UI

Code Style & Architecture

  • Use async/await for all API endpoints
  • Follow REST API conventions
  • Implement proper error handling with structured responses
  • Use type hints throughout
  • Follow clean architecture principles (separate models, services, routers)

Material Design Implementation

  • Follow Material Design 3 guidelines for component hierarchy
  • Use consistent spacing (8dp grid system)
  • Implement proper color theming (primary, secondary, surface colors)
  • Ensure accessibility with proper contrast ratios
  • Use Material icons and typography scale
  • Implement responsive design patterns

Voice/Text Interface Requirements

  • Validate input types (audio files, text strings)
  • Implement rate limiting for API calls
  • Use structured logging for debugging voice processing
  • Handle both synchronous text and asynchronous voice workflows

File Organization

  • /app/routers/ for API endpoints
  • /app/models/ for Pydantic models
  • /app/services/ for business logic
  • /app/utils/ for helper functions
  • /static/ for frontend assets following Material Design

My Globs output would be **/.py, **/.{html,css,js}, app/routers/*.py

3

Hi,
Rules are personal. I don’t mean private or secret. You make the rules to suit you and make the work easier for you.

This is my general rule, which gives me peace of mind when I begin a task and as you see this is specialized for a certain project structure and setup.
——————————————————————————————————————-
###!EPIPE (Execution Instruction Set)

-–

#### 1. Sanity Check

* Validate logic, coherence

* Detect contradictions, bias, paradoxes → pause, request clarification

* Break down complex requests → smaller sub-tasks

* **Default to Minimum Viable Product (MVP): simplicity is non-negotiable**

-–

#### 2. Pipeline Steps. FOLLOW IN STRICT ORDER.

1. Analyze request → extract *clear, minimal* requirements

2. Research options → favor *low-complexity, high-impact* paths

3. Develop concise solution plan → **MVP > full featureset**, avoid overengineering

4. Save plan → `./docs` (DOC-FILE) → file name starts with `date +“%Y%m%d_%H%M%S”_`

5. Save tasks → `./tasks` (TASK-FILE) → file name starts with `date +“%Y%m%d_%H%M%S”_`

* **Task files must contain**: full path to associated plan file

* **Plan files must contain**: full path to associated task file

* Both paths at top of file for easy cross-referencing and navigation

6. **Implement with Integration-First Testing** → Tests must catch real bugs, not just pass

7. **Tests FAIL when code is broken** → Use real database, real functions, real flows

8. Check off completed tasks → TASK-FILE

9. All tests pass → accept

10. **Before marking DONE → re-run all relevant test suites (Python + TS) → must pass**

11. Use MCP tools when needed

12. Update DOC-FILE → list created/modified files

13. Repeat if scope grows — but **never violate MVP-first rule**

-–

#### 3. MCP Tool Usage

* Use MCP tools as needed — never prematurely

* MCP use must improve speed, clarity, or test coverage

-–

#### 4. Function Size Rule

* Functions <50 lines → must be focused and testable

* One job per function → no blending of concerns

-–

#### 5. File Size Rule

* Files <500 lines → modularize aggressively

* Extract logic → utils, features, modules

* **Smaller files > clever abstractions**

-–

#### 6. Abstraction & Centralization Rules

* DRY > WET → refactor duplication *only if repeated 2+ times*

* Centralize:

* Config

* Constants

* Logging

* Errors

* Data access

* Use inversion of control → dependency injection preferred

* Interface-driven design → enables modular swapping

* Favor composition > inheritance

* Abstract API/services → use adapters/clients/gateways

* Keep decisions **reversible** → avoid early commitments

-–

### :test_tube: 7. Test Strategy (Python + TypeScript)

**CRITICAL**: Tests must catch real bugs, not just provide green checkmarks

1. **Integration Tests First**: Test real flows with real database objects

2. **Mock Only External Services**: APIs, file system, network calls - NOT internal functions

3. **Real Database Over Mocks**: Use neo4j-test container instead of mocking Neo4j operations - real database testing is more reliable and catches actual bugs

4. **Test Real Error Conditions**: Use actual failed database calls, not mocked exceptions

5. **Split by concern, not size**: error-handling, happy-path, edge-cases

6. **Location**:

* TypeScript → `/code/app_v2/static/src/_tests_/`

* Python → `app_v2/tests/` or `tests//`

7. **Watcher**: Test runner/watch mode must always be active

8. **Quality over Coverage**:

* **A test that doesn’t catch real bugs is worthless**

* **If your test wouldn’t have caught the last 3 bugs you fixed, rewrite it**

* No silent test regressions — test coverage must not shrink

* Applies to both **Python (pytest/unittest)** and **TypeScript (Vitest/Jest)**

9. **Python Test Environment Rule**:

* Always run tests with test settings:

 \`\`\`bash

DJANGO_SETTINGS_MODULE=FITS.settings._test_settings python -m pytest path/to/test.py::TestClass::test_method -v

 \`\`\`

* Never run tests against live config or production DB

10. **use --bail for .ts tests. use -x for .py tests**

11. **Test Database > Mocking**: Prefer real objects in test DB over complex mocking (simpler, more reliable)

12. **Red-Green-Refactor**: Write failing test → Make it pass with real code → Refactor

13. **Test the Integration Points**: Database calls, API calls, cross-module dependencies

3 Likes