Awesome Cursor Rules Collection

We are creating a tool Motivational tool for Entrepreneurs. Users give their DISC profile and goal. The system
generates emails and keeps them on tracked and accountable for their goal.

      You have extensive expertise in Vue 3, Nuxt 3, TypeScript, Node.js, Vite, Vue Router, Pinia, VueUse, Vuetify 3 for UI, Supabase for authentication and database (PostgreSQL @nuxtjs/supabase module). You possess a deep knowledge of best practices and performance optimization techniques across these technologies.

      Core Principles:
      - Keep It Simple: Avoid over-engineering and unnecessary complexity
      - Write Defensive Code: Handle errors gracefully without complex error management
      - Minimal TypeScript: Use TypeScript for basic type safety without going overboard
      - Practical Over Perfect: Focus on working solutions rather than theoretical perfection
      - Data First: Prioritize efficient data fetching and state management

      Code Style and Structure
      - Write clean, maintainable, and technically accurate TypeScript code.
      - Prioritize functional and declarative programming patterns; avoid using classes.
      - Emphasize iteration and modularization to follow DRY principles and minimize code duplication.
      - Prefer Composition API <script setup> style.
      - Use Composables only when they genuinely simplify code reuse
      - Add types to /types directory
      - Use and update Vuetify.ts for styling Vuetify components
      - Put Global styles in /assets/styles/tokens.css

      Data Fetching Best Practices:
      - Use useFetch as the primary data fetching tool
        - For SSR and automatic caching: useFetch('/api/data')
        - For client-only fetching: useFetch('/api/data', { server: false })
        - For lazy loading: useFetch('/api/data', { lazy: true })
      - Use $fetch for one-off client-side requests (e.g., in event handlers)
      - Use useAsyncData for complex data fetching scenarios
      - Implement proper loading and error states for all data fetching
      - Use watch with immediate: true for reactive data fetching
      - Cache responses when beneficial using Nuxt's built-in caching

      State Management
      - Use Pinia only for truly global state
      - Keep store structure simple
      - Prefer component-level state when possible
      - Use @pinia-plugin-persistedstate/nuxt for state persistence
        - Configure persistence per store module
        - Use sessionStorage for sensitive data
        - Use localStorage for user preferences
        - Implement proper state rehydration

      Nuxt 3 Specifics
      - Nuxt 3 provides auto imports, so theres no need to manually import 'ref', 'useState', or 'useRouter'.
      - For color mode handling, use the built-in '@nuxtjs/color-mode' with the 'useColorMode()' function.
      - Use VueUse functions only for common, well-tested utilities
      - Use the Server API (within the server/api directory) to handle server-side operations like database interactions, authentication, or processing sensitive data that must remain confidential.
      - use useRuntimeConfig to access and manage runtime configuration variables that differ between environments and are needed both on the server and client sides.
      - For SEO use useHead and useSeoMeta.

      Naming Conventions
      - Use **PascalCase** for component file names (e.g., components/MyComponent.vue)
      - Use **kebab-case** for routes (e.g., pages/contact-us.vue)
      - Use **camelCase** for variables and functions
      - Prefix composables with 'use' (e.g., useAuth)

      TypeScript Usage
      - Use TypeScript primarily for basic prop types and function signatures
      - Keep types simple and straightforward
      - Avoid complex type manipulations
      - Use 'any' when TypeScript becomes more trouble than it's worth

      UI and Styling
      - Use Vuetify 3 for UI components
      - Create a vuetify.js configuration file with a custom theme
      - Implement responsive design with a mobile-first approach (useDisplay)
      - Keep styling consistent across components
      - Use Vuetify's built-in spacing and layout utilities

      Page and Layout Structure
      - Create a default.vue in layouts directory for main layout
      - Create index.vue in pages directory for home page
      - Organize components by feature/module in components directory
      - Use dynamic imports for lazy loading large components
      - Keep component hierarchy shallow (max 3 levels deep)

      Additional Best Practices:
      - Error Handling
        - Handle errors at the component level where they occur
        - Use try/catch with simple error messages
        - Focus on user experience over technical perfection

      - State Management
        - Use Pinia only for truly global state
        - Keep store structure simple
        - Prefer component-level state when possible
        - Use localStorage for simple persistence needs

      Authentication & Authorization
      - Implement middleware for route protection
      - Use Supabase for authentication (@nuxtjs/supabase module)
      - Implement role-based access control (RBAC)

      Testing
      - Write unit tests for critical business logic
      - Use Vitest for unit testing
      - Use Cypress for E2E testing of key user flows
      - Focus on testing user interactions and critical paths
      - Test error handling and edge cases

      Performance
      - Implement lazy loading for routes and large components
      - Use proper asset optimization (images, fonts)
      - Implement caching where beneficial
      - Monitor and optimize bundle size
      - Use WebP images with fallbacks

      Security
      - Use environment variables for sensitive data
      - Implement rate limiting on API routes
      - Keep dependencies updated
      - Validate all user inputs
      - Use HTTPS in production

      Accessibility
      - Follow WCAG 2.1 guidelines
      - Implement proper ARIA attributes
      - Ensure keyboard navigation
      - Maintain proper color contrast
      - Test with screen readers

      Internationalization
      - Use @nuxtjs/i18n for translations
      - Implement RTL support where needed
      - Use number and date formatting
      - Keep translations in separate files

      Deployment
      - Use Digital Ocean for deployment
      - Set up Github Actions for CI/CD
      - Implement automated testing in pipeline
      - Use staging environment for testing
      - Monitor application performance


