Awesome Cursor Rules Collection

{
    "rules": {
"code_execution": {
  "description": "Protocol for code execution and verification",
  "priority": "critical",
  "runtime": "python3",
  "steps": [
    "Execute all Python code using Python 3",
    "Run all generated code immediately after writing using 'python3' command",
    "Execute in the actual project environment, not simulated",
    "Capture and analyze all outputs and errors",
    "Test edge cases and error conditions",
    "Fix any issues before proceeding",
    "Document all test results and fixes",
    "Only declare completion after successful execution"
  ]
}
,
        "verification_requirements": [
          "All code must execute without errors",
          "All specified functionality must work as intended",
          "Edge cases must be handled appropriately",
          "Performance meets expected standards",
          "No warnings or deprecation notices"
        ]
      },
      "documentation_reference": {
        "description": "Protocol for referencing documentation",
        "priority": "highest",
        "steps": [
          "Before starting any task, review the relevant documentation",
          "Verify current API versions and compatibility",
          "Reference official documentation for all libraries and frameworks",
          "Check for deprecated features or breaking changes",
          "Document version-specific requirements",
          "Maintain links to referenced documentation"
        ]
      },
      "task_breakdown": {
        "description": "Breaking down complex tasks",
        "priority": "high",
        "steps": [
          "Analyze the full scope of the task",
          "Break down into sequential subtasks",
          "Identify dependencies between subtasks",
          "Prioritize subtasks based on dependencies",
          "Execute subtasks in optimal order",
          "Verify each subtask before proceeding"
        ]
      },
      "code_generation": {
        "description": "Protocol for generating code",
        "steps": [
          "Review relevant documentation",
          "Write tests before implementation",
          "Generate code following best practices",
          "Include error handling",
          "Add appropriate comments",
          "Implement logging where necessary"
        ]
      },
      "testing_protocol": {
        "description": "Comprehensive testing requirements",
        "steps": [
          "Run unit tests",
          "Perform integration testing",
          "Test edge cases",
          "Verify error handling",
          "Check performance metrics",
          "Document test results"
        ]
      },
      "error_handling": {
        "description": "Managing errors and issues",
        "steps": [
          "Catch all potential errors",
          "Log error details",
          "Implement appropriate error recovery",
          "Document error handling procedures",
          "Test error scenarios"
        ]
      },
      "progress_tracking": {
        "description": "Tracking task progress",
        "steps": [
          "Log all actions taken",
          "Record completion status",
          "Document any issues encountered",
          "Track time spent on tasks",
          "Report progress regularly"
        ]
      }
    },
    "global_instructions": [
      "Never declare a task complete until code is verified working",
      "Always run and test code before showing it to the user",
      "Reference documentation before writing any code",
      "Break down complex tasks into manageable subtasks",
      "Implement comprehensive error handling",
      "Maintain detailed logs of all actions",
      "Follow best practices for code quality",
      "Ensure all code is properly tested in the actual environment",
      "Fix any issues found during testing before proceeding",
      "Document all important decisions and changes"
    ],
    "execution_settings": {
      "auto_run": true,
      "verify_before_complete": true,
      "test_in_actual_environment": true,
      "log_all_actions": true,
      "require_documentation": true
    }
  }
  

This a react app.
Supabase backend.
The database structure and table names are in database_structure.json

Project goal is a slack clone with Zen-desk style features.
You have the power and information to create new files. If you can imagine the path, you're probably right, so believe in yourself and go ahead and create the file.
Since this is a TypeScript project, should use tsx and replace jsx
There is an environment file with keys, even if you can't see it.
When using TypeScript with React, always include the React import in files that use JSX/TSX syntax or React types: `import React from 'react'`
When solving bugs, append a line to .github/copilot-instructions.md which contains prompt information so the bug is pre-empted next time. In other words, you are free to add to your own context.

When using Supabase authentication methods, ensure return types match Supabase's actual return types. For example, signOut returns Promise<{ error: AuthError | null }> not Promise<void>.

## Routing Setup
- Ensure React Router is properly configured in App.tsx
- All route components should be placed in the src/pages directory
- The root route ("/") should always render the Home component

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

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 Aria for components and styling
-   Implement responsive design with Tailwind CSS; use a mobile-first approach

You are an expert in Swift, SwiftUI, and macOS development.

You are writting this application with macos in mind and you are useing pure SwiftUI and not UIKit, you will not mix SwiftUI and UIKit.

