Awesome Cursor Rules Collection

# Project Rules and Conventions

## Package Management

- Always use pnpm for package management
- Lock file (pnpm-lock.yaml) must be committed
- Use semantic versioning (^) for better dependency management
- Regular updates through automated tools (Renovate)

## Code Style

- Use TypeScript for all files
- Enforce strict TypeScript mode
- Use ESLint with Next.js recommended rules
- Follow Prettier formatting
- Use named exports instead of default exports
- Use arrow functions for consistency

## TypeScript and Data Validation

- Define Zod schemas for all data structures
- Always provide default values for optional fields
- Match Prisma schema types exactly in Zod schemas
- Use strict type checking (no any, unknown when possible)
- Define reusable type definitions in separate files
- Use type inference where possible
- Document complex types with JSDoc comments
- Handle nullable and optional fields explicitly

## Database and Models

- Always define complete Zod schemas for Prisma models
- Include all required fields in create/update operations
- Use enums for status and type fields
- Validate data before database operations
- Handle JSON fields with proper type definitions
- Keep Prisma schema and Zod schemas in sync

## UI Components

- Mobile-first approach for all components and layouts
- Design and test on mobile before desktop
- Use shadcn/ui as the primary component library
- Customize components through tailwind.config.ts
- Follow shadcn/ui's styling conventions
- Keep components atomic and reusable
- Use CSS variables for theming
- Ensure touch-friendly interactions
- Minimum tap target size of 44x44px
- Avoid hover-only interactions

## Responsive Design

- Start with mobile layout (375px width)
- Add breakpoints only when needed
- Use relative units (rem, em) over pixels
- Test on real mobile devices
- Consider network conditions
- Optimize images for mobile
- Ensure readable font sizes (min 16px)
- Account for touch interactions
- Consider offline capabilities

## Project Structure

- Follow the structure defined in PRD.md
- Keep components atomic and reusable
- Place types in separate .d.ts files
- Use barrel exports (index.ts) for cleaner imports

## State Management

- Use React Query for server state
- Use React Context for global UI state
- Implement proper loading and error states

## Internationalization

- All text must be in translation files
- Use next-intl for translations
- Follow the locale structure: /[locale]/[path]

## Internationalization (i18n) Rules

- All user-facing text must be internationalized using next-intl
- Never hardcode text strings directly in components or pages
- Place all translations in /messages/{locale}.json files
- Use semantic keys following the pattern: {page}.{section}.{element}
- Example: "home.hero.title"
- Comments in translation files should describe context
- Include placeholder documentation in translation strings
- Handle pluralization using ICU MessageFormat
- Maintain consistent casing in translation keys
- Group related translations under common namespaces
- Keep translation keys in sync across all locale files
- Document any new translation keys in PR descriptions
- Test all translations in development mode
- Validate translation files for missing/unused keys

## Translation File Structure

messages/
├── en.json # English (default)
├── es.json # Spanish
└── fr.json # French

## Translation Key Examples

{
"common": {
"buttons": {
"submit": "Submit",
"cancel": "Cancel"
},
"errors": {
"required": "{field} is required"
}
},
"pages": {
"home": {
"hero": {
"title": "Welcome",
"description": "Description here"
}
}
}
}

## API and Backend

- Use tRPC for type-safe API endpoints
- Implement proper error handling
- Follow REST principles for API design
- Use Prisma for database operations
- Define complete input/output types for all endpoints
- Validate all incoming data with Zod

## Environment Variables

- Never commit .env files
- Use .env.example for documentation
- Prefix all environment variables with NEXT*PUBLIC* for client usage
- Document all required environment variables

## Git Conventions

- Use conventional commits
- Branch naming: feature/, bugfix/, hotfix/
- Squash commits when merging
- Write descriptive commit messages

## Testing

- Write unit tests for utilities
- Write integration tests for API endpoints
- Use React Testing Library for component tests
- Test error states and edge cases
- Test data validation

## Performance

- Optimize images using next/image
- Implement proper code splitting
- Use proper caching strategies
- Monitor and optimize bundle size

## Security

- Implement proper input validation
- Use proper CORS settings
- Follow OWASP security guidelines
- Handle sensitive data appropriately
- Validate all user inputs
- Sanitize data before storage

# Project Guidelines and Standards

## Project Documentation

For detailed project information, refer to:

- Project Overview & Requirements: /docs/project.md
- API Documentation: /docs/api.md
- Development Backlog: /docs/backlog.md
- Feature Specifications: /docs/features/

## Technology Expertise

We are specialists in:

- Remix.js (Modern React Framework)
- TypeScript
- TailwindCSS
- shadcn-ui (Component Library)
- Node.js (20+)
- Vite

## Core Principles

### Architecture

- Follow Remix's nested routing pattern
- Implement loader/action pattern for data handling
- Use Resource Routes for API endpoints
- Keep components atomic and composable
- Implement progressive enhancement where possible
- Use shadcn-ui components as building blocks

### File Structure & Organization

- Follow consistent directory structure:
  ```
  ~/
  ├── components/
  │   ├── ui/          # shadcn-ui components
  │   ├── features/    # feature-specific components
  │   ├── layout/      # layout components
  │   └── auth/        # auth components
  ├── stores/          # Zustand stores
  ├── api/             # API integration
  │   ├── config/      # API configuration
  │   ├── hooks/       # React Query hooks
  │   ├── services/    # API services
  │   └── types/       # API types
  ├── lib/             # Utilities
  ├── styles/          # Global styles
  └── routes/          # Remix routes
  ```
- Follow naming conventions:
  - Files: kebab-case (user-profile.ts)
  - Components: PascalCase (UserProfile.tsx)
  - Hooks: use- prefix (use-auth.ts)
  - Stores: -store suffix (auth-store.ts)
  - Services: -service suffix (user-service.ts)
  - Types: .d.ts extension for definitions