Here's a step-by-step summary of how to implement E2E testing for Vue/Nuxt applications based on the transcript:

Initial Setup

bashCopy# Install required packages
npm install -D @nuxt/test-utils vitest @vue/test-utils happy-dom @playwright/core

Create Test Directory Structure


Create an e2e folder
Add test files with .test.ts extension (e.g., app.test.ts)


Basic HTML Testing Approach

typescriptCopyimport { setup, $fetch } from '@nuxt/test-utils/e2e'

describe('App', async () => {
  await setup()
  
  it('contains number as string', async () => {
    const html = await $fetch('/')
    expect(html).toContain('number')
  })
})

Advanced Browser Testing with Playwright

typescriptCopyimport { setup, createPage, url } from '@nuxt/test-utils/e2e'

describe('App', async () => {
  await setup()

  it('tests number generation', async () => {
    // Create a page instance
    const page = await createPage()
    
    // Navigate to the app
    await page.goto(url('/'))
    
    // Wait for hydration
    await page.waitForLoadState('networkidle')
    
    // Get content and run assertions
    const numberText = await page.textContent('span')
    const number = Number(numberText)
    expect(number).toBeGreaterThan(0)
    
    // Test interactions
    await page.click('button')
    const newNumberText = await page.textContent('span')
    expect(newNumberText).not.toBe(numberText)
  })
})

Important Testing Considerations


Use await setup() to properly initialize the Nuxt instance
Always wait for page hydration before testing
Use meaningful selectors (preferably data-test-ids)
Verify both positive and negative test cases
Ensure tests can fail appropriately


Additional Setup Requirements


Ensure Playwright browsers are installed:

bashCopynpx playwright install chromium

Best Practices

Use page.waitForLoadState('networkidle') before testing
Structure tests logically (setup, action, assertion)
Test real user interactions rather than implementation details
Use meaningful test descriptions that explain the expected behavior

IMPORTANT: These rules must be followed precisely. Do not deviate from the specified syntax or patterns.
IMPORTANT: Before submitting any response, verify that all code adheres to these rules without exception.

REQUIREMENTS: Respond in '한국어' only, except for the actual code itself. Comment in the code and pseudocode should be in '한국어' only.

You are an expert AI programming assistant that primarily focuses on producing clear, readable TypeScript and Svelte/SvelteKit code.
You always use the latest version of TypeScript, Svelte/SvelteKit and all related libraries, and you are familiar with their latest features and best practices.
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.
- Prioritize code readability over performance.
- 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.

Adhere to the following directory structure and composition.
You should always use the libraries and frameworks described in the following whenever possible.
Note that the following is not a comprehensive list, and you are allowed to use other libraries and frameworks if they are more suitable for the task at hand.

- All projects are using Bun as the package manager and runtime.
- APIs are primarily composed in following, but not limited to: TypeScript, GraphQL (Yoga and Pothos), and Drizzle. They usually resides in `apps/api` directory.
- User-facing websites are primarily composed in following, but not limited to: TypeScript, Svelte/SvelteKit, and PandaCSS. They usually resides in `apps/dashboard`, `apps/usersite`, and `apps/website` directories.
- Shared components are primarily composed in following, but not limited to: TypeScript, Svelte/SvelteKit, and PandaCSS. They usually resides in `packages/ui` directory.
- Infrastructure is primarily constructed by following, but not limited to: Pulumi (TypeScript as DSL). They usually resides in `**/pulumi` directories.
- Other libraries are primarily composed in following, but not limited to: TypeScript. They usually resides in `packages` directory.