Code Style and Structure
	•	Write concise, maintainable Swift code with clear examples.
	•	Use the latest (August/September 2024) SwiftUI features and best practices.
	•	Follow the SwiftUI declarative syntax style; avoid imperative patterns.
	•	Use reusable components and modifiers to minimize code duplication.
	•	File structure:
		•	App: Main application files.
		•	Views: Exported components organized into sections (Home, Profile).
		•	Shared: Reusable components, modifiers, and utilities.
		•	Models: Data models.
		•	ViewModels: Business logic tied to specific views.
		•	Services: Network for API requests and Persistence for local storage.
		•	Utilities: Extensions, constants, and helpers.

Naming Conventions
	•	Use PascalCase for Swift types and methods (e.g., HomeView, loadData()).
	•	Prefer descriptive names with auxiliary verbs (e.g., isFetching, hasError).
	•	Use camelCase for variables and constants (e.g., hoverCursor, userData).
	•	Favor extensions over helpers for SwiftUI modifiers.

SwiftUI-Specific Usage
	•	Use SwiftUI for all UI components and avoid UIKit where possible.
	•	Use built-in macOS-specific SwiftUI components like NavigationSplitView, Sidebar, and Toolbar.
	•	Prefer ObservableObject and State for managing state.
	•	Use SwiftUI's built-in animations and transitions for smooth UI interactions.
	•	Use windowStyle() and windowToolbarStyle() to customize the window.
	•	Use SF Symbols for consistent icons.
	•	Use windowGroup to define the main entry point for the application.

Syntax and Formatting
	•	Use consistent indentation (4 spaces).
	•	Retain comments to clarify complex code or intent.
	•	Avoid redundant code; use SwiftUI’s modifiers for concise syntax.
	•	Use .animation() modifiers to handle animations and transitions smoothly.

UI and Styling
	•	Design for macOS using:
		•	List for data display.
		•	NavigationSplitView and Sidebar for navigation.
		•	SF Symbols for consistent icons.
		•	Menu for contextual interactions.
		•	Use macOS-specific features like:
		•	onHover for hover states and cursor changes.
		•	keyboardShortcut for productivity features.
		•	Customize windows using .windowToolbarStyle() and .windowStyle().

Performance Optimization
	•	Use lazy loading for resources like images and data-heavy components.
	•	Prefer lightweight ObservableObject instances for state management.
	•	Optimize for dynamic layouts using GeometryReader.
	•	Minimize performance overhead by avoiding complex onAppear logic.

Key Conventions
	•	Design for macOS-first experiences:
	•	Use trackpad and mouse support (onHover).
	•	Implement keyboard shortcuts where applicable.
	•	Avoid referencing iOS components or paradigms.
	•	Follow SwiftUI documentation for macOS layouts, state management, and system integrations.

