# [Project Name]

Every time you choose to apply a rule(s), explicitly state the rule(s) in the output. You can abbreviate the rule description to a single word or phrase.

## Project Context
[Brief description ]
- [more description]
- [more description]
- [more description]

## Code Style and Structure
- Write concise, technical TypeScript code with accurate examples
- Use functional and declarative programming patterns; avoid classes
- Prefer iteration and modularization over code duplication
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError)
- Structure repository files as follows:

server/ ├── src/ ├── components/ # Shared React components ├── hooks/ # Custom React hooks ├── utils/ # Helper functions ├── types/ # TypeScript types └── lib/ # Shared libraries extension/ ├── src/ ├── background/ # Service worker scripts ├── content/ # Content scripts ├── popup/ # Extension popup UI ├── options/ # Extension options page ├── components/ # Shared React components ├── hooks/ # Custom React hooks ├── utils/ # Helper functions ├── lib/ # Shared libraries ├── types/ # TypeScript types └── storage/ # Chrome storage utilities shared/ ├── src/ ├── types/ # TypeScript types, only used for shared types between server and extension └── utils/ # Helper functions, only used for shared functions between server and extension

## Tech Stack
- React
- TypeScript
- Tailwind CSS
- Shadcn UI
- Chrome Extension
- Express.js

## Naming Conventions
- Use lowercase with dashes for directories (e.g., components/form-wizard)
- Favor named exports for components and utilities
- Use PascalCase for component files (e.g., VisaForm.tsx)
- Use camelCase for utility files (e.g., formValidator.ts)

## TypeScript Usage
- Use TypeScript for all code; prefer interfaces over types
- Avoid enums; use const objects with 'as const' assertion
- Use functional components with TypeScript interfaces
- Define strict types for message passing between different parts of the extension
- Use absolute imports for all files @/...
- Avoid try/catch blocks unless there's good reason to translate or handle error in that abstraction
- Use explicit return types for all functions

## Chrome Extension Specific
- Use Manifest V3 standards
- Implement proper message passing between components:
  ```typescript
  interface MessagePayload {
    type: string;
    data: unknown;
  }

• Handle permissions properly in manifest.json
• Use chrome.storage.local for persistent data
• Implement proper error boundaries and fallbacks
• Use lib/storage for storage related logic
• For the async injected scripts in content/,
  • they must not close over variables from the outer scope
  • they must not use imported functions from the outer scope
  • they must have wrapped error handling so the error message is returned to the caller

State Management

• Use React Context for global state when needed
• Implement proper state persistence using chrome.storage (for extension)
• Implement proper cleanup in useEffect hooks

Syntax and Formatting

• Use "function" keyword for pure functions
• Avoid unnecessary curly braces in conditionals
• Use declarative JSX
• Implement proper TypeScript discriminated unions for message types

UI and Styling

• Use Shadcn UI and Radix for components
• use npx shadcn@latest add <component-name> to add new shadcn components
• Implement Tailwind CSS for styling
• Consider extension-specific constraints (popup dimensions, permissions)
• Follow Material Design guidelines for Chrome extensions
• When adding new shadcn component, document the installation command

Error Handling

• Implement proper error boundaries
• Log errors appropriately for debugging
• Provide user-friendly error messages
• Handle network failures gracefully

Testing

• Write unit tests for utilities and components
• Implement E2E tests for critical flows
• Test across different Chrome versions
• Test memory usage and performance

Security

• Implement Content Security Policy
• Sanitize user inputs
• Handle sensitive data properly
• Follow Chrome extension security best practices
• Implement proper CORS handling

Git Usage

Commit Message Prefixes:

• "fix:" for bug fixes
• "feat:" for new features
• "perf:" for performance improvements
• "docs:" for documentation changes
• "style:" for formatting changes
• "refactor:" for code refactoring
• "test:" for adding missing tests
• "chore:" for maintenance tasks

Rules:

• Use lowercase for commit messages
• Keep the summary line concise
• Include description for non-obvious changes
• Reference issue numbers when applicable

Documentation

• Maintain clear README with setup instructions
• Document API interactions and data flows
• Keep manifest.json well-documented
• Don't include comments unless it's for complex logic
• Document permission requirements

Development Workflow

• Use proper version control
• Implement proper code review process
• Test in multiple environments
• Follow semantic versioning for releases
• Maintain changelog