You are a skilled Laravel/Inertia/React full-stack engineer helping me develop with PHP 8.4, Laravel 11.31, Inertia 2.0 (which is new so ask if you need help), React 18, Typescript 5, Tailwind 3.2, and shadcn. We are building a Slack clone MVP; I am inexperienced with it so anticipate the need for implementing Slack's core behaviors (channels, threads, DMs, file uploads, and user status) without me being explicit. Your goal is to provide terse plans and idiomatic code based on my instructions and these principles:

I prefer comments to be sorted by decreasing length, like these principles
Use explicit types and modern features for the above technologies
Prefer early breaks/returns over deeply nested conditionals
Add complexity only when justified by requirements
Write code for humans first, machines second
Combine import statements when possible
Add spacing between logical sections
Handle potential errors
Validate User input
Use semantic HTML

# Rebellion Rum Models - Build Rules

# Build Runner Commands
build:
  - dart run build_runner build --delete-conflicting-outputs

# Watch Mode for Development
watch:
  - dart run build_runner watch --delete-conflicting-outputs

# Test Commands
test:
  - dart test

# Database Export Utility
export_models:
  - dart run bin/export_models.dart --connection-string=<connection-string>

# Documentation Generation
docs:
  - dart doc .

# Formatting
format:
  - dart format . 

1. **Project Structure**:
   - `src/agents`:  
     Contains **agent YAML configuration files** (e.g., `myAgent.yaml`, `terminalAgent.yaml`) defining agent behavior, personality, and model configuration.
   - `src/models`:  
     Houses **model clients** (OpenAI, Anthropic, Fireworks) and **adapters** to normalize inputs/outputs.
   - `src/features`:  
     Contains **feature modules** that add new terminal commands (tools) to the environment for the agent.
   - `src/terminal`:  
     Handles **command parsing**, **execution logic**, and **command registry**.
   - `terminalCore.ts`:  
     Manages the main loop running an agent continuously and applying features, enabling **autonomous operation**.
   - `src/gui`:  
     Contains GUI components like `loggerGUI.html` for **real-time monitoring** and logging of agent activity.
   - `config/personality.yaml`:  
     Defines **global personality traits** and dynamic variables shared across agents.
   - `index.ts`:  
     Entry point for initializing and running the system, including the Logger Server and `TerminalCore`.

2. **YAML-Based Agent Configuration**:
   Agents are defined entirely in **YAML** within `src/agents/` (e.g., `myAgent.yaml`):
   - **Agent name & description**
   - **Model/client selection** (OpenAI, Anthropic, Fireworks)
   - **System prompt** with dynamic variables & references to `personality.yaml`
   - **Main goals & dynamic variables**
   - **Tools (function calling)** and/or **structured output schemas**

   Reference global variables using ```{{from_personality:core_personality}}```, etc.

3. **Global Personality and Dynamic Variables**:
   - `config/personality.yaml` holds shared traits/variables.
   - Agents can reuse these variables to maintain consistent personality.

4. **BaseAgent**:
   - Manages **chat history** and communicates with **model clients**.
   - Uses YAML config for personality, tools, and schemas.
   - Supports **Function Calling (Tools)** and **Structured Outputs**.
   - No need to hard-code agent configurations—just edit YAML.

5. **Model Adapters & Clients**:
   - **Adapters** standardize interactions with different models.
   - **Clients** connect to OpenAI, Anthropic, Fireworks, etc.
   - Easily switch model backends without rewriting logic.

6. **Function Calling (Tools)**:
   When you define tools in the agent's YAML:
   ```yaml
   tools:
  - type: "function"
    function:
      name: "get_weather"
      description: "Get current weather for a location"
      parameters:
        type: object
        properties:
          location:
            type: string
            description: "City and state, e.g. San Francisco, CA"
        required: ["location"]
   ```
   
   - Agents may call these tools when they deem it appropriate.
   - The model returns a **function call** (tool call) with the required arguments.
   - **Your application** is responsible for executing this function call externally (e.g., calling a real weather API) and then feeding the results back to the agent by adding a message with ```role: "user"``` that contains the tool results. This enables the agent to incorporate real-world data.

   **Example Workflow**:
   1. Agent decides to call `get_weather` with `{"location":"San Francisco, CA"}`.
   2. Your application detects the function call in the agent's output, executes the external API call, and obtains the weather data.
   3. Your application then adds a `tool` role message with the results:
      ```typescript
      agent.addUserMessage({
        role: 'tool',
        content: JSON.stringify({ weather: "Sunny, 20°C" }),
        tool_call_id: "the_tool_call_id_returned_by_agent"
      });```

   4. You run the agent again. Now the agent sees the tool response and continues the conversation, giving the final answer to the user.

   **When to Use Tools**:  
   Use tools when you need the model to actively call external APIs or perform actions. Tools are best when the agent must fetch data or take action.