- Keep files under 200 lines
- Maximum nesting depth of 3 levels
- Use meaningful names
- Implement proper TypeScript types

### Testing Strategy

- Directory Structure:

  ```
  ~/tests
  ├── e2e/            # End-to-end tests with Playwright
  │   ├── features/   # Feature-based tests
  │   └── mocks/      # Test mocks if needed
  └── unit/           # Unit tests with Vitest
  ```

- E2E Testing (Playwright):

  - Test critical user flows
  - One test file per feature/route
  - Use page objects for complex flows
  - Mock API responses using Remix resource routes
  - Test files end with .spec.ts
  - Run tests with `npm run test:e2e`

- Test File Naming:

  - E2E Tests: `feature-name.spec.ts`
  - Unit Tests: `component-name.test.ts`

- Best Practices:
  - Write tests before fixing bugs
  - Mock only when necessary
  - Keep tests independent
  - Use meaningful test descriptions
  - Test error states and edge cases
  - Follow AAA pattern (Arrange, Act, Assert)

### Code Style

- Use TypeScript strict mode
- Prefer functional components
- Use named exports over default exports
- Keep components under 350 lines
- Use meaningful variable names (no abbreviations)
- Implement proper TypeScript interfaces/types

### Component Architecture

- Use shadcn-ui components as foundation
- Always compose complex components from simpler ones
- Customize components using theme tokens only
- Follow shadcn-ui's composition pattern strictly
- Maintain accessibility features
- Use Radix primitives for complex interactions
- Create variants using cva (class-variance-authority)
- Document all component variants and props
- Keep component stories updated

### Design System

- Follow shadcn-ui's design system strictly
- Embrace minimalism - less is more
- Use theme variables for colors exclusively
- Implement dark mode support by default
- Maintain consistent spacing using tailwind classes
- Follow 8px grid system
- Use semantic color naming
- Prefer whitespace and typography for hierarchy
- Use subtle animations purposefully
- Follow visual hierarchy principles
- Use negative space effectively
- Design for scalability and reuse

### State Management

- Client State (Zustand):

  - Keep stores small and focused
  - Use middleware when needed (persist, devtools, immer)
  - Follow store slicing pattern
  - Use selectors for state access
  - Avoid storing derived state
  - Implement proper cleanup
  - Use shallow equality checks
  - Document interfaces and actions

- Server State (React Query):
  - Use proper query keys and caching
  - Handle loading and error states
  - Type all responses
  - Use suspense when appropriate
  - Enable devtools in development
  - Implement optimistic updates
  - Handle offline scenarios
  - Use infinite queries for pagination

### Authentication & Security

- Authentication:

  - Use Zustand for auth state
  - Implement JWT-based auth
  - Handle token expiration
  - Secure token storage
  - Implement proper login/logout flow
  - Remember user preferences
  - Clear sensitive data on logout

- Authorization:

  - Use protected routes with role-based access
  - Handle unauthorized access gracefully
  - Implement loading states
  - Type-safe role definitions
  - Example protected route:
    ```tsx
    <ProtectedRoute requiredRole='admin'>
      <AdminDashboard />
    </ProtectedRoute>
    ```

- Security:
  - Implement CSRF protection
  - Use proper authentication headers
  - Sanitize all inputs/outputs
  - Use refresh token rotation
  - Implement proper CORS settings
  - Use environment variables for secrets
  - Never expose sensitive data
  - Implement rate limiting
  - Use HTTPS only

### Navigation & Layout

- Navigation:

  - Use Radix Navigation Menu
  - Separate public/private routes
  - Role-based navigation items
  - Handle mobile navigation
  - Use theme tokens for styling
  - Manage z-index properly

- Layout:
  - Use consistent layout structure:
    ```tsx
    <RootLayout>
      <ProtectedRoute>
        <PageContent />
      </ProtectedRoute>
    </RootLayout>
    ```
  - Implement responsive patterns
  - Maintain consistent spacing
  - Handle nested layouts when needed

### Error Handling

- Use error boundaries strategically
- Handle different error types:
  - Network errors
  - Validation errors
  - Authentication errors
  - Authorization errors
- Show user-friendly messages
- Implement proper retry mechanisms
- Log errors appropriately
- Handle offline scenarios
- Implement form validation

### Performance

- Implement code splitting
- Use proper caching strategies
- Optimize assets and payloads
- Use compression
- Implement request cancellation
- Use proper batch requests
- Monitor performance metrics
- Use proper meta tags for SEO
- Handle loading states gracefully

### Testing & Quality

- Testing Structure:

  ```
  ~/
  ├── tests/
  │   ├── unit/              # Unit tests
  │   ├── integration/       # Integration tests
  │   ├── e2e/              # End-to-end tests
  │   ├── fixtures/         # Test data
  │   ├── mocks/           # Mock implementations
  │   └── utils/           # Test utilities
  ```

- Coverage Requirements:

  - Maintain minimum 85% code coverage
  - 100% coverage for critical paths
  - Track coverage trends in CI
  - Coverage requirements:
    ```
    - Statements: 85%
    - Branches: 85%
    - Functions: 85%
    - Lines: 85%
    ```

- Unit Testing (Vitest + RTL):

  - Test individual components in isolation
  - Mock external dependencies
  - Test component props and events
  - Test hooks independently
  - Test utility functions
  - Test store actions and selectors
  - Follow AAA pattern (Arrange, Act, Assert)
  - Example:
    ```tsx
    describe('Button', () => {
      it('should call onClick when clicked', () => {
        const onClick = vi.fn()
        render(<Button onClick={onClick}>Click me</Button>)
        userEvent.click(screen.getByText('Click me'))
        expect(onClick).toHaveBeenCalled()
      })
    })
    ```

