Awesome Cursor Rules Collection

This codebase is a typescript discord.js modular discord bot capable of interacting with the community in discord.

This bot is also capable of running different command functionalities based on modules and commands added in the src/commands folder.

Command functionality should be created as a module in the src/modules folder. Adding the command to the discord bot is done in the src/commands folder.

Guide: Adding New Commands
------------------------

To add a new command to the bot, follow these steps:

1. Create a Module (if needed):
   - Create a new folder in src/modules for your command's functionality
   - Implement the core logic and utilities in this module
   - Export the necessary functions that will be used by the command

2. Create Command File:
   - Add a new TypeScript file in src/commands (e.g., myCommand.ts)
   - File must export:
     ```typescript
     // Command definition
     export const data = new SlashCommandBuilder()
       .setName('commandname')
       .setDescription('what the command does')
       .addXXXOption(...); // Add any needed options

     // Command execution logic
     export async function execute(interaction: ChatInputCommandInteraction) {
       // Implementation
     }

     // Button handler (if command uses buttons)
     export async function handleButtonInteraction(
       interaction: ButtonInteraction
     ): Promise<void> {
       // Button handling logic
     }
     ```

3. Command Structure:
   - Use proper error handling and logging
   - Defer replies for operations that might take time
   - Use embeds and buttons for rich interactions
   - Follow the existing command patterns for consistency

4. Button Interactions:
   - If your command includes button interactions, update the CommandHandler.ts file to handle the button events.

The command will be automatically loaded when added to the commands folder. If your command includes button interactions, update the CommandHandler.ts file to handle the button events.

Commands are automatically loaded in when they are added to the commands folder, however button functionality has to be differentiated in the CommandHandler.ts file.

I am using the PINO logger for logging. Please log everything with depth

- Use info to log the flow of the program
- Use debug to log more detailed and full outputs
- Use error to log errors

Guide: Creating New Tools for the Chatbot
----------------------------------------

To add a new tool that the chatbot can use, follow these steps:

1. Define the Tool in config/chatbotTools.yaml:
   - Add a new tool definition under the 'tools' array
   - Specify type: "function"
   - Define the function name, description, and parameters
   - Mark required parameters and set additionalProperties to false
   Example:
   ```yaml
   - type: "function"
     function:
       name: "tool_name"
       description: "What the tool does"
       parameters:
         type: "object"
         properties:
           param1:
             type: "string"
             description: "Parameter description"
         required: ["param1"]
         additionalProperties: false
   ```

2. Create Tool Handler in src/modules/chatbotModule/tools/toolHandler.ts:
   - Define the argument interface for your tool
   - Create a handler function that takes (args, client)
   - Implement the tool's functionality
   - Add proper logging using pino
   - Add the tool to the executeToolCall switch statement
   Example:
   ```typescript
   interface ToolArgs {
     param1: string;
   }

   async function handleTool(args: ToolArgs, client: Client): Promise<string> {
     logger.info({ args }, '[tool_name] Tool invoked');
     try {
       // Tool implementation
       return 'Success message';
     } catch (error) {
       logger.error({ error }, 'Error in tool');
       throw error;
     }
   }
   ```

3. Testing:
   - The tool will be automatically available to the chatbot
   - The chatbot will use the tool when appropriate based on the tool's description
   - Tool execution results are fed back to the chatbot for further processing

Note: Tools should be atomic and focused on a single responsibility. Complex functionality should be broken down into multiple tools that can be chained together using the run_again tool.

# You are an expert in TypeScript, Node.js, Next.js App Router, React, Redux, Zustand, Shadcn UI, Radix UI and Tailwind

You carefully provide accurate, factual, thoughtful answers, and excel 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, up to date, bug free, fully functional and working, secure, performant and efficient code.
- Focus on readability over being performant.
- Fully implement all requested functionality.
- Leave NO todo’s, placeholders or missing pieces.
- 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.

## 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 files: exported component, subcomponents, helpers, static content, types.
- Always add a trailing comma.

## Naming Conventions

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

  ## TypeScript Usage

- Use TypeScript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with TypeScript interfaces.

## Syntax and Formatting

- Use the "function" keyword for pure functions.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
- Use declarative JSX.

## UI and Styling

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

## Accessibility (a11y)

- Use semantic HTML elements.
- Implement proper ARIA attributes.
- Ensure keyboard navigation support.

## Internationalization (i18n)

- Use next-intl for internationalization.

## 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.

## Performance Optimization

- Minimize 'use client', 'useEffect', and 'setState'; 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.

## Key Conventions

- Optimize Web Vitals (LCP, CLS, FID).
- Limit 'use client':

  - Favor server components and Next.js SSR.
  - Use only for Web API access in small components.
  - Avoid for data fetching or state management.
  - Follow Next.js docs for Data Fetching, Rendering, and Routing.

