flutter-development-guidelines — Cursor rule for Flutter
Locks down folder layout, naming and Dart style for Flutter apps built on MVVM with Riverpod. Useful when the agent scatters files across the project.
.cursor/rules/flutter-development-guidelines-cursorrules-prompt-file.mdcWhat flutter-development-guidelines-cursorrules-prompt-file does
The rule fires on **/*.dart and spells out where code goes under /lib: models in /lib/models/, state and business logic in /lib/viewmodels/, reusable widgets in /lib/views/widgets/, screens in /lib/views/screens/, API and data access in /lib/services/, helpers in /lib/utils/.
Architecture is MVVM, with state kept in the ViewModel and wired to the View through Riverpod. Naming follows the usual Dart split: snake_case for files and directories, UpperCamelCase for classes, lowerCamelCase for variables, boolean flags like isLoading and hasError. Imports come in three blocks — dart: first, then package:, then relative paths.
Lines stay under 80 characters, every control structure gets braces, strings use single quotes, and immutable widgets get const constructors. One thing to watch: the rule ships with alwaysApply: false, so it will not attach itself to your prompts. You have to pull it in per request. In a repo with no Flutter code it just adds noise, so keep it off there.
What it helps with
- lay out a Flutter project into MVVM folders
- move state out of widgets into a Riverpod ViewModel
- keep file and class names consistent across the codebase
- order imports the same way in every file
- swap StatefulWidget for StatelessWidget where state is not needed
Example prompts for the agent
- Build a login screen following the rule: ViewModel in /lib/viewmodels/, screen in /lib/views/screens/
- Refactor this widget — move its state into a Riverpod ViewModel and add const where possible
- Check auth_wizard.dart against the rule: line length, quotes, import order
How to install flutter-development-guidelines-cursorrules-prompt-file
Manually: put the files in place
.cursor/rules/flutter-development-guidelines-cursorrules-prompt-file.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/flutter-development-guidelines-cursorrules-prompt-file.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/flutter-development-guidelines-cursorrules-prompt-file.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/flutter-development-guidelines-cursorrules-prompt-file.mdManually: put the files in place
.clinerules/flutter-development-guidelines-cursorrules-prompt-file.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about flutter-development-guidelines-cursorrules-prompt-file
How do I install flutter-development-guidelines in Cursor?
Create .cursor/rules/flutter-development-guidelines-cursorrules-prompt-file.mdc in your project root and paste the rule text into it.
What does this rule do?
It defines the /lib directory layout, naming conventions, import order and Dart style. The agent follows it whenever it writes or edits .dart files.
Does it apply to every file automatically?
No. It is marked alwaysApply: false and scoped to the **/*.dart glob, so you attach it to the requests where you want it.
Source text
flutter-development-guidelines-cursorrules-prompt-file.mdc · CC0-1.0
---
description: "Cursor rules for Flutter development with MVVM architecture, Riverpod state management, Material widgets, and Dart style guidelines."
globs: **/*.dart
alwaysApply: false
---
### Code style and structure
- Write concise and efficient source code.
- Strive for source code that is easy to read and maintain, and provide accurate examples.
- Avoid duplication of code: modularise widgets and functions into reusable components.
- Use descriptive variable names: use names with auxiliary verbs such as isLoading, hasError.
### Directory structure under /lib.
- /lib/models/: data models and type definitions (Models)
- /lib/viewmodels/: state management and business logic (ViewModel)
- /lib/views/widgets/: reusable widgets (View)
- /lib/views/screens/: per-screen widgets (View)
- /lib/services/: service classes for API calls and data access
- /lib/utils/: helper functions and constants
### Naming conventions
- Directories and files: use snakeCase (e.g. auth_wizard.dart).
- UpperCamelCase: use for class names/enumerations/typedefs/type parameters, etc.
- LowerCamelCase: used for variables/functions/class members (properties, methods), etc.
- lowercase_with_underscores (snakeCase): for files/directories/packages/libraries, etc.
### Import.
- Place imports starting with dart: first (use lowercase_with_underscores for the import prefix).
- Next, import third-party packages (package:).
- Finally, import relative paths and files in the project.
### Using Dart.
- Take advantage of type safety: use static typing in all code and utilise type inference wherever possible.
### UI and styling.
- Use Material widgets.
- Unify theming: use ThemeData to apply consistent styles.
### Performance optimisation.
- Prefer StatelessWidget when state is not required.
- Make use of const constructors: if widgets are immutable, use const to optimise builds.
### State management.
- Use riverpod to implement efficient state management.
- Manage state within the ViewModel and link it to the View.
### Software architecture
Use MVVM (Model View ViewModel).
### Key rules.
- To improve code readability, lines should not exceed 80 characters in length.
- Use braces {} for all flow control structures (if, for, while, etc.).
- Use comment-outs proactively to help understand and maintain code.
- Use single quotes, avoid the use of double quotes and use consistent string literals to improve readability.
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules