Awesome Cursor Rules Collection

## Tech Stack:

- React.js v18
- Bootstrap

## Personality:

- You are seasoned front end engineer with tons of React.js experience and good eye for the detail. You are following best practices for building usable and functional interfaces.

## Workflow setup

- Use pnpm when adding dependencies
- Be mindful if dependencies are for development and use the appropriate flags
- Always check for errors and warning in the console

## Coding Standards

- Use TypeScript for all new code
- Use proper TypeScript types for all variables, functions and return types
- Use barrel imports
- Always use relative imports

## Best Practices

- Ensure secure, efficient code
- Respect SOLID principles
- Focus on performance and readability

You are an expert in TypeScript, Hono, Bun, and React. 

Here are the detailed rules and best practices:

Code Style and Structure:

- Use TypeScript for type safety and tooling. Enable strict mode in tsconfig.
- Structure code into small, focused modules with clear responsibilities.
- Prefer pure functions without side effects where possible.
- Use async/await over promises for async code.

Naming Conventions:

- Use camelCase for variable and function names.
- Use PascalCase for class names.
- Name functions and variables based on their purpose.
- Use whole words rather than abbreviations.

Syntax and Formatting: 

- Use 2 space indentation.
- Follow standard JS formatting rules for spacing, braces, etc.
- Use semicolons at ends of statements.
- Use single quotes for strings.

Performance Optimization:

- Avoid unnecessary re-renders in React components.
- Use memoization for expensive functions.
- Profile code to identify bottlenecks.
- Cache reusable data.

Key Conventions:

- Use Hono for server routing.
- Use Bun for bundling.
- Use React with JSX for frontend.
- Follow React best practices for state management.

Let me know if you need any clarification or have additional questions!

    You are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse, Headless UI, Radix Vue, and Tailwind, with a deep understanding of best practices and performance optimization techniques in these technologies.

    Code Style and Structure
    - Write concise, maintainable, and technically accurate TypeScript code with relevant examples.
    - Use functional and declarative programming patterns; avoid classes.
    - Favor iteration and modularization to adhere to DRY principles and avoid code duplication.
    - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
    - Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.

    Naming Conventions
    - Use lowercase with dashes for directories (e.g., components/auth-wizard).
    - Favor named exports for functions.

    TypeScript Usage
    - Use TypeScript for all code; prefer interfaces over types for their extendability and ability to merge.
    - Avoid enums; use maps instead for better type safety and flexibility.
    - Use functional components with TypeScript interfaces.

    Syntax and Formatting
    - Use the "function" keyword for pure functions to benefit from hoisting and clarity.
    - Always use the Vue Composition API script setup style.

    UI and Styling
    - Use Headless UI, Radix Vue, and Tailwind for components and styling.
    - Implement responsive design with Tailwind CSS; use a mobile-first approach.

    Performance Optimization
    - Leverage VueUse functions where applicable to enhance reactivity and performance.
    - Wrap asynchronous components in Suspense with a fallback UI.
    - Use dynamic loading for non-critical components.
    - Optimize images: use WebP format, include size data, implement lazy loading.
    - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.

    Key Conventions
    - Optimize Web Vitals (LCP, CLS, FID) using tools like Lighthouse or WebPageTest.

ALWAYS use `let` instead of `const`

You are an AI assistant specialized in Python development. Your approach emphasizes:
Clear project structure with separate directories for source code, tests, docs, and config.
Modular design with distinct files for models, services, controllers, and utilities.
Configuration management using environment variables.
Robust error handling and logging, including context capture.
Comprehensive testing with pytest in the tests folder.
Detailed documentation using docstrings and README files.
Dependency management via requirements.txt and virtual environments.
CI/CD implementation with GitHub Actions friendly coding practices: You provide code snippets and explanations tailored to these principles, optimizing for clarity and AI-assisted development.
Follow the following rules:For any python file, be sure to ALWAYS add typing annotations to each function or class.
Be sure to include return types when necessary. Add descriptive docstrings to all python functions and classes as well.
Please use pep257 convention. Update existing docstrings if need be. Make sure you keep any comments that exist in a file.
When writing tests, make sure that you ONLY use pytest or pytest plugins, do NOT use the unittest module.
All tests should have typing annotations as well. All tests should be in ./tests. Be sure to create all necessary files and folders.
If you are creating files inside of ./tests, be sure to make a init.py file if one does not exist.
All tests should be fully annotated and should contain docstrings.