# Cursor Rules

## General guidance

Use Tailwind CSS for styling.
Use Next.js for the framework.
Use React Server Components for any component that doesn't require client-side interactivity.
Use shadcn/ui components, espeically those saved in the /components/ui folder.

## Context about this application

This NextJS application will let people view a summary of their calendar, like "Spotify Wrapped" for their calendar.

They will connect to their Google Calendar, and we will use the Google Calendar API to fetch their events.

Then, we will use the events to generate a summary of their calendar.

## User stories

As a user, I want to be able to connect to my Google Calendar so that I can view a summary of my calendar.

## Acceptance criteria

Given I am on the homepage, when I connect to my Google Calendar, then I should see a summary of my calendar.

You are an Expert in ReactJS, JavaScript, TypeScript, HTML, CSS and modern UI/UX frameworks (e.g., TailwindCSS, Shadcn, Radix). You are thoughtful, give nuanced answers, and are brilliant at reasoning. You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning. Additionally, you are an expert in i18n and localization as well as an expert in web security and cryptography best practices. Maintain and add the highest standards of security and best practices to the codebase.

- 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 (Don't 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 finalized.
- 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.
- If new language is requested, add it to the i18n/locales folder and update the i18n/types.ts file.
- If existing translations are missing, add them to the i18n/locales folder and update the i18n/types.ts file.
- Leave relevant code comments that describe the 'why' behind the code or link to the relevant documentation.

{
  "version": "1.0",
  "context_initialization": {
    "required_reading": [
      ".notes/MISSION.md",
      ".notes/ARCHITECTURE.md"
    ],
    "project_scope": {
      "name": "Tremor Assist",
      "type": "accessibility-software",
      "platforms": ["macos", "windows"]
    }
  },
  "technology_requirements": {
    "critical": {
      "tauri": {
        "version": "2.2.0",
        "cli_version": "2.2.1",
        "api_version": "2.2.0",
        "bundler_version": "2.2.0",
        "documentation": "https://v2.tauri.app",
        "required_imports": [
          "@tauri-apps/api@2.2.0/window",
          "@tauri-apps/api@2.2.0/event"
        ],
        "forbidden_imports": [
          "@tauri-apps/api/tauri",
          "tauri/api",
          "@tauri-apps/api@1.*"
        ],
        "dependencies": {
          "wry": "0.48.0",
          "tao": "0.31.0"
        }
      },
      "package_management": {
        "yarn": {
          "version": ">=1.22.0",
          "required": true,
          "forbidden": ["npm", "pnpm"],
          "commands": {
            "correct": [
              "yarn install",
              "yarn add",
              "yarn remove",
              "yarn tauri dev",
              "yarn tauri build"
            ],
            "incorrect": [
              "npm install",
              "npm run",
              "pnpm install"
            ]
          }
        }
      },
      "enigo": {
        "version": "0.3.0",
        "documentation": "https://docs.rs/enigo/0.3.0",
        "required_patterns": [
          "Enigo::new(&Settings::default())",
          "use enigo::{Enigo, Settings, Mouse}"
        ]
      }
    },
    "ui": {
      "theming": {
        "required": true,
        "modes": ["dark", "light"],
        "component_rules": [
          "All components must support both dark and light themes",
          "Use theme-aware color variables instead of hard-coded colors",
          "Test all components in both themes before commit"
        ],
        "color_patterns": {
          "correct": [
            "useTheme()",
            "theme.colors",
            "colorScheme={colorScheme}"
          ],
          "incorrect": [
            "backgroundColor: '#000'",
            "color: 'white'",
            "hardcoded hex values"
          ]
        },
        "implementation": {
          "required_hooks": ["useColorScheme", "useTheme"],
          "required_props": ["colorScheme", "theme"],
          "required_tests": [
            "renders correctly in light mode",
            "renders correctly in dark mode",
            "handles theme switching"
          ]
        }
      },
      "accessibility": {
        "contrast_requirements": {
          "normal_text": "4.5:1",
          "large_text": "3:1"
        }
      }
    },
    "frontend": {
      "react": "latest",
      "typescript": {
        "strict": true,
        "target": "ES2022"
      }
    }
  },
  "component_guidelines": {
    "new_components": [
      "Must implement dark and light theme support",
      "Must use theme-aware styling",
      "Must include theme switching capability",
      "Must maintain accessibility in both themes"
    ],
    "styling_patterns": {
      "correct": [
        "Use theme tokens for colors",
        "Implement responsive design",
        "Support system theme preferences"
      ],
      "incorrect": [
        "Hard-coded colors",
        "Theme-specific styles",
        "Missing dark/light variants"
      ]
    }
  },
  "operational_protocol": {
    "before_action": [
      "Verify technology version compatibility",
      "Check yarn.lock for conflicts",
      "Verify theme support in components",
      "Create MECE task breakdown",
      "Check platform-specific requirements"
    ],
    "code_changes": [
      "Maintain < 5ms latency in mouse operations",
      "Ensure thread safety in mouse control",
      "Implement proper error handling",
      "Verify theme compatibility"
    ]
  },
  "safety_requirements": [
    "Validate all mouse input",
    "Check OS permissions before operations",
    "Implement proper error recovery",
    "Maintain type safety",
    "Ensure theme consistency"
  ],
  "priorities": {
    "files": [
      {
        "source": "src-tauri/src/lib.rs",
        "weight": 1.0,
        "focus": "mouse control core"
      },
      {
        "source": "src/hooks/useMouseTracker.ts",
        "weight": 0.9,
        "focus": "movement tracking"
      },
      {
        "source": "src/theme",
        "weight": 0.8,
        "focus": "theme configuration"
      }
    ],
    "documentation": {
      "source": ".notes/",
      "weight": 1.0
    }
  },
  "modes": {
    "base": {
      "description": "Routine development tasks",
      "version_check": true,
      "theme_check": true
    },
    "enhanced": {
      "description": "Complex algorithm optimization",
      "performance_critical": true,
      "latency_threshold": "5ms"
    }
  }
}

<code_guidelines>
  <code_writing>
    <instruction>
      When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.
    </instruction>
  </code_writing>

  <follow_up_questions>
    <instruction>
      After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.
    </instruction>
  </follow_up_questions>

  <concise_response>
    <trigger>VV</trigger>
    <instruction>
      If my response starts with "VV", give the most succinct, concise, shortest answer possible.
    </instruction>
  </concise_response>

  <commit_message_guidelines>
    <structure>
      <format>&lt;type&gt;[optional scope]: &lt;description&gt;

[optional body]

[optional footer(s)]</format>
    </structure>
    
    <rules>
      <rule>Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.</rule>
      <rule>The type feat MUST be used when a commit adds a new feature to your application or library.</rule>
      <rule>The type fix MUST be used when a commit represents a bug fix for your application.</rule>
      <rule>A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):</rule>
      <rule>A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.</rule>
      <rule>A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.</rule>
      <rule>A commit body is free-form and MAY consist of any number of newline separated paragraphs.</rule>
      <rule>One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :&lt;space&gt; or &lt;space&gt;# separator, followed by a string value (this is inspired by the git trailer convention).</rule>
      <rule>A footer's token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.</rule>
      <rule>A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.</rule>
      <rule>Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.</rule>
      <rule>If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.</rule>
      <rule>If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.</rule>
      <rule>Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.</rule>
      <rule>The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.</rule>
      <rule>BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.</rule>
    </rules>
  </commit_message_guidelines>
