# Flutter Project Bootstrap > Scaffolds a Flutter app structure from developer requirements. Supports a guided questionnaire and a quick default mode, then generates architecture, dependencies, starter files, and 1-2 sample screens. Use when this capability is needed. - Skill: `tomevault-io/flutter-project-bootstrap` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/flutter-project-bootstrap` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/flutter-project-bootstrap/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/flutter-project-bootstrap --- # Flutter Project Bootstrap ## Purpose Use this skill to initialize a new Flutter project structure based on developer needs. This skill supports two modes: - Guided setup: ask requirement questions and generate from answers. - Quick default setup: skip questions and apply a recommended baseline. ## Activation Activate this skill when the user asks to bootstrap, scaffold, or initialize a Flutter app structure and wants architecture, dependencies, and starter code generated quickly. ## Non-Goals - Do not implement full business logic for every feature. - Do not generate production secrets or real keys. - Do not install unsupported platform SDKs silently. ## Mode Selection Ask this first: - Do you want Guided setup or Quick default setup? If user picks Quick default, skip interview and use the Default Profile section. If user picks Guided setup, run the full questionnaire. ## Guided Questionnaire Ask questions in this order. Accept either selected options or free text. 1) App type - Example options: ecommerce, quick-commerce, rider, fintech, food-delivery, social, healthcare, custom. 2) Primary state management - Example options: riverpod, bloc, getx, provider, custom. 3) Additional state management (optional) - If multiple are chosen, keep one primary and isolate others by module. 4) Architecture style - Example options: feature-first clean, layered by type, simple starter. 5) Backend strategy - Example options: rest-api, firebase, supabase, hybrid. 6) API usage - Ask: Will this app consume external APIs? (yes/no) - If yes, ask for API style: rest, graphql, both. 7) Authentication - Example options: email-password, google, apple, phone-otp, guest. 8) Push notifications - Example options: firebase-fcm, onesignal, none. 9) Local persistence - Example options: shared-preferences, secure-storage, hive, isar, sqlite, none. 10) Realtime needs - Example options: websocket, firebase-realtime, none. 11) Payments (optional) - Example options: stripe, razorpay, sslcommerz, none. 12) Target platforms - Example options: android, ios, web, macos, windows, linux. 13) Flavors/environments - Example options: dev, staging, prod. 14) Tooling - Ask for optional setup: ci-cd, localization, accessibility baseline, analytics. 15) Starter screens - Ask if user wants 1 or 2 sample screens and which feature area. ## Quick Default Profile If user selects quick default, apply this baseline: - App type: ecommerce starter - Architecture: feature-first clean - Primary state management: riverpod - Backend: rest-api ready - API usage: yes, rest - Auth: email-password scaffold - Push: firebase-fcm ready - Local persistence: shared-preferences + secure-storage - Realtime: none - Payments: none - Platforms: android + ios - Flavors: dev + prod - Starter screens: splash + home catalog sample Always print a summary of applied defaults before generation. ## Decision Rules - If multiple state management options are requested, require one primary and place additional patterns in separate modules only. - Do not mix two state patterns inside the same feature module. - If backend=firebase and push=onesignal, allow both. - If backend=none and api=no, generate local/offline starter only. - If platforms include web, avoid mobile-only plugin setup in generated instructions. - If payments are enabled, scaffold abstraction layer and placeholder service only. ## Generation Contract After collecting requirements, generate the following: 1) Folder structure - core/ - config/ - shared/ - features/ - data/ - domain/ - presentation/ - routes/ 2) Core setup - app entry wiring - theme setup - route config - dependency injection bootstrap - environment/flavor config if requested 3) Dependencies - Add only required packages for selected options. - Group packages by: state, network, storage, push, auth, payments, utilities. 4) Starter implementation - Create 1-2 sample screens based on requested app type. - Add basic navigation between generated screens. - Include placeholder repository/service contracts. 5) Developer handoff output - Print: - selected options summary - generated directories/files summary - package summary - next 5 recommended implementation steps ## Validation Checklist Before completing, verify: - No contradictory choices remain unresolved. - Generated structure matches selected architecture. - Chosen state management is wired as primary. - Selected services (push/auth/storage) are reflected in dependencies and stubs. - At least one starter route and one starter screen exist. ## Failure Handling If requirements conflict or are incomplete: - Apply safe defaults for missing optional inputs. - For blocking conflicts, resolve with deterministic fallback: - state management fallback: riverpod - backend fallback: rest-api - push fallback: none - Continue generation and clearly report fallback decisions. ## Completion Output Template Use this format at the end: 1. Setup mode: guided | quick-default 2. Selected stack: 3. Generated artifacts: 4. Installed package groups: 5. Next steps: - Step 1 - Step 2 - Step 3 - Step 4 - Step 5 --- > Source: [mdazadhossain95/flutter-agent-skills](https://github.com/mdazadhossain95/flutter-agent-skills) — distributed by [TomeVault](https://tomevault.io).