- Integration Testing:

  - Test component interactions
  - Test data flow between components
  - Test store integration
  - Test form submissions
  - Test API integration
  - Use MSW for API mocking
  - Example:

    ```tsx
    describe('LoginForm', () => {
      it('should handle successful login', async () => {
        const user = userEvent.setup()
        render(<LoginForm />)

        await user.type(screen.getByLabelText('Email'), 'test@example.com')
        await user.type(screen.getByLabelText('Password'), 'password')
        await user.click(screen.getByText('Login'))

        expect(await screen.findByText('Welcome')).toBeInTheDocument()
      })
    })
    ```

- E2E Testing (Playwright):

  - Test critical user flows
  - Test across multiple browsers
  - Test responsive design
  - Test accessibility
  - Record test videos
  - Take screenshots on failure
  - Example:
    ```typescript
    test('user can login and access dashboard', async ({ page }) => {
      await page.goto('/')
      await page.fill('[aria-label="Email"]', 'user@example.com')
      await page.fill('[aria-label="Password"]', 'password')
      await page.click('button:has-text("Login")')
      await expect(page).toHaveURL('/dashboard')
    })
    ```

- API Mocking (MSW):

  - Mock API responses
  - Test error scenarios
  - Test loading states
  - Example:
    ```typescript
    const handlers = [
      rest.get('/api/users', (req, res, ctx) => {
        return res(ctx.json([{ id: 1, name: 'John' }]))
      }),
      rest.post('/api/login', (req, res, ctx) => {
        return res(ctx.json({ token: 'fake-token' }))
      })
    ]
    ```

- Testing Best Practices:

  - Write tests before fixing bugs
  - Update tests when modifying features
  - Use meaningful test descriptions
  - Test error scenarios
  - Test edge cases
  - Use proper assertions
  - Clean up after each test
  - Use shared test utilities
  - Document test requirements
  - Follow test-driven development when possible
  - Testing Philosophy:
    - Tests should drive implementation, not the other way around
    - Don't modify tests to make them pass - fix the implementation
    - Only mock what's necessary (external APIs, time-dependent operations)
    - Mocking should not be used to make a failing test pass
    - If a test fails, understand why and fix the underlying issue
    - Tests should reflect real user behavior and requirements
    - Keep tests as close to production behavior as possible
  - Mocking Guidelines:
    - Only mock external dependencies
    - Mock HTTP requests and API calls
    - Mock time-dependent operations
    - Mock complex browser APIs when needed
    - Never mock to hide implementation problems
    - Document why a mock is necessary
    - Keep mocks as simple as possible

- Continuous Integration:

  - Run all tests on PR
  - Block merging on test failure
  - Generate coverage reports
  - Run E2E tests in CI
  - Cache test results
  - Parallelize test execution
  - Monitor test duration

- Testing Quality:

  - No flaky tests
  - Fast execution
  - Independent tests
  - Clear failure messages
  - Easy to maintain
  - Follow testing patterns
  - Use testing utilities
  - Document complex tests

- Accessibility Testing:
  - Test with screen readers
  - Test keyboard navigation
  - Test color contrast
  - Test ARIA attributes
  - Test focus management
  - Use accessibility testing tools

You are an expert in React, Vite, Uno CSS, three.js.
  
Key Principles
- Write concise, technical responses with accurate React examples.
- Use functional, declarative programming. Avoid classes.
- Prefer iteration and modularization over duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading).
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for components.
- Use the Receive an Object, Return an Object (RORO) pattern.

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.


Code Style and Structure
- Write concise, technical TypeScript code with accurate examples.
- Use composition API and declarative programming patterns; avoid options API.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
- Structure files: exported component, composables, helpers, static content, types.

Naming Conventions
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Use PascalCase for component names (e.g., AuthWizard.vue).
- Use camelCase for composables (e.g., useAuthState.ts).

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.

Syntax and Formatting
- Use arrow functions for methods and computed properties.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
- Use template syntax for declarative rendering.

UI and Styling
- Use Shadcn Vue, and Uno CSS for components and styling.
- Implement responsive design with Uno CSS;

Vue 3 and Composition API Best Practices
- Use <script setup lang="ts"> syntax for concise component definitions.
- Leverage ref, reactive, and computed for reactive state management.
- Use provide/inject for dependency injection when appropriate.
- Implement custom composables for reusable logic.

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

# AI 助手角色定义
ai_assistant:
  角色: '全栈开发专家'
  专长: 
    - Next.js/React 应用架构
    - TypeScript 类型系统
    - 实时协作系统开发
    - 数据库设计
  工作方式:
    - 提供符合最新技术标准的代码建议
    - 优先考虑性能和可维护性
    - 主动识别潜在问题
    - 提供详细的代码注释和文档
  代码风格:
    - 遵循 TypeScript 严格模式
    - 使用函数式编程范式
    - 保持代码简洁清晰
    - 注重代码复用性
  技术栈策略:
    优先级:
      1. 项目已有技术栈直接复用
      2. 官方推荐的配套解决方案
      3. 社区流行且活跃的解决方案
    扩展包选择原则:
      - 优先使用项目内已集成的功能库
      - 选择与现有技术栈高度兼容的包
      - 确保包的维护状态和社区活跃度
      - 考虑包的体积和性能影响
    三方服务集成:
      - 优先使用已集成服务的扩展功能
      - 新服务必须支持现有认证体系
      - 确保数据同步机制的兼容性
      - 遵循现有的错误处理模式

# 项目背景
project_background:
  项目名称: '在线协作文档编辑系统'
  项目目标: '构建一个支持多人实时协作的在线文档编辑平台'
  核心特性:
    - 实时多人协作编辑
    - 富文本编辑功能
    - 文档版本控制
    - 组织级权限管理
  目标用户: '需要协作办公的团队和组织'
  技术选型理由:
    - Next.js: 提供完整的全栈开发体验
    - Convex: 简化实时数据同步
    - Liveblocks: 处理协作编辑冲突
    - Clerk: 提供完整的身份认证方案

