.cursorrules Python FastAPI copy # Python FastAPI .cursorrules # FastAPI best practices fastapi_best_practices = [ "Use Pydantic models for request and response schemas", "Implement dependency injection for shared resources", "Utilize async/await for non-blocking operations", "Use path operations decorators (@app.get, @app.post, etc.)", "Implement proper error handling with HTTPException", "Use FastAPI's built-in OpenAPI and JSON Schema support", ] # Folder structure folder_structure = """ app/ main.py models/ schemas/ routers/ dependencies/ services/ tests/ """ # Additional instructions additional_instructions = """ 1. Use type hints for all function parameters and return values 2. Implement proper input validation using Pydantic 3. Use FastAPI's background tasks for long-running operations 4. Implement proper CORS handling 5. Use FastAPI's security utilities for authentication 6. Follow PEP 8 style guide for Python code 7. Implement comprehensive unit and integration tests """ --- description: Enforces FastAPI best practices for application code within the 'app' directory, including data validation, dependency injection, and asynchronous operations. globs: app/**/*.* --- - Use Pydantic models for request and response schemas - Implement dependency injection for shared resources - Utilize async/await for non-blocking operations - Use path operations decorators (@app.get, @app.post, etc.) - Implement proper error handling with HTTPException - Use FastAPI's built-in OpenAPI and JSON Schema support --- description: Defines the recommended folder structure for FastAPI projects to maintain organization and separation of concerns within the 'app' directory. globs: app/**/*.* --- - Follow this folder structure: app/ main.py models/ schemas/ routers/ dependencies/ services/ tests/ --- description: Specifies guidelines for the main application file in FastAPI projects, focusing on application initialization and configuration. globs: app/main.py --- - Ensure proper application initialization with FastAPI() - Configure middleware and exception handlers - Define API routes using path operation decorators --- description: Guidelines for defining Pydantic models within the models directory of a FastAPI project to ensure data validation and serialization. globs: app/models/*.py --- - Use Pydantic models for request and response schemas - Define data types using Pydantic fields - Implement validation logic using Pydantic validators --- description: Applies general Python coding standards, including type hinting, input validation with Pydantic, background tasks, CORS handling, security utilities, PEP 8 compliance, and comprehensive testing. globs: **/*.py --- - Use type hints for all function parameters and return values - Implement proper input validation using Pydantic - Use FastAPI's background tasks for long-running operations - Implement proper CORS handling - Use FastAPI's security utilities for authentication - Follow PEP 8 style guide for Python code - Implement comprehensive unit and integration tests Cursor AI by @PatrickJS
.cursorrules Flutter Riverpod copy # AI Assistant Technical Instructions You are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately. First, confirm the instructions received from the user: {{instructions}} Please proceed with the following process based on these instructions: --- ## 1. Instruction Analysis and Planning - Summarize the main tasks concisely - Review the specified tech stack and consider implementation methods within those constraints **Note: Do not change versions listed in the tech stack without approval** - Identify key requirements and constraints - List potential challenges - Enumerate specific steps for task execution in detail - Determine the optimal execution order for these steps ### Preventing Duplicate Implementation Before implementation, verify: - Existence of similar functionality - Functions or components with identical or similar names - Duplicate API endpoints - Identification of processes that can be shared Take sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis. --- ## 2. Task Execution - Execute identified steps one by one - Report progress concisely after completing each step - Pay attention to the following during implementation: - Adherence to proper directory structure - Consistency in naming conventions - Appropriate placement of shared processes --- ## 3. Quality Control and Problem Resolution - Quickly verify the execution results of each task - If errors or inconsistencies occur, address them through the following process: a. Problem isolation and cause identification (log analysis, debug information verification) b. Creation and implementation of countermeasures c. Post-fix operation verification d. Debug log confirmation and analysis - Record verification results in the following format: a. Verification items and expected results b. Actual results and discrepancies c. Required countermeasures (if applicable) --- ## 4. Final Confirmation - Evaluate the entire deliverable once all tasks are completed - Verify consistency with original instructions and make adjustments as needed - Perform final confirmation that there are no duplicates in implemented functions --- ## 5. Results Report Please report final results in the following format: markdown # Execution Results Report ## Overview [Brief description of overall summary] ## Execution Steps 1. [Step 1 description and results] 2. [Step 2 description and results] ... ## Final Deliverables [Details of deliverables, links if applicable] ## Issue Resolution (if applicable) - Problems encountered and responses - Future considerations ## Notes & Improvement Suggestions - [List any observations or suggestions for improvement] --- ## Important Notes - Always confirm any unclear points before beginning work - Report and obtain approval for any important decisions as they arise - Report unexpected problems immediately and propose solutions - **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval - **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification - **Do not arbitrarily change versions listed in the tech stack** (APIs, frameworks, libraries, etc.). If changes are necessary, clearly explain the reason and wait for approval before making any changes --- # Tech Stack ## Core Technologies - **AI Model: GPT-4** ## Frontend - Flutter: ^3.22.0 ### State Management - Riverpod: ^2.6.1 ## BaaS - Firebase --- ## Project Structure Please implement following this directory structure: lib/features/products/ ├── data/ │ ├── models/ │ │ ├── product_dto.dart │ │ └── product_category_dto.dart │ └── product_repository.dart ├── presentation/ │ ├── screens/ │ │ ├── product_list_screen.dart │ │ └── product_details_screen.dart │ ├── controllers/ │ │ └── product_list_controller.dart │ ├── widgets/ │ └── product_card.dart ├── domain/ │ ├── models/ │ │ ├── product.dart │ │ └── product_category.dart │ └── get_products_use_case.dart └── shared/ └── models/ └── address.dart ## Placement Rules ### Flutter Project Structure Placement Rules This document outlines the placement rules for files and folders within the recommended Flutter project structure, focusing on scalability, maintainability, and adherence to Clean Architecture principles. #### Top-Level Structure lib/ ├── features/ ├── models/ ├── providers/ ├── routes/ ├── core/ ├── app.dart └── main.dart * **lib/**: Contains all Dart code. * **features/**: Feature-specific code. * **models/**: Global models (use sparingly). * **providers/**: Global providers (minimize use). * **routes/**: App navigation. * **core/**: Core app logic (networking, errors, DI). * **app.dart**: Root widget. * **main.dart**: Entry point. #### features/ Structure lib/features/ └── / ├── data/ │ ├── models/ │ └── _repository.dart ├── presentation/ │ ├── screens/ │ ├── controllers/ │ ├── widgets/ ├── domain/ │ ├── models/ │ └── .dart ├── use_cases/ └── shared/ └── models/ * **/**: A feature (e.g., authentication, products). * **data/**: Data access. * **models/**: Data Transfer Objects (DTOs). * **_repository.dart**: Data access logic. * **presentation/**: UI. * **screens/**: UI screens (__screen.dart). * **controllers/**: State management (_controller.dart). * **widgets/**: Feature-specific widgets (.dart). * **domain/**: Business logic. * **models/**: Domain models. * **.dart**: Main entity. * **use_cases/**: User interactions (.dart). * **shared/models/**: Models shared between *related* features. #### shared/ (Top-Level) Structure lib/shared/ ├── providers/ ├── widgets/ ├── models/ └── services/ * **providers/**: Providers shared across *unrelated* features. * **widgets/**: Widgets shared across *unrelated* features. * **models/**: Models shared across *unrelated* features (use cautiously). * **services/**: Utility classes. #### models/ (Top-Level) Structure lib/models/ └── .dart * Global models (use sparingly). #### providers/ (Top-Level) Structure lib/providers/ └── .dart * Global providers (minimize use). #### core/ Structure lib/core/ ├── network/ │ └── api_client.dart ├── errors/ │ └── exceptions.dart └── di/ └── injection.dart * **network/**: Networking code. * **errors/**: Error handling. * **di/**: Dependency injection. ## Naming Conventions * **Files:** snake_case (e.g., product_list_screen.dart). * **Classes:** PascalCase (e.g., ProductListScreen). * **Variables/Functions:** camelCase (e.g., productList). ## Key Principles * **Feature Isolation:** Self-contained feature code. * **Separation of Concerns:** Separate data, logic, and UI. * **Single Responsibility:** One purpose per class/file. * **DRY:** Avoid code duplication. * **Prefer Feature-Specific:** Prioritize feature-level placement. Please adhere to the above content when executing tasks. Cursor AI by @PatrickJS
.cursorrules Convex copy This document serves as some special instructions when working with Convex. # Schemas When designing the schema please see this page on built in System fields and data types available: https://docs.convex.dev/database/types Here are some specifics that are often mishandled: ## v (https://docs.convex.dev/api/modules/values#v) The validator builder. This builder allows you to build validators for Convex values. Validators can be used in schema definitions and as input validators for Convex functions. Type declaration Name Type id (tableName: TableName) => VId<GenericId, "required"> null () => VNull number () => VFloat64 float64 () => VFloat64 bigint () => VInt64 int64 () => VInt64 boolean () => VBoolean string () => VString bytes () => VBytes literal (literal: T) => VLiteral array (element: T) => VArray object (fields: T) => VObject<Expand<{ [Property in string | number | symbol]?: Exclude<Infer, undefined> } & { [Property in string | number | symbol]: Infer }>, T, "required", { [Property in string | number | symbol]: Property | `${Property & string}.${T[Property]["fieldPaths"]}` }[keyof T] & string> record (keys: Key, values: Value) => VRecord<Record<Infer, Value["type"]>, Key, Value, "required", string> union (...members: T) => VUnion any () => VAny optional (value: T) => VOptional ## System fields (https://docs.convex.dev/database/types#system-fields) Every document in Convex has two automatically-generated system fields: _id: The document ID of the document. _creationTime: The time this document was created, in milliseconds since the Unix epoch. You do not need to add indices as these are added automatically. ## Example Schema This is an example of a well crafted schema. ```ts import { defineSchema, defineTable } from "convex/server"; import { v } from "convex/values"; export default defineSchema( { users: defineTable({ name: v.string(), }), sessions: defineTable({ userId: v.id("users"), sessionId: v.string(), }).index("sessionId", ["sessionId"]), threads: defineTable({ uuid: v.string(), summary: v.optional(v.string()), summarizer: v.optional(v.id("_scheduled_functions")), }).index("uuid", ["uuid"]), messages: defineTable({ message: v.string(), threadId: v.id("threads"), author: v.union( v.object({ role: v.literal("system"), }), v.object({ role: v.literal("assistant"), context: v.array(v.id("messages")), model: v.optional(v.string()), }), v.object({ role: v.literal("user"), userId: v.id("users"), }), ), }) .index("threadId", ["threadId"]), }, ); Cursor AI by @PatrickJS
.cursorrules Angular TypeScript copy you are an expert Angular programmer using TypeScript, Angular 18 and Jest that focuses on producing clear, readable code. you are thoughtful, give nuanced answers, and are brilliant at reasoning. you carefully provide accurate, factual, thoughtful answers and are a genius at reasoning. before providing an answer, think step by step, and provide a detailed, thoughtful answer. if you need more information, ask for it. always write correct, up to date, bug free, fully functional and working code. focus on performance, readability, and maintainability. before providing an answer, double check your work include all required imports, and ensure proper naming of key components do not nest code more than 2 levels deep prefer using the forNext function, located in libs/smart-ngrx/src/common/for-next.function.ts instead of for(let i;i < length;i++), forEach or for(x of y) code should obey the rules defined in the .eslintrc.json, .prettierrc, .htmlhintrc, and .editorconfig files functions and methods should not have more than 4 parameters functions should not have more than 50 executable lines lines should not be more than 80 characters when refactoring existing code, keep jsdoc comments intact be concise and minimize extraneous prose. if you don't know the answer to a request, say so instead of making something up. Cursor AI by @Dave Bush
