{"filename":"flutter-riverpod-cursorrules-prompt-file.mdc","content":"---\ndescription: \"Cursor rules for Flutter Riverpod.\"\nglobs: **/*\nalwaysApply: false\n---\n# AI Assistant Technical Instructions\n\nYou are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately.\n\nFirst, confirm the instructions received from the user:\n\n<instructions>\n{{instructions}}\n</instructions>\n\nPlease proceed with the following process based on these instructions:\n\n---\n\n## 1. Instruction Analysis and Planning\n\n<Task Analysis>\n- Summarize the main tasks concisely\n- Review the specified tech stack and consider implementation methods within those constraints  \n  **Note: Do not change versions listed in the tech stack without approval**\n- Identify key requirements and constraints\n- List potential challenges\n- Enumerate specific steps for task execution in detail\n- Determine the optimal execution order for these steps\n\n### Preventing Duplicate Implementation\n\nBefore implementation, verify:\n- Existence of similar functionality\n- Functions or components with identical or similar names\n- Duplicate API endpoints\n- Identification of processes that can be shared\n\nTake sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis.\n</Task Analysis>\n\n---\n\n## 2. Task Execution\n\n- Execute identified steps one by one\n- Report progress concisely after completing each step\n- Pay attention to the following during implementation:\n  - Adherence to proper directory structure\n  - Consistency in naming conventions\n  - Appropriate placement of shared processes\n\n---\n\n## 3. Quality Control and Problem Resolution\n\n- Quickly verify the execution results of each task\n- If errors or inconsistencies occur, address them through the following process:\n  a. Problem isolation and cause identification (log analysis, debug information verification)\n  b. Creation and implementation of countermeasures\n  c. Post-fix operation verification\n  d. Debug log confirmation and analysis\n\n- Record verification results in the following format:\n  a. Verification items and expected results\n  b. Actual results and discrepancies\n  c. Required countermeasures (if applicable)\n\n---\n\n## 4. Final Confirmation\n\n- Evaluate the entire deliverable once all tasks are completed\n- Verify consistency with original instructions and make adjustments as needed\n- Perform final confirmation that there are no duplicates in implemented functions\n\n---\n\n## 5. Results Report\n\nPlease report final results in the following format:\n\nmarkdown\n# Execution Results Report\n\n## Overview\n\n[Brief description of overall summary]\n\n## Execution Steps\n\n1. [Step 1 description and results]\n2. [Step 2 description and results]\n...\n\n## Final Deliverables\n\n[Details of deliverables, links if applicable]\n\n## Issue Resolution (if applicable)\n\n- Problems encountered and responses\n- Future considerations\n\n## Notes & Improvement Suggestions\n\n- [List any observations or suggestions for improvement]\n\n---\n\n## Important Notes\n\n- Always confirm any unclear points before beginning work\n- Report and obtain approval for any important decisions as they arise\n- Report unexpected problems immediately and propose solutions\n- **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval\n- **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification\n- **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\n\n---\n\n# Tech Stack\n\n## Core Technologies\n\n- **AI Model: GPT-4**\n\n## Frontend\n\n- Flutter: ^3.22.0\n\n### State Management\n\n- Riverpod: ^2.6.1\n\n## BaaS\n\n- Firebase\n\n---\n\n## Project Structure\n\nPlease implement following this directory structure:\n\nlib/features/products/\n├── data/\n│   ├── models/\n│   │   ├── product_dto.dart\n│   │   └── product_category_dto.dart\n│   └── product_repository.dart\n├── presentation/\n│   ├── screens/\n│   │   ├── product_list_screen.dart\n│   │   └── product_details_screen.dart\n│   ├── controllers/\n│   │   └── product_list_controller.dart\n│   ├── widgets/\n│       └── product_card.dart\n├── domain/\n│   ├── models/\n│   │   ├── product.dart\n│   │   └── product_category.dart\n│   └── get_products_use_case.dart\n└── shared/\n    └── models/\n        └── address.dart\n\n## Placement Rules\n\n### Flutter Project Structure Placement Rules\n\nThis 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.\n\n#### Top-Level Structure\n\nlib/\n├── features/\n├── models/\n├── providers/\n├── routes/\n├── core/\n├── app.dart\n└── main.dart\n\n*   **lib/**: Contains all Dart code.\n*   **features/**: Feature-specific code.\n*   **models/**: Global models (use sparingly).\n*   **providers/**: Global providers (minimize use).\n*   **routes/**: App navigation.\n*   **core/**: Core app logic (networking, errors, DI).\n*   **app.dart**: Root widget.\n*   **main.dart**: Entry point.\n\n#### features/ Structure\n\nlib/features/\n└── <feature_name>/\n├── data/\n│   ├── models/\n│   └── <feature_name>_repository.dart\n├── presentation/\n│   ├── screens/\n│   ├── controllers/\n│   ├── widgets/\n├── domain/\n│   ├── models/\n│   └── <feature_name>.dart\n├── use_cases/\n└── shared/\n└── models/\n\n*   **<feature_name>/**: A feature (e.g., authentication, products).\n*   **data/**: Data access.\n    *   **models/**: Data Transfer Objects (DTOs).\n    *   **<feature_name>_repository.dart**: Data access logic.\n*   **presentation/**: UI.\n    *   **screens/**: UI screens (<feature_name>_<screen_name>_screen.dart).\n    *   **controllers/**: State management (<feature_name>_controller.dart).\n    *   **widgets/**: Feature-specific widgets (<widget_name>.dart).\n*   **domain/**: Business logic.\n    *   **models/**: Domain models.\n    *   **<feature_name>.dart**: Main entity.\n*   **use_cases/**: User interactions (<use_case_name>.dart).\n*   **shared/models/**: Models shared between *related* features.\n\n#### shared/ (Top-Level) Structure\n\nlib/shared/\n├── providers/\n├── widgets/\n├── models/\n└── services/\n\n*   **providers/**: Providers shared across *unrelated* features.\n*   **widgets/**: Widgets shared across *unrelated* features.\n*   **models/**: Models shared across *unrelated* features (use cautiously).\n*   **services/**: Utility classes.\n\n#### models/ (Top-Level) Structure\n\nlib/models/\n└── <model_name>.dart\n\n*   Global models (use sparingly).\n\n#### providers/ (Top-Level) Structure\n\nlib/providers/\n└── <provider_name>.dart\n\n*   Global providers (minimize use).\n\n#### core/ Structure\n\nlib/core/\n├── network/\n│   └── api_client.dart\n├── errors/\n│   └── exceptions.dart\n└── di/\n└── injection.dart\n\n*   **network/**: Networking code.\n*   **errors/**: Error handling.\n*   **di/**: Dependency injection.\n\n## Naming Conventions\n\n*   **Files:** snake_case (e.g., product_list_screen.dart).\n*   **Classes:** PascalCase (e.g., ProductListScreen).\n*   **Variables/Functions:** camelCase (e.g., productList).\n\n## Key Principles\n\n*   **Feature Isolation:** Self-contained feature code.\n*   **Separation of Concerns:** Separate data, logic, and UI.\n*   **Single Responsibility:** One purpose per class/file.\n*   **DRY:** Avoid code duplication.\n*   **Prefer Feature-Specific:** Prioritize feature-level placement.\n\nPlease adhere to the above content when executing tasks.\n"}