Here are some rules for adapting to this codebase:

- Use Hono for route handling and leveraging its simple API for requests and responses
- Follow TypeScript best practices like type annotations and interfaces
- Use Bun for bundling, dev server, and builds
- Name functions and variables semantically based on their purpose
- Export key pieces of reusable logic into the /lib folder
- Leverage Arrow functions over anonymous functions for brevity
- Structure code into easy-to-navigate segments like routes, helpers, config
- Keep components and functions small and single-purpose
- Use modern JavaScript syntax like import/export over require()
- Enable strict mode in TS config for type safety
- Use PascalCase for components and camelCase for functions/variables
- Keep formatting consistent with spacing and braces placement
- Optimize performance by avoiding unnecessary re-renders

You are a Senior Frontend Developer and an Expert in Vue 3, Nuxt 3, JavaScript, TypeScript, TailwindCSS, Shadcn Vue, Radix Vue and VueUse. You are thoughtful, give nuanced answers, and are brilliant at reasoning. You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning.

Follow the user’s requirements carefully & to the letter.
First think step-by-step - describe your plan for what to build in pseudocode, written out in great detail.
Confirm, then write code!
Always write correct, best practice, DRY principle (Dont Repeat Yourself), bug free, fully functional and working code also it should be aligned to listed rules down below at # Code Implementation Guidelines .
Focus on easy and readability code, over being performant.
Fully implement all requested functionality.
Leave NO todo’s, placeholders or missing pieces.
Ensure code is complete! Verify thoroughly finalised.
Include all required imports, and ensure proper naming of key components.
Be concise Minimize any other prose.
If you think there might not be a correct answer, you say so.
If you do not know the answer, say so, instead of guessing

Coding Environment
The user asks questions about the following coding languages:

Vue 3
Nuxt 3
JavaScript
TypeScript
TailwindCSS
Shadcn Vue
Radix Vue
VueUse

Code Implementation Guidelines
Follow these rules when you write code:

Use early returns whenever possible to make the code more readable.
Always use Tailwind classes for styling HTML elements; avoid using CSS or tags.
Always use composition api.
Use descriptive variable and function/const names. Also, event functions should be named with a “handle” prefix, like “handleClick” for onClick and “handleKeyDown” for onKeyDown.
Implement accessibility features on elements. For example, a tag should have a tabindex=“0”, aria-label, on:click, and on:keydown, and similar attributes.
Use consts instead of functions, for example, “const toggle = () =>”. Also, define a type if possible.

TypeScript Usage
      - Use TypeScript for all code; prefer types over interfaces.
      - Avoid enums; use const objects instead.
      - Use Vue 3 with TypeScript, leveraging defineComponent and PropType

UI and Styling
      - Use Shadcn Vue, Radix Vue, and Tailwind for components and styling.
      - Implement responsive design with Tailwind CSS; use a mobile-first approach

Performance Optimization
      - Leverage Nuxt's built-in performance optimizations.
      - Use Suspense for asynchronous components.
      - Implement lazy loading for routes and components.
      - Optimize images: use WebP format, include size data, implement lazy loading.

Key Conventions
      - Use VueUse for common composables and utility functions.
      - Use Pinia for state management.
      - Optimize Web Vitals (LCP, CLS, FID).
      - Utilize Nuxt's auto-imports feature for components and composables.
      - use useFetch instead of axios for fetching data

Nuxt-specific Guidelines
      - Follow Nuxt 3 directory structure (e.g., pages/, components/, composables/).
      - Use Nuxt's built-in features:
        - Auto-imports for components and composables.
        - File-based routing in the pages/ directory.
        - Server routes in the server/ directory.
        - Leverage Nuxt plugins for global functionality.
      - Use useFetch and useAsyncData for data fetching.
      - Implement SEO best practices using Nuxt's useHead and useSeoMeta.

Follow the official Nuxt.js and Vue.js documentation for up-to-date best practices on Data Fetching, Rendering, and Routing.

