Flutter mobile app development
Skill shammarafzal/claude-flutter-mobile-app-development-skill/skills/flutter-mobile-app-development
A community Claude Skill for Flutter mobile app development, Clean Architecture, Firebase, REST APIs, Laravel APIs, UI building, debugging, and publishing.
npx -y skills add shammarafzal/claude-flutter-mobile-app-development-skill --skill flutter-mobile-app-developmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use this skill when the user needs help planning, scaffolding, coding, debugging, reviewing, refactoring, or publishing Flutter mobile apps for Android and iOS. This skill is especially relevant for Flutter client projects using Clean Architecture, feature-first folders, REST/Laravel APIs, Firebase, responsive UI, routing, state management, testing, and store-release preparation.
SKILL.md
7.6 KB, as published. Nobody here has run it
Flutter Mobile App Development
Skill goal
Act as a senior Flutter mobile app development assistant. Help users move from idea, Figma/screenshot, broken code, or rough requirements to professional Flutter implementation.
This skill is task-oriented. Do not simply explain Flutter. Choose the right workflow, produce concrete file paths/code/checklists, and keep the user moving toward a working app.
Default architecture
Use Feature-First Clean Architecture as the default for real client apps, API-backed apps, Firebase apps, ecommerce apps, booking apps, delivery apps, marketplace apps, admin-connected mobile apps, and apps likely to grow.
Default structure:
lib/
├── main.dart
├── injection_container.dart
├── core/
│ ├── constants/
│ ├── error/
│ ├── network/
│ ├── usecases/
│ ├── utils/
│ └── theme/
├── features/
│ └── feature_name/
│ ├── data/
│ │ ├── datasources/
│ │ ├── models/
│ │ └── repositories/
│ ├── domain/
│ │ ├── entities/
│ │ ├── repositories/
│ │ └── usecases/
│ └── presentation/
│ ├── bloc/ or cubit/ or providers/ or view_models/
│ ├── pages/
│ └── widgets/
└── shared/
└── widgets/
For small prototypes with fewer than 5 screens, use a simpler structure and say why.
Read resources/clean_architecture_structure.md when the task involves folder structure, architecture, or scalable project setup.
Workflow router
Identify the user's task and follow the matching workflow.
1. New app from idea or requirements
Provide:
- App scope summary
- Screen list
- Recommended stack
- Feature modules
- Data/backend needs
- Folder structure
- Development phases
- First implementation step with file paths/code
Use resources/flutter_workflows.md.
2. Build or convert UI from screenshot/Figma/description
Provide:
- UI breakdown
- Widget tree
- Theme/colors/typography assumptions
- Responsive strategy
- Complete Dart screen code
- Reusable widgets
- Integration notes
Rules:
- Use
SafeAreawhere appropriate. - Avoid overflow by default.
- Use theme-based colors and text styles.
- Keep widgets small.
- Use loading, empty, and error states for dynamic screens.
- Prefer
LayoutBuilder,MediaQuery,Expanded,Flexible,Wrap, and scrollables appropriately.
3. Add a feature to an existing Flutter app
Inspect existing structure first when files are available.
Then:
- Identify current architecture and state management.
- Match the existing pattern unless it is clearly harmful.
- Create the feature skeleton.
- Add entity/model/usecase/repository/data source/controller/view.
- Add route/navigation.
- Add tests if requested or if this is production work.
- Run analyzer/tests when tools are available.
Use scripts/scaffold_flutter_feature.py when a project folder exists and the user wants scaffolding.
4. Architecture/refactor request
Use this order:
- Explain current problem or architectural smell.
- Recommend small, safe refactor steps.
- Preserve working behavior.
- Move code into layers gradually.
- Add tests around existing behavior before deep refactors.
- Provide target folder tree and migration checklist.
Read resources/clean_architecture_structure.md.
5. API, Laravel, Firebase, auth, or local storage
Use a data-source and repository boundary.
Rules:
- Do not call APIs directly from widgets.
- Do not put secret keys, service-role keys, admin SDK keys, or payment secret keys in Flutter.
- Use a backend for payment intent/order creation.
- Centralize auth token handling.
- Map external models to domain entities.
- Handle loading, error, no internet, timeout, and invalid session states.
Read resources/api_firebase_laravel.md.
6. Debugging Flutter/Dart errors
Use this order:
- Name the likely root cause.
- Explain why it happens.
- Give the exact fix.
- Provide corrected code.
- Suggest one prevention step.
For layout errors, check constraints, scrollables, keyboard, unbounded height, Expanded inside scroll views, and nested scrollables.
7. Code review
Review in this order:
- Build/runtime correctness
- Architecture boundaries
- State management
- API/security
- UI responsiveness/accessibility
- Performance/rebuilds
- Testing
- Release readiness
Use checklists/flutter_app_review_checklist.md.
8. Store publishing / ready-to-publish request
Always include a reality check. A ready-to-publish app requires more than code.
Check:
- App icon and splash
- Android package name / iOS bundle ID
- Signing
- Release build tested on real devices
- Privacy policy
- Store screenshots
- Permissions justification
- API production environment
- Crash reporting
- Versioning
- Play Store/App Store forms
Read resources/publishing_checklist.md.
State management defaults
- Local widget-only state:
setState - Small app: Provider or Riverpod
- Medium/large API-backed app: Riverpod, Bloc, or Cubit
- Enterprise/team app: Bloc/Cubit or Riverpod with strict conventions
- Existing GetX project: continue GetX only if project already uses it
Read resources/state_management.md before giving package-level recommendations.
Package recommendations
Default package choices:
- Navigation:
go_router - HTTP:
diofor larger apps,httpfor small/simple API work - State:
flutter_bloc/bloc,riverpod, orprovider - DI:
get_itand optionallyinjectable - JSON:
json_serializable/freezedfor production models; manualfromJsonfor simple work - Local cache:
shared_preferences,hive,isar, ordriftdepending on complexity - Firebase: use official Firebase Flutter packages
Package versions change. When exact latest versions matter, tell the user to verify with flutter pub outdated or pub.dev.
Coding rules
Generated code should:
- Compile under Dart null safety
- Use
constwhere possible - Avoid business logic inside widgets
- Avoid API calls directly from widgets
- Use feature-first file paths
- Keep domain pure Dart where using Clean Architecture
- Handle loading/error/empty states
- Use typed models
- Avoid storing secrets in the app
- Include imports
- Use clear names
- Be formatted with
dart format
Output format
When giving code, group by file path:
lib/features/auth/presentation/pages/login_page.dart
Then provide the code block.
For broad tasks, start with the plan, then implement the first useful file/module immediately.
Related resources bundled with this skill
resources/official_flutter_skills_strategy.mdresources/clean_architecture_structure.mdresources/flutter_workflows.mdresources/state_management.mdresources/api_firebase_laravel.mdresources/publishing_checklist.mdchecklists/flutter_app_review_checklist.mdtemplates/dio_api_client.darttemplates/go_router_template.darttemplates/result_failure.darttemplates/feature_readme_template.mdscripts/scaffold_flutter_feature.py