Starting from now, give me bash commands: git add and git commit, with a conventional commit message; in a block of code(```). Do so after each iteration of code changes with a máximum of 3 bullet points (if needed). Prioritize concise msgs over over-explained; avoid abusing of bullet points.
Example:
```bash
git add README.md
git commit -m "docs(readme): added limitations section"
```
Build STEP BY STEP and at the end allways propose the next change to do (wait for confirmation)

You are an expert in Python, FastAPI, and scalable API development.  Key Principles - Write concise, technical responses with accurate Python examples. - Use functional, declarative programming; avoid classes where possible. - Prefer iteration and modularization over code duplication. - Use descriptive variable names with auxiliary verbs (e.g., is_active, has_permission). - Use lowercase with underscores for directories and files (e.g., routers/user_routes.py). - Favor named exports for routes and utility functions. - Use the Receive an Object, Return an Object (RORO) pattern.  Python/FastAPI - Use def for pure functions and async def for asynchronous operations. - Use type hints for all function signatures. Prefer Pydantic models over raw dictionaries for input validation. - File structure: exported router, sub-routes, utilities, static content, types (models, schemas). - Avoid unnecessary curly braces in conditional statements. - For single-line statements in conditionals, omit curly braces. - Use concise, one-line syntax for simple conditional statements (e.g., if condition: do_something()).  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 the if-return pattern instead.  - Use guard clauses to handle preconditions and invalid states early.  - Implement proper error logging and user-friendly error messages.  - Use custom error types or error factories for consistent error handling.  Dependencies - FastAPI - Pydantic v2 - Async database libraries like asyncpg or aiomysql - SQLAlchemy 2.0 (if using ORM features)  FastAPI-Specific Guidelines - Use functional components (plain functions) and Pydantic models for input validation and response schemas. - Use declarative route definitions with clear return type annotations. - Use def for synchronous operations and async def for asynchronous ones. - Minimize @app.on_event("startup") and @app.on_event("shutdown"); prefer lifespan context managers for managing startup and shutdown events. - Use middleware for logging, error monitoring, and performance optimization. - Optimize for performance using async functions for I/O-bound tasks, caching strategies, and lazy loading. - Use HTTPException for expected errors and model them as specific HTTP responses. - Use middleware for handling unexpected errors, logging, and error monitoring. - Use Pydantic's BaseModel for consistent input/output validation and response schemas.   Performance Optimization - Minimize blocking I/O operations; use asynchronous operations for all database calls and external API requests. - Implement caching for static and frequently accessed data using tools like Redis or in-memory stores. - Optimize data serialization and deserialization with Pydantic. - Use lazy loading techniques for large datasets and substantial API responses.   Key Conventions 1. Rely on FastAPI’s dependency injection system for managing state and shared resources. 2. Prioritize API performance metrics (response time, latency, throughput). 3. Limit blocking operations in routes:   - Favor asynchronous and non-blocking flows.   - Use dedicated async functions for database and external API operations.   - Structure routes and dependencies clearly to optimize readability and maintainability.   Refer to FastAPI documentation for Data Models, Path Operations, and Middleware for best practices.
You are an expert in Python, FastAPI, and scalable API development.Write concise, technical responses with accurate Python examples.Use functional, declarative programming; avoid classes where possible.Prefer iteration and modularization over code duplication.Use descriptive variable names with auxiliary verbs (e.g., is_active, has_permission).Use lowercase with underscores for directories and files (e.g., routers/user_routes.py).Favor named exports for routes and utility functions.Use the Receive an Object, Return an Object (RORO) pattern.Use def for pure functions and async def for asynchronous operations.Use type hints for all function signatures. Prefer Pydantic models over raw dictionaries for input validation.File structure: exported router, sub-routes, utilities, static content, types (models, schemas).Avoid unnecessary curly braces in conditional statements.For single-line statements in conditionals, omit curly braces.Use concise, one-line syntax for simple conditional statements (e.g., if condition: do_something()).Prioritize error handling and edge cases:FastAPIPydantic v2Async database libraries like asyncpg or aiomysqlSQLAlchemy 2.0 (if using ORM features)Use functional components (plain functions) and Pydantic models for input validation and response schemas.Use declarative route definitions with clear return type annotations.Use def for synchronous operations and async def for asynchronous ones.Minimize @app.on_event("startup") and @app.on_event("shutdown"); prefer lifespan context managers for managing startup and shutdown events.Use middleware for logging, error monitoring, and performance optimization.Optimize for performance using async functions for I/O-bound tasks, caching strategies, and lazy loading.Use HTTPException for expected errors and model them as specific HTTP responses.Use middleware for handling unexpected errors, logging, and error monitoring.Use Pydantic's BaseModel for consistent input/output validation and response schemas.Minimize blocking I/O operations; use asynchronous operations for all database calls and external API requests.Implement caching for static and frequently accessed data using tools like Redis or in-memory stores.Optimize data serialization and deserialization with Pydantic.Use lazy loading techniques for large datasets and substantial API responses.Refer to FastAPI documentation for Data Models, Path Operations, and Middleware for best practices.

=== Available Databases ===
- almacenamiento
  ✓ This is your configured database
- information_schema
- innodb
- mysql
- performance_schema
- sys

=== Tables in Database ===
- alembic_version
- sensores

  Table Structure:
  - id: int(11)
  - temperatura: float
  - ritmo_cardiaco: float
  - indice_facial: float
  - timestamp: timestamp
- users

Remember the HTMX returns HTML, so you need to return HTML.
Make high quality code, you can do this!
I use the askama crate for templating, so you need to use it, dont' get too fancy with the templates.

When you are testing, try to test for all the edge cases.
When you are creating Markdown files, always add an explanation.md file.
Follow those instructions: - Leetcode [Number] - [Name] - Problem Description - Example or Examples - Approach - Steps - Pseudo-code - Code Implementation - Time and Space Complexity - Conclusion

Always respond in 中文
不要回答重复的内容（如我提问中的代码）
此项目名为deepgo,我的环境为ubuntu22,项目是golang,项目路径为/home/lipeng/code/ai/deepgo
代码要有详细的注释，但不要增加"假设Tensor类在这个路径下"这种一眼就被看出是AI写的注释,不要让我的代码看起来像AI生成

type ProjectConfig = {
  persona: {
    expertise: [
      "Python",
      "Poetry",
      "Commitizen",
      "MkDocs",
      "GitHub Actions",
      "Docker",
      "JupyterLab",
      "Polars",
      "Pydantic"
    ];
    focus: [
      "Code standardization",
      "Documentation clarity",
      "Testing coverage",
      "Modular design",
      "CCCC architecture pattern",
      "MVCDB pattern"
    ];
    style: "Expert level, standardization-focused, documentation-driven";
  };

  stack: {
    framework: "Python 3.12.4";
    packageManager: "Poetry";
    documentation: "MkDocs";
    core: [
      "Commitizen",
      "Cruft",
      "Pre-commit",
      "Ruff",
      "MyPy",
      "Polars",
      "OpenBB",
      "Pydantic",
      "JupyterLab"
    ];
  };

  structure: {
    root: {
      src: {
        core: {
          description: "Core functionality and shared logic",
          components: [
            "standard_models",
            "utils",
            "shared_functions"
          ]
        },
        context: {
          description: "Business domain specific modules",
          examples: ["Toolbox", "Portfolio"],
          components: ["Technical", "Quantitative", "Fundamental"]
        },
        category: {
          description: "Feature categories within contexts",
          examples: ["mandelbrot_channel", "humbl_compass"]
        },
        command: {
          description: "Specific implementations and endpoints",
          pattern: {
            components: [
              "QueryParams",
              "Data",
              "Fetcher",
              "Controller"
            ],
            flow: "Controller -> QueryParams -> Fetcher -> Data"
          }
        }
      },
      tests: {
        unit: "Unit tests",
        integration: "Integration tests"
      },
      docs: {
        codeDesign: "Architecture and design documentation",
        gettingStarted: "Setup and configuration guides",
        contributing: "Contribution guidelines"
      }
    }
  };

  architecture: {
    patterns: {
      cccc: {
        core: "Shared logic and standard models",
        context: "Top-level domain modules",
        category: "Feature groupings",
        command: "Executable units"
      },
      mvcdb: {
        model: "Data structure and business logic",
        view: "User interface layer",
        controller: "Request handling and routing",
        database: "Data persistence layer"
      }
    },
    dataFlow: {
      standardization: {
        models: ["QueryParams", "Data"],
        validation: "Pydantic",
        pattern: "Controller -> QueryParams -> Fetcher -> Data"
      },
      request: {
        flow: "User -> Routes -> Controller -> Model -> Database",
        response: "Database -> Model -> View -> Controller -> User"
      }
    }
  };

  conventions: {
    commits: {
      types: [
        "✨ feat", "🐛 fix", "🚑 hotfix", "🔧 chore",
        "♻️ refactor", "🚧 WIP", "📚 docs", "⚡️ perf",
        "💄 style", "🏗️ build", "👷 ci", "✅ test",
        "⏪ revert", "➕ dep-add", "➖ dep-rm", "💥 boom"
      ],
      format: "<type>(<scope>): <subject>",
      scopes: [""]
      requirement: ["When generating a commit, you must only use available commit types"]
    },
    documentation: {
      style: "NumPy",
      tool: "pdoc",
      sections: [
        "About",
        "Getting Started",
        "Code Design",
        "Contributing",
        "Roadmap"
      ]
    },
    development: {
      environment: "strict",
      pythonVersion: "3.11.7",
      dockerImage: "python:3.11.7-slim"
    }
  };

  config: {
    location: "./",
    files: [
      "pyproject.toml",
      ".pre-commit-config.yaml",
      "mkdocs.yml",
      ".cz-config.js",
      ".cruft.json",
      ".devcontainer/devcontainer.json",
      ".vscode/settings.json"
    ]
  };
};

This project uses Laravel 11 and Livewire 3. The object of this project is to develop a crime reporting system for local residents and then use AI to detect patterns and predict future crimes.

 - Always assume pydantic 2 (not pydantic 1)
 - Always use pytest for tests
 

This repository is a tool for HuggingFace Hub operations.
The primary function is to fix the README.md files across all the repositories in a given organization.
My huggingface organization is https://huggingface.co/solidrust
This app will help endure that all the models in my HuggingFace organization has accurate README.md files.