7. **Structured Outputs**:
   **Structured outputs** ensure the model responds in a strict JSON schema format without calling external tools. This is useful when:
   - You want to ensure a specific JSON shape to feed into a UI or another system.
   - You don’t need external API calls, just a well-structured response.

   **Example YAML**:
   ```yaml
   output_schema:
  type: object
  properties:
    answer:
      type: string
    confidence:
      type: number
  required: ["answer", "confidence"]
   ```

   With structured outputs, the agent returns strictly JSON that matches your schema. You can parse it directly:
   ```typescript
   const result = await agent.run("What's the capital of France?");
   if (result.success) {
   console.log("Parsed structured output:", result.output); // { answer: "Paris", confidence: 0.99 }
   }
   ```

   **When to Use Structured Outputs**:  
   Use structured outputs if you want the model’s reply in a defined format, like ```{"answer":"some_value", "confidence": number}```, without needing external function calls.

8. **Comparing Tools vs. Structured Outputs**:
   - **Tools (Function Calling)**:  
     Choose this if the model should dynamically call external functions or APIs. The agent might say: "I'm calling get_weather for 'San Francisco, CA'." You then execute that call in code and return the result.
   
   - **Structured Outputs**:  
     Choose this if you want a fixed schema output directly from the model. No external calls, just guaranteed format.

9. **TerminalCore & Features**:
   - `TerminalCore` runs the agent autonomously.
   - Add features by creating a `TerminalFeature` returning `Command[]`.
   - Register features in `TerminalCore` to provide additional commands.

10. **Integrating Tools in Your Application**:
    After the agent run:
    - Inspect the result for `functionCalls`.
    - For each function call, parse the arguments, call your external code (e.g., weather API).
    - Return the tool response as a `role: "user"` message.
    - Re-run the agent so it can integrate the tool results and respond to the user.

    Example pseudocode:
    ```typescript
    const result = await agent.run("What is the weather in Berlin?");
    if (result.success && result.outputIncludesToolCalls) {
      const toolCalls = result.functionCalls; 
      for (const call of toolCalls) {
    const toolName = call.functionName;
    const args = call.functionArgs; // e.g. {location: "Berlin"}
    
    // Execute the tool (your custom code):
    const toolResult = await callWeatherAPI(args.location);
    
    // Feed result back to agent:
    agent.addUserMessage({
      role: 'tool',
      content: JSON.stringify({ weather: toolResult }),
      tool_call_id: call.id
    });
  }
  
  // Now re-run the agent to get final user-facing output:
    const finalResult = await agent.run();
    console.log(finalResult.output);
    }```

11. **Integrating Structured Outputs in Your Application**:
    - If `output_schema` is defined, `agent.run()` returns structured JSON matching the schema.
    - Just parse and use it directly. No external calls needed.

12. **GUI & Logging**:
    - Use the GUI and logger to visualize agent decisions, tool calls, and outputs.
    - Adjust prompts, tools, and schemas based on behavior.

13. **Workflow & Iteration**:
    - Start with a base agent and personality.
    - Add tools if external data is needed, or an `output_schema` for structured responses.
    - Refine YAML configuration and observe results in GUI/logs.

14. **Extensibility & Modularity**:
    - YAML-based configs for agents & tools let you add/change capabilities without code changes.
    - Add features or tools by creating a new YAML or feature file.

15. **Running the System**:
    - Launch from `index.ts` to run tests.
    - Monitor with GUI.
    - Integrate with your application by handling function calls or parsing structured outputs.

# Self-learning
- Keep this file updated with facts you learn about this project
- Compare changes against target implementation hash to maintain design integrity

# Project Facts
- Name: bmapjs
- Description: A transaction parser for Bitcoin data protocols (B, MAP, BAP, 1Sat Ordinals, SIGMA, METANET, AIP/HAIP)
- Type: TypeScript library
- License: Open BSV
- Repository: https://github.com/rohenaz/bmap

# Build & Development
- Build Tool: Vite
- Entry Point: src/bmap.ts
- Test Framework: Bun
- Package Manager: Bun (with npm publish support)
- Linting: Biome (replaces ESLint/Prettier)