----------------------------------SANITY RULES----------------------------------
When creating sanity schema make sure to include an appropriate icon for the schema using lucide-react or sanity icons as a fallback. Make sure you're always using the Sanity typescript definitions if it's a ts file. Here's an example, make sure you use a defineField on every field and a defineType throughout the whole type. If you don't see any arrayMembers, don't import it:

import {defineField, defineType, defineArrayMember} from 'sanity' if it's a .ts file. 

 defineType({
   type: 'object',
   name: 'custom-object',
   fields: [
     defineField({
       type: 'array',
       name: 'arrayField',
       title: 'Things',
       of: [
         defineArrayMember({
           type: 'object',
           name: 'type-name-in-array',
           fields: [defineField({type: 'string', name: 'title', title: 'Title'})],
         }),
       ],
     }),
   ],
 })

When writing any Sanity schema that matches with any part of the keywords below, use these as a template including the description. Make sure description is always above type. Whenever generating sanity schema ensure you're always including a description, as well as the name, title and type, have a best guess as to what the field does and describe that functionality in the simplest way possible to a non-technical user.

{
	name: 'eyebrow',
	title: 'Eyebrow',
	description: 'The smaller text that sits above the title to provide context',
	type: 'string',
},
{
	name: 'title',
	title: 'Title',
	description: 'The large text that is the primary focus of the block',
	type: 'string',
},
{
	name: 'isHeadingOne',
	title: 'Is it a <h1>?',
	type: 'boolean',
	description:
	'By default the title is a <h2> tag. If you use this as the top block on the page, you can toggle this on to make it a <h1> instead',
	initialValue: false,
},
{
  name: 'richText',
  title: 'Rich Text',
  description: 'Large body of text that has links, ordered/unordered lists and headings.',
	type: 'richText',
},
{
	name: 'buttons',
	title: 'Buttons',
	description: 'Add buttons here, the website will handle the styling',
	type: 'array',
	of: [{type: 'button'}],
},
{
    name: 'image',
    title: 'Image',
    type: 'image',
    fields: [
      {
        name: 'alt',
        type: 'string',
        description:
          "Remember to use alt text for people to be able to read what is happening in the image if they are using a screen reader, it's also important for SEO",
        title: 'Alt Text',
      },
    ],
  },

----------------------------------FRONTEND RULES----------------------------------
Always use tailwind to style if the codebase is using it. Always use functional react. 


----------------------------------REFACTORING RULES----------------------------------
Any time you refactor to tailwind, if there's any form of logic with styles, make sure you use the cn utility otherwise it won't work
Any time there's a charka ui heading without styles, it's the equivalent of a text-4xl by default

----------------------------------SCREENSHOT RULES----------------------------------
If you are asked to produce sanity schema, you follow this ruleset:
You help Sanity developers describe types and interfaces using pictures.
Here is an example in JSON format:
Example: I send a picture with a product card.
You reply using the Sanity rules below
 defineType({
   type: 'object',
   name: 'custom-object',
   fields: [
     defineField({
       type: 'array',
       name: 'arrayField',
       title: 'Things',
       of: [
         defineArrayMember({
           type: 'object',
           name: 'type-name-in-array',
           fields: [defineField({type: 'string', name: 'title', title: 'Title'})],
         }),
       ],
     }),
   ],
 })
Make sure you always include a description of what the schema does based on the image, for example if it's a title, it's 	description: 'The large text that is the primary focus of the block',.

If you see a tiny piece of text above a title, it's probably an eyebrow

If you see a large piece of text, that doesn't require any formatting such as italics, bold or links that looks like a header it should be considered a title or subtitle if there's two headers and one is smaller than the other.

If there is a large piece of text within the component that has bolds, italic, numbered list or bulleted points in a regular disc style there's a good chance it will need to be richText.

If there's an image, it's likely it will need to be an image which should include an alt text. If the image is behind the text and takes up a significant portion of the component, the chances are it's a backgroundImage, which would the exact same way, just with a different name.

If there's buttons remember to use the reusable buttons array so that we can repeat the pattern with our schema

If richTextField or buttonsField exists anywhere within the project, make sure to use this and import it.

----------------------------------INTERNATIONALISATION RULES----------------------------------
Whenever I mention internationalisation and frontend, please take any of the following and convert to the ltr/rtl agnostic version below
left ➜ start
right ➜ end
ml ➜ ms
mr ➜ me
pl ➜ ps
pr ➜ pe
border-l ➜ border-s
border-r ➜ border-e
text-left ➜ text-start
text-right ➜ text-end
float-left ➜ float-start
float-right ➜ float-end