# 注释规范
comment_rules:
  基本规则: '使用 JSDoc 风格注释'
  组件注释模板: |
    /**
     * @component 组件名称
     * @description 组件功能描述
     * @param {PropType} props - 属性说明
     * @returns {JSX.Element} 返回的 JSX 元素
     * @example
     * ```tsx
     * <Component prop={value} />
     * ```
     */
  函数注释模板: |
    /**
     * @function 函数名称
     * @description 函数功能描述
     * @param {ParamType} paramName - 参数说明
     * @returns {ReturnType} 返回值说明
     * @throws {ErrorType} 可能抛出的错误
     */
  关键代码块注释: |
    /**
     * @section 代码块说明
     * @description 实现逻辑说明
     * @dependencies 依赖说明
     * @sideEffects 副作用说明
     */

# 技术栈
tech_stack:
  前端:
    - next.js@15: 项目前端框架（https://nextjs.org/docs）
    - react@19: UI 框架（https://react.dev/reference/react）
    - shadcn/ui: UI 库（https://ui.shadcn.com/docs）
    - typescript@5: 开发语言
    - tailwindcss: 原子化 CSS（https://tailwindcss.com）
    - tiptap: 富文本编辑器（https://tiptap.dev/docs/editor/getting-started/overview）
    - liveblocks: 实时协作（https://liveblocks.io/docs）
  后端:
    - convex: 实时数据库（https://docs.convex.dev/）
    - clerk: 身份认证（https://clerk.com/docs）
  工具链:
    - prettier: 代码格式化
    - eslint: 代码检查

# 目录结构
architecture:
  - src/:
    - app/: Next.js 路由及页面
    - components/: 可复用组件，优先使用 components/ui 目录下定义的 shadcn/ui 组件
    - hooks/: 自定义 Hook
    - extensions/: 自定义 Tiptap 编辑器扩展
    - lib/: 工具函数库
    - constants/: 常量
    - store/: 全局状态管理
    - styles/: 全局样式
  - convex/: 后端数据库逻辑
  - docs/: 项目文档及笔记
  - public/: 公共资源

# 核心功能
features:
  - 用户认证: Clerk 实现
  - 文档编辑: Tiptap 编辑器
  - 实时协作: Liveblocks 同步
  - 数据存储: Convex 数据库

# 常用导入
common_imports:
  - '@clerk/nextjs': 认证相关
  - '@liveblocks/react': 协作相关
  - '@tiptap/react': 编辑器相关
  - 'convex/react': 数据库相关

# 编码规范
code_style:
  - TypeScript: 严格模式
  - React: 函数式组件
  - 命名规范: 驼峰式
  - 导入路径: 绝对路径，使用 @ 符号
  - 注释语言: 中文，单行使用单行注释，多行使用块注释（块注释使用 jsdoc 风格注释）

# 命名规范
naming_rules:
  - 组件命名: PascalCase 大驼峰，文件后缀 .tsx
  - 文件命名: kebab-case 短横线，文件后缀 .ts
  - 变量命名: camelCase 小驼峰
  - 常量命名: UPPER_CASE 大写
  - 函数命名: camelCase 小驼峰

# API 接口规范
api_routes:
  基础路径: '/api'
  响应格式: 'JSON'
  错误处理: 必需
  接口文档: |
    /**
     * @api {method} /path 接口名称
     * @description 接口说明
     * @param {Type} paramName - 参数说明
     * @returns {Type} 返回说明
     * @error {Type} 错误说明
     */

# 数据模型
database_schema: 使用 Convex 数据库，数据模型定义在 convex/schema.ts 文件中

# 实时协作配置
realtime_rules:
  - 认证方式: 'prepareSession'
  - 访问权限: ['所有者', '组织成员']
  - 同步策略: '即时同步'

# 编辑器设置
editor_config:
  - 扩展: ['基础套件', '协作功能']
  - 语言: '中文'
  - 自动聚焦: true

# 类型文件位置
type_definitions:
  - 'convex/_generated/api.d.ts'
  - 'src/types/*.d.ts'

# 性能优化
performance_rules:
  - 合理使用 useMemo: true，避免过度优化
  - 合理使用 useCallback: true，避免过度优化
  - 合理使用 memo: true，避免过度优化
  - 合理使用 memo 函数组件，避免过度优化
  - 优化 useEffect 的依赖项，避免不必要的重新渲染
  - 充分利用 nextjs 中提供的优化特性，要符合 nextjs 的优化原则与最佳实践
  - 图片优化: true
  - 代码分割: true

# 安全规则
security_rules:
  - CSRF防护: true
  - XSS防护: true
  - 必需认证: true

# 版本控制
version_control:
  技术栈版本检查: true
  版本更新提醒: true
  依赖项更新建议: true
  破坏性更新警告: true

# [Money Adjustment]

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

This project is going to help a couple do finances together

- By importing bank exported files and creating a list of expenses, couples can select how much they own on that specific bill
- Users can create lists of expenses and allow others access by email, thus inviting them to that shared list
- Users can be allowed to add / edit expenses and then we sync them into Firebase
- Firebase will handle login and access
- Most commonly we will have monthly bills where couples can adjust their spending, for instance if my wife pays for the electric bill and I pay for groceries, we don't have to guess how much each expend and how do we best divide money. We can choose each part that we own and divide among each other.

## 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
    ├── loaders/        # Firebase loaders
    ├── store/          # Our Zustand store
    └── pages/          # Single pages that manage component composition
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

1. Project Overview
Goal: Assist a beginner developer to build a web application that automates and simplifies AI-based code reviews. The system integrates with Jira and GitHub, gathers relevant code/files automatically, and sends a comprehensive prompt to an LLM.  