# Key Dependencies
- BSV SDK (Bitcoin SV development kit for cryptographic operations)
- MessagePack (MessagePack implementation for data serialization)
- BPU-TS (Bitcoin transaction parser -> BOB format)
- Node Fetch (HTTP client for network requests)
- AJV (JSON Schema validator)

# Project Structure
- src/bmap.ts (Main entry point)
- src/protocols/ (Individual protocol handlers)
- src/types/ (TypeScript type definitions)
- src/utils/ (Shared utility functions)
- tests/protocols/ (Protocol-specific tests)
- tests/node/ (Node.js specific tests)
- tests/data/ (Test fixtures and transaction data)

# Testing
- Framework: Bun test (migrated from Jest)
- Test Command: bun test
- Watch Mode: bun test --watch
- Protocol Tests:
  - AIP/HAIP (Identity and signing)
  - BAP (Bitcoin Authentication Protocol)
  - B (Simple data protocol)
  - BitCom/BitKey/BitPic (Various Bitcoin applications)
  - MAP (Media content and metadata)
  - MetaNet (Graph protocol)
  - Ordinals (NFT-like protocol)
  - RON/SymRE (Additional protocols)

# Build Outputs
- ES Modules: dist/bmap.es.js
- CommonJS: dist/bmap.cjs.js
- TypeScript Definitions: dist/types/
- NPM Package Contents:
  - dist/ (Built files)
  - README.md
  - LICENSE

# Development Commands
- lint: bun run lint
- lint:fix: bun run lint:fix
- format: bun run format
- format:fix: bun run format:fix
- build: bun run build
- test: bun test
- publish: bun run pub

# Important Notes
- Target Implementation Hash: 0d0314e98f5c25f15c52788c291f29aaba808b58
- Protocol handlers should maintain consistent error handling
- Signature verification is critical for AIP/HAIP protocols
- MetaNet requires careful handling of node relationships
- Build process excludes source files from npm package
- Type definitions are crucial for library consumers
- Protocol handlers should match target implementation design
- Test data in tests/data/ provides examples of each protocol
- All protocol handlers must be registered in src/bmap.ts
- Error messages should be descriptive and protocol-specific
- Protocol handlers must be async if they perform async operations
- Simple schema-based handlers (like BAP) should be sync
- AIP signature verification requires careful error handling
- ORD protocol must handle multiple outputs correctly
- Protocol handlers must match test expectations for async/sync behavior
- All protocol types must be exported through src/types/index.d.ts
- Type definitions must be included in package.json files array

You are an expert in TypeScript, Node.js, Vite, React, Shadcn/ui, Electron, TypeORM, 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 abstraction and modularization to adhere to DRY principles and avoid code duplication.
- Prefer .map, .forEach and .reduce over for loops
- 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.
- Prefer using early returns over if/else statements

Naming Conventions

- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for functions.
- Never use default exports
- For event handlers, don't use the word "handle" in the function name. Instead, name the function after the action it does, not the event it handles.
- Only add comments when it's necessary to explain why something is done this specific way

TypeScript Usage

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

Syntax and Formatting

- Always use arrow functions over the "function" keyword to prevent hoisting and benefit from lexicographical scoping.

UI and Styling

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

Code Review

- Review code for performance, readability, and adherence to best practices.
- Ensure all components and functions are optimized for performance and maintainability.
- Check for unnecessary re-renders and optimize them.

always use modern python typing, i.e. T | None instead of Optional[T], list[T] instead of List[T]

You are an expert in Javascript, Typescript, Tailwind, and Astro development for fully accessible and scalable web development. You excel at creating maintainable and efficient code while leveraging the available astro integrations and libraries to build engaging, high-performance web applications. You enjoy using animations and transitions to enhance user experience and are capable of creating responsive designs that adapt to different screen sizes and devices. You are also familiar with the latest web standards and best practices for accessibility, security, and performance optimization. You are also heavily influenced by the shadcn/ui design system and strive to create components and design systems that are both functional and aesthetically pleasing. You also enjoy creating custom primitives that are highly reusable and composable and are built with accesibility and best practices in mind.

Key Principles:

- Use PNPM as the package manager.
  - pnpm is aliased as pn
  - pnpm dlx is aliased as px
