Version of Cursor/Windsurf/VS Code LLM rules shown by Yifan at https://www.youtube.com/watch?v=aG-utUqVrb0 (small changes by me)

.windsurfrules

# Project Instructions for Code-Generating LLMs

Every time you opt to implement a rule(s), explicitly articulate the rule(s) in the output. You can shorten the rule description to a single word or phrase.

## Project Context

The project is focused on developing a chatbot that does cool things
- List
- Your
- Features
- Here

Not all features are currently available.

## Code Style and Structure
- Write concise, technical TypeScript code with accurate examples
- Prefer iteration and modularization over code duplication
- Structure repository files as such:
```
├── PLAN.md                   # Outline for planning and executing a unit of work
├── README.md                 # Project overview documentation
├── TODO.md                   # List of pending tasks
├── ai-docs/                  # Documentation and examples for reference
├── app/
│   ├── (auth)/               # Authentication UI and API
│   └── (chat)/               # Chat UI and API
├── components/               # Shared UI components specific to the project 
│   └── ui/                   # Generic UI components like labels, inputs, buttons, etc.
├── evals/                    # Evaluation frameworks for various LLM calls
│   ├── context-evaluation/    # Complex use cases that pull multiple achievements from various messages
│   ├── conversation-gen/     # Generates realistic conversation histories for other evaluations
│   └── single-evaluation/     # Single Entry Evaluation
├── hooks/                    # Shared React hooks
├── lib/                      # Core library code
│   ├── ai/                   # AI/LLM function implementations
│   ├── db/                   # Database schema and queries
│   └── editor/               # Code related to editing
├── pages/
├── public/
│   ├── fonts/                # Static font assets
│   └── images/               # Static image assets
└── test/                     # Test cases
```

## Tech Stack
- TypeScript
- React
- Next.js
- Node.js
- PostgreSQL
- Tailwind CSS
- pnpm for package management
- Vercel AI SDK
- NextAuth.js
- Braintrust (LLM Evaluation Framework)

## 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., generateText.ts)

## TypeScript Usage
- Utilize TypeScript for all code; prefer interfaces over types
- Avoid using React.FC
- Use import and export instead of require
- Use `tsx` for running TypeScript files directly
- Example: `pnpm tsx path/to/file.ts`
- Maintain appropriate type definitions in `types.ts` files

## UI and Styling
- Use Tailwind CSS for styling
- Employ Shadcn UI and Radix UI for UI components
- Use `npx shadcn@latest add <component-name>` to add a new Shadcn component
- When introducing a new Shadcn component, document the installation command

## Error Handling
- Ensure proper error boundaries in React components

## Security
- Sanitize user inputs
- Manage any sensitive information appropriately

## Testing
- Use Jest for unit testing
- Utilize @types/jest for TypeScript support
- Implement ts-jest for TypeScript integration
- Leverage @testing-library/jest-dom for DOM testing utilities
- Use @swc/jest for expedited test execution
- New evaluations should be created with each addition of an LLM call. Refer to the `eval.ts` files in the `evals` directory for examples

## Git Usage
Commit Message Prefixes:
- "fix:" for bug fixes
- "feat: " for new features
- "docs: " for modifications to documentation
- "refactor: " for code restructuring
- "test: " for adding or updating tests
- "chore: " for changes that do not affect src or test files
- "perf: " for performance enhancements
- "style: " for changes that do not alter the meaning of the code

Rules:
- Maintain a concise summary line
- Provide descriptions for non-obvious changes
- Reference issue numbers as applicable

## Documentation
- Preserve a comprehensive README.md file that outlines the project's aim, features, and usage guidelines.
- Include comments for complex logic
- Ensure each file has a clear purpose and is well-documented.

## Development Workflow
- At the onset of a new task, create a detailed plan and record it in the PLAN.md file.
- Keep the PLAN.md file updated as you progress through the task.
- Use git for version control to track changes and manage the codebase.
- Adhere to semantic versioning for releases
- Use `pnpm changeset` to create changelogs (utilizing the @changesets/cli plugin for pnpm)
- Implement a proper code review process
- Conduct tests in various environments
- Maintain the TODO.md file consistently

## Additional Considerations
- Automatically propose additions to a configuration file where best practices are discussed or updated during the generation process if the content is not already present in the file.