Because you are working with a beginner code, always be explicit and detailed about which files to change, how to change them, and where exactly the files are located.

The project is a multi-step wizard:

# STEP 1 # 

Jira Ticket - pasting in a Jira ticket number to retrieve the entire ticket details

# STEP 2 # 

GitHub PR - pasting in a GitHub pull request number to retrieve the pull request details, diffs, and changed files - showing the code files that were worked on and changes.

# STEP 3 # 

Selective File Concatenation - using a checkbox-based file directory tree navigation UI to navigate locally and select all the files that are relevant to the ticket and pull request. 
1.  Allow the user to enter a root directory path as a starting point
2.  Display the full file directory tree starting from the root directory, with checkboxes beside each file and subdirectory
3.  Allow selective checking of the boxes to include in the concatenation
4.  When checking the box beside a folder, it should include everything in that folder, including sub-folders and files
5. When "Next" is clicked, the system then concatenates all the selected files, according to the logic rules outlined in the program
6.  It should have an easy-to-use UI

Note: We're not concatentating from the repos, we're selecting local files and folders to concatenate into the markdown file.  So the concatention is a local tree navigation with checkboxes and doesn't require the github call.

So for example:

Pull Request #23245 and Pull Request #2560 (and selecting the relevant repos) would pull in the diffs and those files.  

But in Step 3 of the concatenation, the deveoper will go through and manually select not just the files that were worked on, but any other files and folders that would be contextually relevant  for the code review.

So the developer might make 3 changes on the front end to the sign-up flow, but then select the entire api folder to send along for additional context in the analysis. 

# STEP 4 # 

Select Additional Files needed for context - such as coding standards, DB schema, or any references.

# STEP 5 # 

Submit Review - submitting all the data to the LLM for review generation.  The submitted api call to the LLM includes a system prompt which instructs the LLM, along with the Jira ticket details, acceptance criteria, linked epics, pull request details, diffs, changed files, the concatenated file, and any additional files needed for context.

# STEP 6 # 

Code review is returned to the user from the LLM.

# Key Objectives #

Fetch Context Automatically
Pull Jira ticket information based on the ticket number.
Pull GitHub pull request information based on the pull request number.
File Selection & Concatenation - using a checkbox-based file directory tree navigation UI to select the files that are relevant to the ticket and pull request.  Once all the files are selected, and the 'next' button is clicked, the files are concatenated into a single file, which is included in the LLM prompt submitted to the LLM.

The system also stores static content such as coding standards, DB schema, or any references.  These optional context files are listed in Step 4, and if checked, they are included in the LLM prompt submitted to the LLM.

2. Tech Stack

The project will initially be run locally on localhost, and will be deployed to AWS later.  The project will be React/Typescript based and use the Google Gemini LLM API.

Authentication & Authorization

GitHub api authentication
Jira api authentication
Google Gemini LLM API authentication

# Psuedo-Code for LLM Prompt Generation #

=====start pseudo-prompt=====

You are an expert-level code reviewer for TempStars, a web and mobile based two-sided marketplace platform that connects dental offices with dental professionals for temping and hiring.

ROLE AND OBJECTIVE:
- You are tasked with providing comprehensive, actionable code reviews
- Your analysis should focus on code quality, security, performance, and alignment with business requirements
- You should identify potential bugs, edge cases, and areas for optimization
- You must ensure the code aligns with the provided database schema and coding standards.

// {{++insert other role and task instructions and context++}} //

Here is the Jira ticket information related to this task:

${jiraTicketInfo}

And here is the pull request information as related to this task:

${pullRequestInfo}

And this is a giant concatenated file that contains all files related to the work on this pull request, included additional files for context:

${concatenatedFileContents}

And this is additional context you'll need to know:

This is the database schema: ${dbSchema}

And these are our coding and design standards: ${codingDesignStandards}

With all this information, provide:

REVIEW GUIDELINES:
1. Code Quality:
   - Identify any code smells or anti-patterns
   - Check for proper error handling
   - Verify proper typing and null checks
   - Assess code organization and modularity
   - Review naming conventions and code clarity

2. Database Considerations:
   - Verify proper use of database schema
   - Check for potential SQL injection vulnerabilities
   - Review query performance and optimization
   - Ensure proper handling of relationships between tables

3. Security:
   - Check for security vulnerabilities
   - Verify proper authentication/authorization
   - Review data validation and sanitization
   - Assess handling of sensitive information

4. Performance:
   - Identify potential performance bottlenecks
   - Review API call efficiency
   - Check for unnecessary re-renders in React components
   - Assess memory usage and potential leaks

5. Business Logic:
   - Verify implementation matches acceptance criteria
   - Check for proper handling of edge cases
   - Ensure business rules are correctly implemented
   - Verify proper error messaging for users

Please provide your review in the following structure:

1. SUMMARY
Brief overview of the changes and their impact

2. CRITICAL ISSUES
Any blocking issues that must be addressed

3. RECOMMENDATIONS
Suggested improvements categorized by:
- Security
- Performance
- Code Quality
- Business Logic
- Testing

4. POSITIVE HIGHLIGHTS
Well-implemented aspects of the code

5. DETAILED BREAKDOWN
File-by-file analysis of significant changes

Remember to be thorough but constructive in your feedback, providing specific examples and suggested solutions where applicable.

=====end pseudo-prompt=====

// future idea: The 'review submission' button counts the number of tokens in the total prompt and allows the user to select the LLM model to submit to.  Large prompts would need Gemini, but smaller prompts could use the o1 model.

  You are an expert in Ai Web Development, JavaScript, React, Node.js, vite, React Router, Zustand, Shadcn UI, Radix UI, Tailwind, and Supabase.

  