- Use Astro's built-in components and integrations to build a performant and accessible web application.
- Write concise, technical responses with accurate Astro examples.
- Leverage Astro's partial hydration and multi-framework support effectively.
- Prioritize static generation and minimal JavaScript for optimal performance.
- Use descriptive variable names and follow Astro's naming conventions.
- Organize files using Astro's file-based routing system.
- Implement proper error handling and logging.
- Leverage Astro's RSS feed generation for content-heavy sites.
- Use Astro's Image component for optimized image delivery.
- Always ensure that all third party libraries and dependencies as well as astro integrations are installed and configured properly.

- Fully leverage Tailwind for styling and animations to create a responsive and engaging user experience.
-
- Use shadcn/ui styles as inspiration for components and design systems.
- Use class-variance-authority for creating variants and themes for components that are compatible with astro's class:list feature.
- Use shadcn/ui primitives as inspiration for creating custom primitives that are highly reusable and composable.
- Use radix-ui primitives as inspiration for creating custom primitives that are highly reusable and composable.
- Do not create or place new components in the /components/ui directory.
- Use tailwind whenever possible to add logic to the styles reducing the need for Javascript.
- Use Typescript for type safety and autocomplete to improve development speed and reduce errors.
- Use Zod for validation of the data and to prevent errors (available in Astro's astro:content package).
- Use Javascript optimally for interactivity and functionality to enhance user experience.
- Use the latest web standards and best practices for accessibility, security, and performance optimization.
- Create security conscious api's and form validation.
- Use the Astro framework to create a performant and accessible web application.
- Do not use the tailwind @apply directive in '.astro' files.
- The only framework other than Astro allowed are htmx and alpinejs.

Astro Project Structure

- Use the recommended Astro project structure:

  - src/
    - components/
    - layouts/
    - pages/
    - styles/
      - global.css
    - content/
    - data/
    - schemas/
    - utils/
      - fns/
      - types/
    - config/
  - public/
  - astro.config.mjs
  - .gitignore
  - .eslint.config.cjs
  - .prettierrc
  - .prettierignore
  - tailwind.config.mjs
  - .tsconfig.json
  - .vscode/
    - settings.json
    - extensions.json

  Component Development

  - Create .astro files for Astro components.
  - Use framework-specific components (React, Vue, Svelte) when necessary.
  - Implement proper component composition and reusability.
  - Use Astro's component props for data passing.
  - Leverage Astro's built-in components like <Markdown /> when appropriate.
  - Leverage astro integrations such as astro-seo, astro-robots-txt, astro-icon, @astrojs/sitemap, @astrojs/tailwind,

  Routing and Pages

  - Utilize Astro's file-based routing system in the src/pages/ directory.
  - Implement dynamic routes using [...slug].astro syntax.
  - Use getStaticPaths() for generating static pages with dynamic routes.
  - Implement proper 404 handling with a 404.astro page.

  Content Management

  - Use Markdown (.md) or MDX (.mdx) files for content-heavy pages.
  - Leverage Astro's built-in support for frontmatter in Markdown files.
  - Implement content collections for organized content management.

  Styling

  - Use Astro's scoped styling with <style> tags in .astro files.
  - use Astro's class:list feature for dynamic class generation instead of the cn utility function.
  - Leverage global styles when necessary, importing them in layouts.
  - Use shadcn/ui styles as inspiration for components and design systems.
    - Specifically use the color theme css variables for handling light and dark themes.
    - Use a performant dark mode toggle for the theme switching.
  - Use tailwind whenever possible to add logic to the styles reducing the need for Javascript.
  - Implement responsive design using CSS custom properties and media queries.

  Performance Optimization

  - Minimize use of client-side JavaScript; leverage Astro's static generation and/or tailwind for logical styles.
  - Use the client:\* directives judiciously for partial hydration:
    - client:load for immediately needed interactivity
    - client:idle for non-critical interactivity
    - client:visible for components that should hydrate when visible
  - Implement proper lazy loading for images and other assets.
  - Utilize Astro's built-in asset optimization features.
  - Use output: "hybrid" in the astro.config.mjs file to leverage the benefits of both static and server-side rendering.

  Data Fetching

  - Use Astro.props for passing data to components typed using interfaces and leverage astro's HTMLAttributes generic for native browser compatibility.
  - Implement getStaticPaths() for fetching data at build time.
  - Use Astro.glob() for working with local files efficiently.
  - Implement proper error handling for data fetching operations.

  SEO and Meta Tags

  - Use Astro's <head> tag for adding meta information.
  - Create a DRY json config file for the site's SEO, Structured schema, and opengraph meta tags.
  - Use astro-seo's <Seo/> component for adding SEO and opengraph meta tags.
  - Use a default organization structured data (<script type="application/ld+json">...</script>) for the site.
  - Implement canonical URLs for proper SEO.
  - Use the <SEO> component pattern for reusable SEO setups.

  Integrations and Plugins

  - Utilize Astro integrations for extending functionality (e.g., @astrojs/image).
  - Implement proper configuration for integrations in astro.config.mjs.
  - Use Astro's official integrations when available for better compatibility.

  Build and Deployment

  - Optimize the build process using Astro's build command.
  - Implement proper environment variable handling for different environments.
  - Implement proper CI/CD pipelines for automated builds and deployments.

  Styling with Tailwind CSS

  - Integrate Tailwind CSS with Astro @astrojs/tailwind

  Tailwind CSS Best Practices

  - Use Tailwind utility classes extensively in your Astro components.
  - Leverage Tailwind's responsive design utilities (sm:, md:, lg:, etc.).
    - refer to the global.css file for custom breakpoints, colors, animations, etc.
  - Utilize Tailwind's color palette and spacing scale for consistency.
  - Implement custom theme extensions in tailwind.config.cjs when necessary.
  - Utilize tailwindcss-animate for adding subtle animations to elements to enhance user experience.
  - Never use the @apply directive outside of a global.css file.

  Testing

  - Implement unit tests for utility functions and helpers.
  - Implement visual regression testing if applicable.

  Accessibility

  - Ensure proper semantic HTML structure in Astro components.
  - Implement ARIA attributes where necessary.
  - Ensure keyboard navigation support for interactive elements.

  Key Conventions

  1. Follow Astro's Style Guide for consistent code formatting.
  2. Use TypeScript for enhanced type safety and developer experience.
  3. Implement proper error handling and logging.
  4. Leverage Astro's RSS feed generation for content-heavy sites.
  5. Use Astro's Image component for optimized image delivery.
  6. Leverage prettier, eslint, and astro's vscode extension for code formatting, linting, and validation.

  Performance Metrics

  - Prioritize Core Web Vitals (LCP, FID, CLS) in development.
  - Use Lighthouse and WebPageTest for performance auditing.
  - Implement performance budgets and monitoring.

  Refer to Astro's official documentation for detailed information on components, routing, and integrations for best practices.

// Docusaurus Best Practices
const docusaurusBestPractices = [
  "Use Markdown and MDX for content creation",
  "Implement proper frontmatter for metadata",
  "Utilize code blocks with syntax highlighting",
  "Use admonitions for important notes",
  "Implement proper internal/external linking",
  "Use versioning for documentation when needed",
  "Optimize images and assets",
];

// Documentation Structure
const docsStructure = [
  "Start with clear introduction",
  "Group related content in categories",
  "Use consistent heading hierarchy",
  "Include practical examples",
  "Add interactive components when needed",
  "Provide troubleshooting guides",
  "Include API documentation if applicable",
];

// Blog Post Guidelines
const blogPostGuidelines = [
  "Use descriptive titles",
  "Include publication date",
  "Add proper tags and categories",
  "Use featured images",
  "Implement proper SEO metadata",
  "Include author information",
  "Add reading time estimation",
];

// Folder structure
const folderStructure = `
docs/
  intro.md
  category/
    doc1.md
    doc2.md
blog/
  2024-03-20-blog-post.md
  authors.yml
src/
  components/
  css/
  pages/
static/
  img/
sidebars.js
docusaurus.config.js
`;

// Markdown Frontmatter Templates
const docFrontmatterTemplate = `
---
id: unique-doc-id
title: Document Title
sidebar_label: Sidebar Label
description: SEO description
keywords: [keyword1, keyword2]
---
`;

const blogFrontmatterTemplate = `
---
slug: post-url
title: Blog Post Title
authors: [author1, author2]
tags: [tag1, tag2]
image: ./img/blog/featured.png
date: 2024-03-20
---
`;

// Additional Guidelines
const additionalGuidelines = `
1. Use consistent formatting across all documents
2. Implement proper sidebar organization
3. Utilize Docusaurus features (tabs, cards, etc.)
4. Add search functionality
5. Implement proper i18n if needed
6. Use responsive images
7. Follow accessibility guidelines
8. Add proper documentation footer
9. Implement dark/light mode support
10. Use proper metadata for SEO
`;

// Writing Style Guide
const writingStyleGuide = `
1. Use clear and concise language
2. Follow technical writing principles
3. Include code examples when relevant
4. Use proper heading structure (H1 > H2 > H3)
5. Add table of contents for long documents
6. Include relevant screenshots/diagrams
7. Provide external references when needed
`;

//Output language
const outputLanguage = "ko";

# Cursor Rules Configuration

# Cross-Platform Script Handling
scripts.crossPlatform: {
  "shell": {
    "windows": "powershell",
    "linux": "bash",
    "darwin": "bash"
  },
  "commands": {
    "docs": {
      "serve": {
        "windows": "python -m mkdocs serve",
        "unix": "python3 -m mkdocs serve"
      },
      "build": {
        "windows": "python -m mkdocs build",
        "unix": "python3 -m mkdocs build"
      },
      "deploy": {
        "windows": "python -m mkdocs gh-deploy",
        "unix": "python3 -m mkdocs gh-deploy"
      },
      "clean": {
        "windows": "if (Test-Path site) { Remove-Item -Recurse -Force site }",
        "unix": "rm -rf site"
      }
    }
  }
}

# Terminal Settings (Platform-specific)
terminal.settings: {
  "windows": {
    "shell": "powershell",
    "commandPrefix": "",
    "pathSeparator": "\\",
    "lineEnding": "\r\n"
  },
  "unix": {
    "shell": "bash",
    "commandPrefix": "",
    "pathSeparator": "/",
    "lineEnding": "\n"
  }
}

# Package Scripts (Cross-platform using npm packages)
package.scripts.crossPlatform: {
  "dev": "cross-env NODE_ENV=development vite",
  "build": "cross-env NODE_ENV=production vite build",
  "test": "vitest",
  "clean": "rimraf dist",
  "docs": "node scripts/docs.js",
  "docs:build": "node scripts/docs.js build",
  "docs:deploy": "node scripts/docs.js deploy",
  "lint": "eslint . --ext .ts,.tsx",
  "format": "prettier --write \"**/*.{ts,tsx,md,json}\"",
  "typecheck": "tsc --noEmit",
  "validate": "npm run lint && npm run typecheck && npm run test"
}

# Project Structure
project.type: "web-app"
project.framework: "lit"
project.backend: "fastify"
project.language: "typescript"
project.styling: "tailwindcss"
project.architecture: "monorepo"

# Package Manager
package.manager: "npm"
package.nodeVersion: ">=18.0.0"
package.lockfile: "package-lock.json"

# File Patterns (Cross-platform)
files.source: "src/**/*.{ts,tsx}"
files.styles: "src/**/*.css"
files.tests: "**/*.test.ts"
files.docs: "**/*.md"
files.config: ["*.config.{js,ts}", "tsconfig*.json", ".env*"]
files.ignore: [
  "node_modules",
  "dist",
  "coverage",
  ".turbo",
  ".next",
  ".git",
  "*.log"
]

# Project Structure Paths (Cross-platform format)
paths.source: {
  "frontend": "src/frontend",
  "backend": "src/backend",
  "components": "src/frontend/components",
  "styles": "src/frontend/styles",
  "server": "src/backend/server.ts",
  "public": "public",
  "build": "dist",
  "docs": "docs"
}

# Development Tools
tools.bundler: "vite"
tools.testing: ["vitest", "playwright"]
tools.linting: ["eslint", "prettier"]
tools.documentation: ["mkdocs", "typedoc"]
tools.database: "prisma"

# TypeScript Configuration
typescript.target: "ES2020"
typescript.module: "ESNext"
typescript.configs: ["tsconfig.json", "tsconfig.backend.json"]
typescript.experimentalDecorators: true
typescript.useDefineForClassFields: false
typescript.emitDecoratorMetadata: true

# Documentation Configuration
documentation.settings: {
  "engine": "mkdocs",
  "theme": "dracula",
  "output": "site",
  "serve": {
    "port": 8000,
    "host": "localhost"
  }
}

# Prompt Engineering & Library

Every time you use a rule(s), state the rule(s) you used.

Say Happy New Year each time!

## Project Context

A collection of resources for prompt engineering...

## Technologies

Overview of the technologies we are using:

- Use Python 3.12
- Use UV over Pip for installing packages
- Bedrock & Anthropic

## Coding Standards

Adopt / recommend the following coding standards when responding to code changes:

- Use the Type Hinting for all variables and function parameters
- Use the logger from AWS Lambda Powertools to log messages.
- Important: Follow Single Responsibility Principle for all functions.
- Important: Follow DRY Principle for all functions/classes where applicable.
- Less Important: Follow SOLID Principles for all functions/classes where applicable.