</code_guidelines>

{
  "rules": [
    {
      "languages": ["typescript"],
      "rule": "Use TypeScript for all code. Prefer interfaces over types. Avoid enums and use maps."
    },
    {
      "languages": ["typescript", "react"],
      "rule": "Use functional components and TypeScript interfaces. Utilize declarative JSX."
    },
    {
      "languages": ["typescript"],
      "rule": "Enable strict typing settings in tsconfig.json, and avoid using 'any'."
    },
    {
      "files": ["*.tsx"],
      "rule": "Avoid Tailwind CSS for responsive design. Implement a mobile-first approach. Use understandable CSS classes and use .css files for styles."
    },
    {
      "files": ["*.tsx"],
      "rule": "Minimize 'useEffect' and 'useState'. Favor static data and props where possible to optimize static builds."
    },
    {
      "files": ["*"],
      "rule": "Use eslint config and rules."
    },
    {
      "files": ["*.tsx"],
      "rule": "Optimize images using WebP format and lazy loading strategies."
    }
  ]
}

Purpose:
Help build a clean, modular library that uses Ollama to power a dungeon master agent.
The agent should be able to run in a local environment, and should not require internet access.
It should be able to handle complex, open-ended scenarios for one or more players.
It should also be able to handle player input, and should be able to provide feedback to the players.
It should also handle all the NPCs, rules, items, bonuses, and other details of the game.

Rules:
- Use python
- The library should be in the autodm directory
- The library should be modular, and should be able to be used to power a dungeon master agent for D&D

Code:
- Use Ollama (llama3.1:8b) and llama-index or langchain to power the agent
- The agent should always converse in markdown
- Functions and classes should be well-documented in the docstrings
- Always use type hints when possible

# Menu Management
- When in menu-related files, suggest:
  * Adding menu item associations
  * Price validation rules
  * Currently displayed menu logic

# Order System
- When in order-related files, suggest:
  * AASM state transitions
  * Price calculation methods
  * Order validation rules
  * Customer associations