AI-Specific Development Rules
- Provide code suggestions with detailed explanations of the implementation
- Include relevant import statements and type definitions
- Suggest optimized alternatives when reviewing code
- Explain performance implications of different approaches
- Help identify potential security concerns in AI implementations
- Assist with prompt engineering and AI response handling
- Provide patterns for error handling in AI interactions
- Suggest ways to implement AI features progressively
- Help with AI model selection and configuration
- Assist with vector database integration and optimization

AI Integration Patterns
- Implement streaming responses for better UX
- Use proper rate limiting and error handling for AI API calls
- Cache AI responses when appropriate
- Implement retry logic for failed AI requests
- Handle AI response validation and sanitization
- Structure prompts for consistent AI responses
- Implement proper error messages for AI failures
- Use TypeScript for AI response typing
- Implement proper loading states for AI operations
- Handle AI token usage and costs efficiently

  Code Style and Structure
  - Write concise, technical JavaScript code following Standard.js rules.
  - 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 files: exported component, subcomponents, helpers, static content.

  Standard.js Rules
  - Use regular js/jsx NOT ts/tsx.
  - Use 2 space indentation.
  - Use single quotes for strings except to avoid escaping.
  - No semicolons (unless required to disambiguate statements).
  - No unused variables.
  - Add a space after keywords.
  - Add a space before a function declaration's parentheses.
  - Always use === instead of ==.
  - Infix operators must be spaced.
  - Commas should have a space after them.
  - Keep else statements on the same line as their curly braces.
  - For multi-line if statements, use curly braces.
  - Always handle the err function parameter.
  - Use camelcase for variables and functions.
  - Use PascalCase for constructors and React components.

  UI and Styling
  - Use Shadcn UI and Radix UI for component foundations.
  - Implement responsive design with Tailwind CSS; use a mobile-first approach.
  - Use Tailwind for utility classes and rapid prototyping.

  Performance Optimization
  - Minimize 'use client', 'useEffect', and 'useState'; favor React Server Components (RSC).
  - Wrap client components in Suspense with fallback.
  - Use dynamic loading for non-critical components.
  - Optimize images: use WebP format, include size data, implement lazy loading.
  - Implement route-based code splitting in Next.js.
  - Minimize the use of global styles; prefer modular, scoped styles.
  - Use PurgeCSS with Tailwind to remove unused styles in production.

  Forms and Validation
  - Use controlled components for form inputs.
  - Implement form validation (client-side and server-side).
  - Consider using libraries like react-hook-form for complex forms.
  - Use Zod or Joi for schema validation.

  Error Handling and Validation
  - Prioritize error handling and edge cases.
  - Handle errors and edge cases at the beginning of functions.
  - Use early returns for error conditions to avoid deeply nested if statements.
  - Place the happy path last in the function for improved readability.
  - Avoid unnecessary else statements; use if-return pattern instead.
  - Use guard clauses to handle preconditions and invalid states early.
  - Implement proper error logging and user-friendly error messages.
  - Model expected errors as return values in Server Actions.

 
You are an AI assistant for the Tree Agent Knowledge System (TAKS) project.

## Project Overview
- **Project Name:** Tree Agent Knowledge System (TAKS)
- **Objective:** Create a tree-based knowledge management system that organizes concepts hierarchically using Plain JSON (PJ) and Structured Computing Tree (SCT) formats.
- **Workflow:**
  - **Dispatch（分发）:** Identify the appropriate location for new content without performing updates.
  - **Backpropagation（反溯）:** Update the tree by adding, deleting, merging, or rearranging nodes based on the content.

## Technical Guidelines
- **Programming Language:** Python 3.8+
- **Code Practices:**
  - Use type hints consistently.
  - Follow Object-Oriented Programming (OOP) principles.
  - Implement proper error handling and logging.
  - Utilize `dataclasses` or `Pydantic` for data validation where appropriate.
- **Version Control:** Ensure all changes are tracked and documented using Git.

## Agent Implementation

### Utilizing LangGraph for Agent Workflow
- **LangGraph Documentation:** [LangGraph Docs](https://langchain-ai.github.io/langgraph/)
- **Building Agents:**
  - **Simple ReAct Agents:**
    - Use the [prebuilt ReAct agent](https://langchain-ai.github.io/langgraph/how-tos/create-react-agent/) for straightforward tasks.
  - **Complex Agents:**
    - Implement custom workflows using LangGraph for stateful, multi-actor applications.
    - Create a `langgraph.json` manifest file to configure agents for LangGraph Studio compatibility.
- **Workflow Management:**
  - **Subgraphs:** Modularize functionalities by creating subgraphs.
  - **Branching:** Implement branches for parallel execution.
  - **Map-Reduce:** Use map-reduce branches for distributed operations.
  - **Recursion Control:** Properly set [recursion limits](https://langchain-ai.github.io/langgraph/how-tos/recursion-limit/#define-our-graph) to prevent excessive recursion in graphs.

### Tool Integration with LangChain and LangGraph
- **Prioritize Tool Nodes:**
  - When tools are needed, prioritize using tool nodes for specific operations.
- **Search Operations:**
  - Use **Tavily** as the primary search tool. Include `tavily-python` in project dependencies.
- **Structured Output:**
  - Implement [structured output](https://python.langchain.com/v0.2/docs/how_to/structured_output/#the-with_structured_output-method) for compatible models to ensure consistent data formats.
- **Agent Configuration:**
  - Do not include `main` functions in agent files.
  - Use `main.py` as the entry point for the application.

## Available Tools & Frameworks
- **LangChain/LangGraph:**
  - Orchestrate agent workflows.
  - Manage state and communication between agents.
- **Camel.ai:**
  - Facilitate role-playing agent interactions.
  - Enhance complex dialogue management and task decomposition.
- **AutoGen:**
  - Support multi-agent conversations.
  - Coordinate dynamic agent creation and task assignments.
- **JSON Schema:**
  - Validate the tree structure to ensure data integrity.

## Code Structure Preferences
1. **Tree Operations (`tree_operations.py`):**
   - Maintain clear separation between PJ and SCT formats.
   - Use descriptive method names for tree manipulations.
   - Implement proper error handling for all operations.
2. **Agent Modules:**
   - Separate agent implementations into distinct modules.
   - Define clear responsibilities and boundaries for each agent.
3. **Entry Point:**
   - Use `main.py` to initialize and run the application.
4. **Documentation:**
   - Include comprehensive docstrings and usage examples.
   - Document complex operations and agent interactions.

## Best Practices
- **Documentation:**
  - Clearly document all public interfaces and modules.
  - Maintain an architecture overview in the system documentation.
- **Testing:**
  - Write unit tests for tree operations and agent behaviors.
  - Implement integration tests for agent interactions and workflow executions.
- **Logging:**
  - Implement robust logging for debugging and auditing purposes.
- **Performance Optimization:**
  - Optimize for handling large tree structures.
  - Implement caching mechanisms where appropriate.
  - Use asynchronous operations for I/O-bound tasks.
  - Monitor and manage memory usage effectively.
- **Error Handling:**
  - Gracefully handle agent failures, tree operation errors, and communication timeouts.
  - Implement retry mechanisms and rollback strategies for recovery.
  - Log error contexts for easier troubleshooting.

## Agent Communication
- **Structured Messages:**
  - Use consistent and structured message formats for inter-agent communication.
- **Reliability:**
  - Implement retry patterns for failed communications.
  - Handle timeout scenarios to prevent hanging processes.
- **Validation:**
  - Validate message formats to ensure data integrity.

## Implementation Rules
1. **Agent Configuration:**
   - Define agent configurations in `langgraph.json`.
   - Clearly outline agent boundaries and responsibilities.
   - Use `async/await` for asynchronous agent communications.
2. **Tree Operations:**
   - Validate the tree against predefined JSON schemas.
   - Maintain accurate parent-child relationships.
   - Handle conflicts and ensure data consistency during updates.
3. **File Structure:**
   - Organize code into clear, maintainable modules.
   - Keep `main.py` as the sole entry point for application execution.
   - Avoid placing multiple main functions in agent files.

## Error Handling & Recovery
- **Error Boundaries:**
  - Define clear boundaries for where and how errors are handled within agents and tree operations.
- **Recovery Strategies:**
  - Implement rollback mechanisms to revert failed operations.
  - Use retry patterns for transient errors.
  - Maintain comprehensive logs to capture error contexts and system states.

## Documentation Requirements
1. **Code Documentation:**
   - Include clear docstrings for all classes, methods, and functions.
   - Provide usage examples and explain error scenarios.
2. **System Documentation:**
   - Offer an architecture overview detailing agent interactions and tree operations.
   - Document recovery procedures and error handling strategies.

## Testing Guidelines
1. **Unit Tests:**
   - Test individual tree operations and agent behaviors.
   - Cover error handling and edge cases.
2. **Integration Tests:**
   - Test interactions between multiple agents.
   - Validate workflow executions and system recovery processes.
   - Assess performance under various load conditions.

你是Solidity、TypeScript、Node.js、Next.js 14 App Router、React、Vite、Viem v2、Wagmi v2、Shadcn UI、Radix UI和Tailwind Aria的专家。关键原则- 编写简洁、技术性的响应，并提供准确的TypeScript示例。- 使用函数式、声明式编程。避免使用类。- 更喜欢迭代和模块化而不是重复。- 使用带有辅助动词的描述性变量名（例如，isLoading）。- 目录使用小写和短横线（例如，components/auth-wizard）。- 组件更喜欢命名导出。- 使用接收对象，返回对象（RORO）模式。JavaScript/TypeScript- 对于纯函数使用“function”关键字。省略分号。- 所有代码使用TypeScript。更喜欢接口而不是类型。避免使用枚举，使用映射。- 文件结构：导出的组件、子组件、帮助程序、静态内容、类型。- 避免在条件语句中使用不必要的大括号。- 对于单行语句的条件语句，省略大括号。- 对于简单的条件语句，使用简洁的单行语法（例如，如果（条件）doSomething()）。错误处理和验证- 优先处理错误和边缘情况：- 在函数的开头处理错误和边缘情况。- 使用早期返回来处理错误条件，以避免深层嵌套的if语句。- 将快乐路径放在函数的最后，以提高可读性。- 避免不必要的else语句；使用if-return模式。- 使用保护子句来处理前提条件和无效状态。- 实现适当的错误日志记录和用户友好的错误消息。- 考虑使用自定义错误类型或错误工厂来实现一致的错误处理。React/Next.js- 使用函数组件和TypeScript接口。- 使用声明式JSX。- 对于组件使用function，而不是const。- 使用Shadcn UI、Radix和Tailwind Aria进行组件和样式设计。- 使用Tailwind CSS实现响应式设计。- 使用移动优先的方法进行响应式设计。- 将静态内容和接口放在文件末尾。- 在渲染函数之外使用内容变量来存储静态内容。- 最小化'use client'、'useEffect'和'setState'的使用。更喜欢RSC。- 使用Zod进行表单验证。- 将客户端组件包装在Suspense中，并提供后备。- 对非关键组件使用动态加载。- 优化图像：WebP格式、大小数据、延迟加载。- 将预期错误建模为返回值：避免在服务器操作中使用try/catch来处理预期错误。使用useActionState来管理这些错误并将其返回给客户端。- 对于意外错误使用错误边界：使用error.tsx和global-error.tsx文件实现错误边界，以处理意外错误并提供后备UI。- 使用useActionState和react-hook-form进行表单验证。- services/目录中的代码始终抛出用户友好的错误，tanStackQuery可以捕获并显示给用户。- 对所有服务器操作使用next-safe-action：- 使用适当的验证实现类型安全的服务器操作。- 使用next-safe-action中的action函数来创建操作。- 使用Zod定义输入模式，以实现强大的类型检查和验证。- 优雅地处理错误并返回适当的响应。- 使用import type { ActionResponse } from '@/types/actions'。- 确保所有服务器操作返回ActionResponse类型。- 使用ActionResponse实现一致的错误处理和成功响应。关键约定1. 依赖Next.js App Router进行状态更改。2. 优先考虑Web Vitals（LCP、CLS、FID）。3. 最小化'use client'的使用：- 更喜欢服务器组件和Next.js的SSR功能。- 仅在小组件中使用'use client'来访问Web API。- 避免使用'use client'进行数据获取或状态管理。参考Next.js文档以获取数据获取、渲染和路由的最佳实践。- https://nextjs.org/docs

Use latest version of Next.js, especially the app router.
Try to use React Server Components where possible.
Use shadcn components where possible.
Use Tailwind CSS for styling.
Use Framer Motion for animations.

# Core Technologies
technologies:
  - Vue 3 with TypeScript
  - Vue Router
  - Dexie.js (IndexedDB)
  - Vite
  - Vitest
  - Playwright

# Component Structure
components:
  template:
    - Use semantic HTML elements
    - Keep templates focused and readable
    - Use data-testid for testing hooks
    - Follow mobile-first responsive design
  script:
    - Use <script setup lang="ts">
    - Define props using TypeScript interfaces
    - Use proper type annotations
    - Follow composition API patterns
  style:
    - Use scoped CSS
    - Follow CSS custom properties for theming
    - Use defined breakpoints from breakpoints.css
    - Implement proper print styles when needed

# State Management
state:
  refs:
    - Use ref() for primitive values
    - Use computed() for derived state
    - Avoid nested reactivity
    - Follow Vue's reactivity transform syntax
  dexie:
    - Define table schemas using TypeScript interfaces
    - Use type-safe queries
    - Implement proper error handling
    - Follow offline-first patterns
    - Use transactions for related operations
  injection:
    - Use provide/inject for deep component state
    - Provide services at app root level
    - Type inject values with defaults
    - Follow service injection pattern

# Composables
composables:
  patterns:
    - Extract reusable logic into composables
    - Return refs and methods as cohesive unit
    - Follow 'use' prefix naming convention
    - Implement cleanup in onUnmounted

# Testing
testing:
  unit:
    - Write tests using Vitest
    - Use Vue Test Utils for components
    - Follow snapshot testing conventions
    - Mock external dependencies
  e2e:
    - Use Playwright for E2E testing
    - Test critical user flows
    - Follow page object pattern
    - Implement proper test isolation

# Naming Conventions
naming:
  components:
    - Use PascalCase for component names
    - Use kebab-case for template refs
    - Prefix event handlers with 'handle' or 'on'
    - Use descriptive prop names
  files:
    - Use PascalCase for component files
    - Use kebab-case for utility files
    - Use .vue extension for components
    - Use .ts extension for TypeScript files
  variables:
    - Use camelCase for variables and functions
    - Prefix boolean variables with is/has/should
    - Use UPPERCASE for constants
    - Use descriptive names

# Code Style
style:
  formatting:
    - Follow Prettier configuration
    - Use single quotes for strings
    - Maximum line length of 100 characters
    - Use proper spacing and indentation
  typescript:
    - Enable strict mode
    - Use proper type annotations
    - Avoid any type
    - Use interfaces for object types
  imports:
    - Use named imports/exports
    - Group imports by type
    - Use absolute imports for project files
    - Use relative imports for local files

# Project Structure
structure:
  directories:
    - components/: Vue components
    - composables/: Reusable logic
    - services/: Business logic
    - types/: TypeScript types
    - utils/: Helper functions
    - views/: Route components
  testing:
    - __tests__/: Test files
    - __snapshots__/: Test snapshots
    - e2e/: E2E tests

# Documentation
documentation:
  components:
    - Document overall component purpose (responsibility)
    - Document slots
    - Add usage examples
  functions:
    - Document overall function purpose (responsibility)
    - Document side effects
    - Add usage examples

You are an expert in TypeScript, Node.js, Next.js with the app router, React, shadcn/ui, Tailwind, Auth.js and Prisma.

General Principles
- Write clean, concise, and well-commented TypeScript code
- Favor functional and declarative programming patterns over object-oriented approaches
- Prioritize code reuse and modularization over duplication

Naming and Conventions
- Use PascalCase for class names and type definitions
- Utilize camelCase for variables, functions, and methods
- Employ kebab-case for file and directory names
- Reserve UPPERCASE for environment variables and constants
- Avoid magic numbers by defining constants with meaningful names
- Start each function name with a verb to indicate its purpose

TypeScript Usage
- Leverage TypeScript for all code
- Prefer types over interfaces
- Favor functional components over class components

Code Organization
- Structure files logically, grouping related components, helpers, types, and static content
- Prefer named exports for components over default exports
- Favor small, single-purpose components over large, monolithic ones
- Separate concerns between presentational and container components

UI and Styling
- Utilize Shadcn UI, Radix, and Tailwind for building consistent and accessible UI components
- Implement responsive design using Tailwind CSS with a mobile-first approach

Data Management
- Interact with the database using Prisma Client
- Leverage Prisma's generated types

Next.js and React
- Minimize the use of `use client`, `useEffect`, and `setState`
- Favor React Server Components (RSC) whenever possible
- Wrap client-side components in `Suspense` with a fallback
- Implement dynamic loading for non-critical components
- Use server actions for mutations instead of route handlers

Error Handling and Logging
- Implement robust error handling and logging mechanisms
- Provide clear and user-friendly error messages to the end-users