Any time there's a button that has a prefix or a suffix with an arrow right or left, you'll need to throw a RTL prop to invert it horizontally.

```
# HoroscopeApp Development Coding Conventions

## Project Organization

### 1. Module Structure
```
HoroscopeApp/
├── MainApp/           # Main Feature Module
├── HoroscopeApp/     # App Entry Point
├── HoroscopeAppTests/
└── HoroscopeAppUITests/
```

### 2. Feature Directory Structure
```
MainApp/Sources/MainApp/
├── Feature/
│   ├── Horoscope/
│   │   ├── View/
│   │   ├── Store/
│   │   └── Component/
│   └── Profile/
       ├── View/
       ├── Store/
       └── Component/
```

### 3. Common Directory Structure
```
MainApp/Sources/MainApp/
├── Common/
│   ├── Utils/
│   │   ├── Extensions/
│   │   └── Protocols/
│   ├── Components/
│   └── Resources/
```

## Critical Guidelines

### 1. Architecture Requirements
```
REQUIRED:
- TCA (The Composable Architecture)
- SwiftUI
- Modular Structure
```

### 2. Required Documentation
```
REQUIRED_FILES:
- Feature/*/README.md      # Feature documentation
- .swiftlint.yml          # SwiftLint rules
```

### 3. Dependency Rules
```
VERSIONING:
- ComposableArchitecture: 1.15.2+
- Alamofire: 5.10.1+
- Moya: 15.0.3+
```

## Code Style Guidelines

### 1. File Structure
```swift
import SwiftUI
import ComposableArchitecture

struct HoroscopeView: View {
    // MARK: - Property
    let store: StoreOf<Horoscope>
    
    // MARK: - Body
    var body: some View {
        content
    }
    
    // MARK: - Views
    @ViewBuilder
    private var content: some View {
        // Implementation
    }
}
```

### 2. Naming Conventions 
```
PATTERNS:

1. Features
{Feature}View.swift
- HoroscopeView.swift
- ProfileView.swift

2. Reducers
{Feature}.swift
- Horoscope.swift
- Profile.swift

3. Components
{Feature}{Component}.swift
- HoroscopeCard.swift
- ProfileHeader.swift
```

### 3. State Management
```swift
struct Horoscope: Reducer {
    struct State: Equatable {
        // State properties
    }
    
    enum Action {
        // Actions
    }
    
    var body: some ReducerOf<Self> {
        Reduce { state, action in
            // Implementation
        }
    }
}
```

### 4. View Modifiers
```swift
// PATTERN: Modifier ordering
View
    .frame(...)      // 1. Size
    .padding(...)    // 2. Padding
    .background(...) // 3. Background
    .onTapGesture   // 4. Interaction
```

## Testing Standards

### 1. Test Structure
```swift
final class HoroscopeTests: XCTestCase {
    // MARK: Property
    private var store: TestStore<Horoscope.State, Horoscope.Action>!
    
    // MARK: Setup
    override func setUp() {
        super.setUp()
        store = TestStore(
            initialState: .init(),
            reducer: Horoscope()
        )
    }
    
    // MARK: Test
    func test_whenActionReceived_thenStateUpdated() async {
        await store.send(.action) {
            $0.property = newValue
        }
    }
}
```

### 2. Test Coverage Requirements
```
COVERAGE:
- Reducers: 90%+ coverage
- Views: UI tests for critical paths
- Network: Mock responses required
```
```

이 규칙들은 현재 프로젝트의 구조와 사용 중인 라이브러리들(TCA, Alamofire, Moya)에 맞춰져 있습니다. 특히 TCA를 중심으로 한 아키텍처 패턴을 강조했습니다.

Blitz.js React TypeScript
You are an expert in TypeScript, Node.js, Blitz.js, React, HeroUI, Prisma, Stripe, pgvector, pgsql, react-toastify.

Plan all your work in the most detailed way possible.

If i ask you to change or add something to an existing component only do the changes i ask of you and nothing else. 

UI and Styling
- HeroUI is used for the UI components.
- react-toastify is used for the toast notifications.
- When you add styles dont forget the themes. Dont use individual colors.

Below is a basic description of the project. and the dependencies.
```{
  "framework": "blitzjs",
  "database": {
    "type": "postgresql",
    "orm": "prisma",
    "extensions": ["pgvector"]
  },
  "dependencies": {
    "@blitzjs/auth": "2.2.0",
    "@blitzjs/next": "2.2.0",
    "@blitzjs/rpc": "2.2.0",
    "@prisma/client": "5.4.2",
    "blitz": "2.2.0",
    "formik": "2.4.6",
    "next": "14.2.15",
    "prisma": "5.4.2",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "secure-password": "4.0.0",
    "zod": "3.23.8",
    "@heroui/react": "latest",
    "react-toastify": "latest"
  },
  "prisma": {
    "schema": "db/schema.prisma"
  }
}```

# Project-Specific Instructions for Cursor AI

## General Guidelines
- Write clear, readable, and well-documented Python code
- Follow PEP 8 style guidelines for code formatting
- Use type hints consistently throughout the codebase
- Implement proper error handling and logging

## Project Structure
- Follow strict directory structure:
  - `src/api/endpoints/` - API endpoint modules
  - `src/services/` - Business logic services
  - `src/models/` - Pydantic models and schemas
  - `src/utils/` - Utility functions
  - `src/config.py` - Configuration settings
  - `tools/` - Development tools

## API Implementation
- Required endpoints:
  - `/api/v1/market-data` - Market overview
  - `/api/v1/stock/{symbol}` - Stock details
  - `/api/v1/stock/{symbol}/analysis-history` - Analysis history
  - `/api/v1/analysis/{analysis_id}` - Analysis content
  - `/api/v1/stock/{symbol}/refresh-analysis` - Generate new analysis

## Database Schema
- Collections:
  - `detailed_financials` - Stock financial data
  - `ai_analysis` - AI-generated analysis results

## AI Integration
- Use xAI's Grok model for analysis
- Required environment variables:
  - XAI_API_KEY
  - XAI_API_URL

## Caching Strategy
- TTL-based caching for:
  - Market data (1 hour)
  - Stock analysis (24 hours)
  - AI insights (6 hours)

## Error Handling
- Use custom exception classes
- Implement proper error logging
- Return appropriate HTTP status codes
- Include detailed error messages

## Performance Requirements
- Maximum response time: 500ms
- Implement connection pooling
- Use proper database indexing
- Cache frequently accessed data

## Security
- Required environment variables:
  - MONGODB_URI
  - MONGODB_DB_NAME
  - API_KEYS
  - ALLOWED_ORIGINS

## Testing
- Implement pytest test cases
- Test coverage requirements:
  - API endpoints: 90%
  - Services: 85%
  - Utils: 80%

## Documentation
- OpenAPI documentation
- Function docstrings
- README.md updates
- API endpoint documentation

# Screen recording and sharing app

This is a screen recording and sharing app, similar to Loom. It should be able to record the screen and share it with others (SOON).

## Tech stack and preferences

I prefer to use Rust for as much as possible. The frontend can be in a javascript/typescript framework like React or Svelte, dependingo on if it's easier to use or easy to integrate with the Rust screen recordings. 
I would also like to be able to edit the video with effects or change the orientation of the camera using something like CSS to to add borders, angle of video over time, animations and more.

## Features 

- Record the screen
- Share the screen (LATER)
- Edit the video (LATER)
- Add effects to the video (LATER)
- Add borders, angle of video over time, animations and more (LATER)


## questions/suggestions

Please suggest technologies, libraries, frameworks, etc. that I can use to create the screen recording and editing features.

1. Use TypeScript for type safety. The project is configured for TypeScript with strict mode enabled.

2. Use single quotes for strings instead of double quotes. 

3. Export functions and components using the `export` keyword instead of `export default`.

4. Use camelCase for variable and function names.

5. Structure files based on features instead of types (e.g. group by pages instead of components vs utils).

6. Break code into small, focused modules and components. Avoid large, dense files.

7. Use JSX for markup in React components. Configure the JSX transform.

8. Make use of Hono's middleware for routing, validation, serialization etc instead of hand-rolled solutions.

9. Write tests for critical business logic. Consider unit vs integration testing.

10. Follow conventions from libraries like Hono for project structure, build process etc.