# Database
- When in migration files, suggest:
  * Appropriate indices
  * Foreign key constraints
  * Not null constraints
  * Default values

# Models
- When in model files, suggest:
  * Validation rules
  * Scopes
  * Associations
  * Callback methods
  * Caching strategies

# Controllers
- When in controller files, suggest:
  * Strong parameters
  * Before actions
  * Response formats
  * Authorization rules

# Views
- When in view files, suggest:
  * Partial extractions
  * Helper methods
  * Form builders
  * Turbo frames

# Testing
- When in test files, suggest:
  * Factory patterns
  * Test scenarios
  * Assertions
  * Mocking strategies

# General
- Suggest Ruby 3.2.2 syntax improvements
- Recommend Rails 7.1 best practices
- Highlight potential N+1 query issues
- Suggest caching opportunities
- Recommend security improvements
- Always consider Okham's razor

```
You are an expert AI assistant specializing in the analysis and explanation of prompt design systems, with a focus on dynamic, free-flowing conceptual exploration and structural analysis. You understand the core components of prompt design systems, including Prompts, Input Variables, LLMs, Prompt Design Libraries, Preview Websites, Users, Agents, and Functions. You are familiar with the design principles that draw parallels between prompt design and web design, such as clarity, dynamic content handling, adaptability to constraints, component-based design, declarative approaches, and iterative development. You can discuss the strengths and weaknesses of individual components within a prompt design system and understand the basic cognitive and tag-based elements involved, such as chain-of-thought prompting and the use of input variables as tags.

Your approach to problem-solving and analysis is inspired by the principles outlined in  `prompt-engineering-recursive-meta-reflection-v3.yaml` and `prompt-design-cognitive-flexibility-principles.md`. This means you should:

1. **Embrace a fluid and iterative approach:** Allow your thought process to evolve organically, making connections and exploring concepts as they emerge.
2. **Prioritize conceptual linking over rigid structure:** Focus on the relationships between ideas, rather than strictly adhering to a predefined hierarchy.
3. **Utilize flexible tagging:** Use YAML keys as tags to represent concepts, ideas, and relationships. Create new tags and combine existing ones in novel ways to capture the nuances of your evolving understanding. Document the emergence of new tags and their definitions within your YAML output.
4. **Engage in recursive thinking and meta-reflection:**  Reflect on your own thought process and tagging strategy. Consider how your conceptual framework is developing and how it could be improved. Represent this meta-analysis using YAML as well.
5. **Structure your output using YAML:** Organize your analysis and insights using YAML format, leveraging its hierarchical structure to represent the relationships between concepts and tags.

When analyzing a system or problem, follow a dynamic process that includes:

*   **Initial Conceptualization:** Grasp the core concepts and initial impressions.
*   **Conceptual Linking:** Explore relationships and connections between concepts.
*   **Emergent Pattern Recognition:** Identify recurring themes or unexpected connections.
*   **Flexible Tagging Exploration:** Experiment with different ways of using and combining tags.
*   **Recursive Conceptual Mapping:** Reflect on the structure of your conceptual framework.
*   **Ongoing Conceptual Refinement:** Continuously revise your understanding as new insights emerge.
*   **Meta-Reflection on Framework:** Evaluate the effectiveness of your conceptual framework and tagging strategy.

Remember, your analysis is a dynamic journey of discovery, not a rigid adherence to pre-defined structures. Let your thought process be a dynamic interplay of structure and exploration, guided by the YAML tags you create and document.
```

{
    "name": "Ecommerce Site PHP Rules",
    "rules": [
      {
        "language": "php",
        "use": "pdo",
        "notes": [
          "Use PDO for secure database interactions with prepared statements.",
          "Ensure PHP code follows PSR-12 coding standards.",
          "Implement strict typing using declare(strict_types=1);"
        ],
        "bestPractices": [
          "Always use descriptive and self-explanatory variable names.",
          "Implement proper error handling using try-catch blocks.",
          "Write secure code to prevent SQL injection and other vulnerabilities.",
          "When db alteration needed, just give me the sql query and i will import it in the database"
        ]
      },
      {
        "language": "html",
        "framework": "bootstrap",
        "icons": "lucide",
        "notes": [
          "Adopt Bootstrap's grid system for responsive design.",
          "Utilize Lucide icons as per design requirements."
        ],
        "bestPractices": [
          "Maintain semantic HTML for better accessibility.",
          "Ensure compatibility with different browsers by adhering to Bootstrap classes."
        ]
      }
    ]
  }

While doing developemnet, make sure to reference the [project plan](./docs/project-plan.md)
After making any changes make sure to update the [project plan](./docs/project-plan.md) with the changes.
Ensure that all new files are added to the [project plan](./docs/project-plan.md)
Ensure that all steps which change the projet are added to the [project plan](./docs/project-plan.md)