generating-cursor-rules

# Generating Cursor Rules

## Viral Potential: ⭐⭐⭐⭐⭐

Create .cursorrules files that make Cursor IDE understand your project perfectly.

## What This Skill Does

This skill generates comprehensive .cursorrules files that:
- Define project context and architecture
- Set coding standards and conventions
- Specify preferred libraries and patterns
- Configure AI behavior for your workflow
- Prevent common mistakes in your stack

## .cursorrules Structure

### Basic Format

```plaintext
# Project Context
[High-level project description]

# Tech Stack
[Technologies, frameworks, versions]

# Code Style
[Conventions and patterns]

# Architecture
[Project structure and patterns]

# Do's and Don'ts
[Specific rules and anti-patterns]
```

## Complete Templates

### React/Next.js Project

```plaintext
# Project Context
This is a Next.js 14 application using the App Router, TypeScript, and Tailwind CSS.
The project follows a feature-based architecture with shared components.

# Tech Stack
- Next.js 14 (App Router)
- TypeScript (strict mode)
- Tailwind CSS
- shadcn/ui components
- Zustand for state management
- React Query for server state
- Zod for validation

# Code Style
- Use functional components with TypeScript
- Prefer named exports over default exports
- Use 'use client' directive only when necessary
- Keep components small and focused (<150 lines)
- Extract custom hooks for reusable logic

# File Naming
- Components: PascalCase (Button.tsx)
- Utilities: camelCase (formatDate.ts)
- Types: PascalCase with .types.ts suffix
- Hooks: camelCase with use prefix (useAuth.ts)

# Component Structure
1. Imports (external, then internal)
2. Types/interfaces
3. Component definition
4. Export

# State Management
- Use React Query for server state (API data)
- Use Zustand for client state (UI state)
- Avoid prop drilling - use context or Zustand
- Keep state as close to where it's used as possible

# API Patterns
- Use server actions for mutations when possible
- API routes in app/api/ for external integrations
- Always validate input with Zod schemas
- Return typed responses

# Styling
- Use Tailwind CSS utility classes
- Use cn() utility for conditional classes
- Avoid inline styles
- Use CSS variables for theme values

# Do's
- Add proper TypeScript types to all functions
- Use React.memo() for expensive components
- Implement proper error boundaries
- Add loading states for async operations
- Use semantic HTML elements
- Write descriptive variable names

# Don'ts
- Don't use 'any' type
- Don't mutate state directly
- Don't use useEffect for data fetching (use React Query)
- Don't put business logic in components
- Don't use index as key for dynamic lists
- Don't ignore TypeScript errors
```

### Python/FastAPI Project

```plaintext
# Project Context
This is a FastAPI backend service with async SQLAlchemy and PostgreSQL.
It follows clean architecture principles with dependency injection.

# Tech Stack
- Python 3.11+
- FastAPI
- SQLAlchemy 2.0 (async)
- Pydantic v2
- PostgreSQL
- Redis for caching
- pytest for testing

# Code Style
- Follow PEP 8 guidelines
- Use type hints for all functions
- Maximum line length: 88 characters (Black)
- Use f-strings for string formatting
- Prefer pathlib over os.path

# Project Structure
```
src/
├── api/           # Route handlers
├── core/          # Config, security, deps
├── models/        # SQLAlchemy models
├── schemas/       # Pydantic schemas
├── services/      # Business logic
├── repositories/  # Data access layer
└── utils/         # Helper functions
```

# Patterns
- Use dependency injection via FastAPI Depends()
- Separate schemas for Create, Update, Response
- Repository pattern for database operations
- Service layer for business logic
- Always use async/await for I/O operations

# Database
- Use Alembic for migrations
- Always use async session
- Use SQLAlchemy 2.0 style queries
- Implement soft deletes where appropriate

# API Design
- Use proper HTTP methods (GET, POST, PUT, DELETE)
- Return appropriate status codes
- Use Pydantic for request/response validation
- Implement pagination for list endpoints
- Use path parameters for resources, query for filters

# Error Handling
- Create custom exception classes
- Use FastAPI exception handlers
- Return consistent error response format
- Log errors with proper context

# Do's
- Write docstrings for all public functions
- Add type hints everywhere
- Use environment variables for config
- Write unit tests for services
- Use meaningful variable names

# Don'ts
- Don't use raw SQL unless necessary
- Don't put business logic in routes
- Don't ignore type errors
- Don't commit secrets or .env files
- Don't use synchronous operations in async code
```

### Node.js/Express Project

```plaintext
# Project Context
This is an Express.js API with TypeScript, using Prisma ORM
and following a layered architecture.

# Tech Stack
- Node.js 20+
- Express.js
- TypeScript
- Prisma ORM
- PostgreSQL
- Jest for testing
- Zod for validation

# Code Style
- Use ES modules (import/export)
- Prefer async/await over callbacks
- Use const by default, let when needed
- Use arrow functions for callbacks
- Destructure when it improves readability

# Project Structure
```
src/
├── controllers/   # Request handlers
├── services/      # Business logic
├── repositories/  # Data access
├── middleware/    # Express middleware
├── routes/        # Route definitions
├── types/         # TypeScript types
├── utils/         # Helpers
└── config/        # Configuration
```

# Error Handling
- Use custom error classes
- Centralized error middleware
- Always catch async errors
- Return consistent error format

# Validation
- Validate all inputs with Zod
- Create reusable validation schemas
- Validate at controller level
- Return descriptive error messages

# Do's
- Use proper TypeScript types
- Implement request logging
- Use environment variables
- Write integration tests
- Document API with OpenAPI/Swagger

# Don'ts
- Don't use 'any' type
- Don't block the event loop
- Don't store secrets in code
- Don't skip input validation
- Don't ignore promise rejections
```

## Framework-Specific Rules

### For shadcn/ui Projects
```plaintext
# shadcn/ui Components
- Import from @/components/ui
- Use the cn() utility for merging classes
- Extend components, don't modify originals
- Use the component CLI: npx shadcn@latest add [component]

# Form Handling
- Use react-hook-form with zodResolver
- Define schemas in separate files
- Use FormField components for consistency
```

### For Tailwind Projects
```plaintext
# Tailwind CSS
- Use design tokens from tailwind.config
- Prefer utility classes over custom CSS
- Use @apply sparingly, only for truly reusable patterns
- Group related utilities with prettier-plugin-tailwindcss
- Use container queries for responsive components
```

### For Testing
```plaintext
# Testing Rules
- Test files: *.test.ts or *.spec.ts
- Use describe/it blocks for organization
- Mock external dependencies
- Test behavior, not implementation
- Aim for 80%+ coverage on critical paths
```

## Output Format

When generating .cursorrules, provide:
1. **Complete .cursorrules file** content
2. **Usage instructions** for the file
3. **Customization suggestions** based on project
4. **Recommended extensions** for Cursor