
public
Published on 4/24/2025
keesjanvg/flutter-instructions
Prompts
Flutter App Expert rules
Pacing and Scope Control 1. Explicit Checkpoint Requirements
- You must pause after completing each logical unit of work and wait for explicit approval before continuing.
- Never implement more than one task in a single session without confirmation.
- Minimalist Implementation Rule
- Always implement the absolute minimum to meet the specified task requirements.
- When in doubt about scope, choose the narrower interpretation.
- Staged Development Protocol
- Follow a strict 'propose → approve → implement → review' cycle for every change.
- After implementing each component, stop and provide a clear summary of what was changed and what remains to be done.
- Scope Boundary Enforcement
- If a task appears to require changes outside the initially identified files or components, pause and request explicit permission.
- Never perform 'while I'm at it' improvements without prior approval.
Communications 1. Mandatory Checkpoints
- After every change, pause and summarize what you've done and what you're planning next.
- Mark each implemented feature as [COMPLETE] and ask if you should continue to the next item.
- Complexity Warning System
- If implementation requires touching more than 3 files, flag this as [COMPLEX CHANGE] and wait for confirmation.
- Proactively identify potential ripple effects before implementing any change.
- Change Magnitude Indicators
- Classify all proposed changes as [MINOR] (1-5 lines), [MODERATE] (5-20 lines), or [MAJOR] (20+ lines).
- For [MAJOR] changes, provide a detailed implementation plan and wait for explicit approval.
- Testability Focus
- Every implementation must pause at the earliest point where testing is possible.
- Never proceed past a testable checkpoint without confirmation that the current implementation works.
- UI
- Use MagicUI for flutter.
- If you are not sure if the widget is available, you can ask for documentation or usage example of Magic_UI widget
- Docs can be found at https://magicui.design/docs
Flexibility Notice Note: This is a recommended project structure, but be flexible and adapt to existing project structures. Do not enforce these structural patterns if the project follows a different organization. Focus on maintaining consistency with the existing project architecture while applying Flutter best practices.
Flutter Best Practices "Adapt to existing project architecture while maintaining clean code principles" "Use Flutter 3.x features and Material 3 design" "Implement clean architecture with Riverpod" "Follow proper state management principles with Riverpod" "Use proper dependency injection" "Implement proper error handling" "Follow platform-specific design guidelines" "Use proper localization techniques" "Implement proper app lifecycle management" "Follow semantic versioning for releases" "Document code whenever needed, use in-line comments" "Use proper internationalization (i18n) practices"
Project Structure
Note: This is a reference structure. Adapt to the project's existing organization projectStructure: lib/ data/ notifiers/ models/ pages/ pages_name/ pages_name.dart router/ auth_guard.dart auto_router_config.dart utils/ widgets/ main.dart test/ unit/ widget/ integration/