Thanks for getting back to me. Here’s the structure of my .cursor/rules directory :
.cursor
rules
animations.mdc
api.mdc
frontend.mdc
animations-examples.mdc
api-examples.mdc
frontend-examples.mdc
Examples are mentioned with @example.mdc in the rules to avoid big rules files.
Are the naming of my rules / examples OK?
Here’s how I write rules. Is it OK?
---
description: Complete frontend development guidelines for React 18, Next.js 14, TypeScript, Tailwind CSS, and RTK Query - Solar energy application patterns
globs: ["src/**/*.tsx", "src/**/*.ts", "src/**/**/*.tsx", "src/**/**/*.ts", "src/components/**/**/*.tsx", "src/components/ui/*.tsx", "src/app/**/**/*.tsx", "src/app/**/**/**/*.tsx", "src/hooks/*.ts", "src/services/**/*.ts", "src/utils/**/*.ts", "src/lib/**/*.ts", "**/*.d.ts"]
alwaysApply: true
---
# Frontend Development Rules
## React, Hooks, State Management & Next.js → @react-examples.mdc
### React Fundamentals
#### Always Destructure React Imports
**ALWAYS** destructure React imports instead of using `React.` prefix:
- ✅ do `import React, { useState, useEffect, ReactNode, FC } from 'react'`
- ❌ don't `import React from 'react'` then `React.useState()`
#### Component TypeScript Patterns
- **Inline props** for components with ≤ 4 props: `({ title, power, efficiency, isActive }: { title: string; power: number; efficiency: number; isActive: boolean })`
- **Named types** for components with > 4 props: Create `ComponentNameProps` type
- **Always use `type`** instead of `interface`
#### Early Returns Pattern
**ALWAYS** use early returns for loading, error, and edge cases:
- Handle loading states first
- Handle error states second
- Handle missing data third
- Main component logic only when all conditions are met
When I attach a component (.tsx) to a prompt, how can I ensure that the rule is attached to the prompt?
, a Cursor Pro user, and would like to offer a structured response