Cursor Rules Generator — AI Coding Config Builder

Code Style

• Use functional components with TypeScript interfaces
• Prefer named exports over default exports
• Use Tailwind CSS for styling, avoid inline styles

Conventions

• File naming: kebab-case for files, PascalCase for components
• Use server components by default, add "use client" only when needed
• Handle errors with try/catch and return appropriate error responses

Project Structure

• /app - Next.js app router pages
• /components - Reusable UI components
• /lib - Utility functions and API clients
• /types - TypeScript type definitions

## What are Cursor Rules?

Cursor Rules (`.cursorrules` or `.cursor/rules`) are configuration files that tell the Cursor AI coding assistant how to behave in your project. They define coding conventions, tech stack preferences, file structure, and best practices. Well-crafted rules dramatically improve AI code generation quality by giving Cursor project-specific context.

**Answer-Ready**: Cursor Rules are project config files that customize AI code generation in Cursor IDE. Define tech stack, conventions, and patterns. Reduces AI hallucination and improves code consistency. Essential for team standardization. Community-maintained rule collections available.

**Best for**: Developers using Cursor IDE for AI-assisted coding. **Works with**: Cursor IDE, any programming language or framework. **Setup time**: Under 5 minutes.

## Rule Categories

### 1. Tech Stack Rules

You are an expert in Python, FastAPI, SQLAlchemy, and Pydantic.

• Use Pydantic v2 model_validator instead of v1 validator
• Use async def for all route handlers
• Use SQLAlchemy 2.0 style queries with select()

### 2. Architecture Rules

Architecture

• Follow clean architecture: controllers -> services -> repositories
• Never import from controllers in services
• All database access goes through repository layer
• Use dependency injection for services

### 3. Testing Rules

Testing

• Write tests for all new functions
• Use pytest with fixtures, not unittest
• Mock external services, never hit real APIs in tests
• Name test files: test_.py

### 4. Security Rules

Security

• Never hardcode API keys or secrets
• Always validate and sanitize user input
• Use parameterized queries, never string interpolation for SQL
• Set CORS origins explicitly, never use wildcard in production

## Popular Rule Templates

| Stack | Key Rules |
|-------|-----------|
| Next.js + TypeScript | Server components default, app router, Tailwind |
| Python + FastAPI | Async handlers, Pydantic v2, SQLAlchemy 2.0 |
| React Native + Expo | Expo Router, NativeWind, typed navigation |
| Go + Gin | Error handling patterns, middleware conventions |
| Rust + Axum | Ownership patterns, error types, async runtime |

## Best Practices

1. **Be specific**: "Use `date-fns` for dates" beats "use a date library"
2. **Show examples**: Include code snippets for complex patterns
3. **Set boundaries**: Tell Cursor what NOT to do
4. **Keep updated**: Rules should evolve with your codebase
5. **Team alignment**: Share rules via version control

## FAQ

**Q: Where do I put the file?**
A: Project root as `.cursorrules` or in `.cursor/rules` directory for multiple rule files.

**Q: Do rules work with Claude Code too?**
A: Claude Code uses `CLAUDE.md` files instead, but the concept is identical — project-specific AI instructions in a config file.

**Q: How long should rules be?**
A: 200-500 lines is the sweet spot. Too short lacks context, too long dilutes important rules.