本文へ移動
cccskills
無料GitHub で公開

flutter-dev

Build Flutter/Dart cross-platform apps with widgets, state management, navigation, tests, and performance patterns.

インストール方法を見る

含まれるファイル(13)

  • SKILL.md8.4 KB
  • references/animations.md12.6 KB
  • references/bloc-state.md6.6 KB
  • references/forms.md17.0 KB
  • references/gorouter-navigation.md6.1 KB
  • references/localization.md11.7 KB
  • references/networking.md13.6 KB
  • references/performance.md6.5 KB
  • references/platform-specific.md10.8 KB
  • references/project-structure.md6.5 KB
  • references/riverpod-state.md5.3 KB
  • references/testing.md8.4 KB
  • references/widget-patterns.md5.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Flutter Development Guide

A practical guide for building cross-platform applications with Flutter 3 and Dart. Focuses on proven patterns, state management, and performance optimization.

Routing Boundary

Use this skill for Flutter/Dart apps, widgets, Riverpod/Bloc, GoRouter, Flutter performance, and Flutter tests. Use android-native-dev for native Android/Kotlin, ios-application-dev for native iOS/Swift, react-native-dev for React Native/Expo, and web frontend skills for browser React/Next/Vue work.

Quick Reference

Implementation Workflow

  1. Inspect project shape: identify Flutter version, pubspec.yaml dependencies, state package, router, existing feature folders, and nearest tests before editing.
  2. Choose the pattern using the decision tables below; do not introduce Riverpod, Bloc, GoRouter, or Hooks into a project that already uses another working pattern unless the task explicitly asks for that migration.
  3. Implement the complete vertical slice: model/state first, route or widget entry point second, UI states third (loading, empty, error, success), then platform-specific hooks only if required.
  4. Verify locally: run the narrowest available command first, usually flutter test <target> for logic/widgets, then flutter analyze, then flutter run --profile only for performance work.
  5. Report evidence: name changed widgets/providers/routes, state the verification command, and mark any skipped platform check as Unverified.

🔴 CHECKPOINT · 🛑 STOP before a state-management or router change if it would migrate existing app architecture, affect deep links/auth redirects, or require adding packages. Ask for approval instead of silently replacing the project pattern.

State and Routing Decisions

NeedUseDo not use
Local ephemeral UI stateStatefulWidget, useState, or local StateProvider matching the projectGlobal provider for one text field or toggle
Shared synchronous app stateRiverpod NotifierProvider or existing Bloc/CubitDirect mutable singleton state
Async/server stateAsyncNotifierProvider, FutureProvider, or existing repository + BlocManual isLoading booleans spread across widgets
Event-heavy workflowBloc/Cubit when already present or explicitly requestedBloc for simple derived display state
Auth-aware navigationExisting GoRouter redirect/auth guard patternImperative pushes from random widgets
Feature navigation onlyExisting route declarations plus typed route namesAd-hoc string paths duplicated in widgets

Failure Modes and Fallbacks

TriggerFirst responseIf still failing
flutter pub get failsInspect SDK/package constraints in pubspec.yaml; keep existing versions unless task allows dependency changesReport dependency conflict; do not upgrade packages unasked
Widget test cannot pump route/providerWrap the widget with the same app-level providers/router used by nearby testsAdd a minimal test harness in the test file only if adjacent tests already do this
Auth redirect loopsTrace redirect conditions and provider loading state; ensure loading returns null redirectStop and report route/auth ambiguity before changing public navigation
Rebuild jank persistsUse DevTools/rebuild logging to identify the specific provider/widget; apply select() or const locallyMark performance result Unverified if profile evidence is unavailable
Platform-specific behavior differsCheck Platform/plugin usage and run the relevant simulator/emulator if availableReport the unverified platform instead of assuming parity

Do Not Do This

  • Do not add a new state-management framework just to satisfy a small widget task.
  • Do not replace existing Navigator/GoRouter architecture without explicit migration scope.
  • Do not optimize performance from intuition only; require profiling, rebuild counts, or a concrete failing scenario.
  • Do not hide loading/error states to make UI code shorter.
  • Do not add packages, generated code, or platform folders unless the task explicitly requires them.

Widget Patterns

PurposeComponent
State management (simple)StateProvider + ConsumerWidget
State management (complex)NotifierProvider / Bloc
Async dataFutureProvider / AsyncNotifierProvider
Real-time streamsStreamProvider
NavigationGoRouter + context.go/push
Responsive layoutLayoutBuilder + breakpoints
List displayListView.builder
Complex scrollingCustomScrollView + Slivers
HooksHookWidget + useState/useEffect
FormsForm + TextFormField + validation

Performance Patterns

PurposeSolution
Prevent rebuildsconst constructors
Selective updatesref.watch(provider.select(...))
Isolate repaintsRepaintBoundary
Lazy listsListView.builder
Heavy computationcompute() isolate
Image cachingcached_network_image

Core Principles

Widget Optimization

  • Use const constructors wherever possible
  • Extract static widgets to separate const classes
  • Use Key for list items (ValueKey, ObjectKey)
  • Prefer ConsumerWidget over StatefulWidget for state

State Management

  • Riverpod for dependency injection and simple state
  • Bloc/Cubit for event-driven workflows and complex logic
  • Never mutate state directly (create new instances)
  • Use select() to minimize rebuilds

Layout

  • 8pt spacing increments (8, 16, 24, 32, 48)
  • Responsive breakpoints: mobile (<650), tablet (650-1100), desktop (>1100)
  • Support all screen sizes with flexible layouts
  • Follow Material 3 / Cupertino design guidelines

Performance

  • Profile with DevTools before optimizing
  • Target <16ms frame time for 60fps
  • Use RepaintBoundary for complex animations
  • Offload heavy work with compute()

Checklist

Widget Best Practices

  • const constructors on all static widgets
  • Proper Key on list items
  • ConsumerWidget for state-dependent widgets
  • No widget building inside build() method
  • Extract reusable widgets to separate files

State Management

  • Immutable state objects
  • select() for granular rebuilds
  • Proper provider scoping
  • Dispose controllers and subscriptions
  • Handle loading/error states

Navigation

  • GoRouter with typed routes
  • Auth guards via redirect
  • Deep linking support
  • State preservation across routes

Performance

  • Profile mode testing (flutter run --profile)
  • <16ms frame rendering time
  • No unnecessary rebuilds (DevTools check)
  • Images cached and resized
  • Heavy computation in isolates

Testing

  • Widget tests for UI components
  • Unit tests for business logic
  • Integration tests for user flows
  • Bloc tests with blocTest()

References

TopicReference
Widget patterns, const optimization, responsive layoutWidget Patterns
Riverpod providers, notifiers, async stateRiverpod State Management
Bloc, Cubit, event-driven stateBloc State Management
GoRouter setup, routes, deep linkingGoRouter Navigation
Feature-based structure, dependenciesProject Structure
Profiling, const optimization, DevToolsPerformance Optimization
Widget tests, integration tests, mockingTesting Strategies
iOS/Android/Web specific implementationsPlatform Integration
Implicit/explicit animations, Hero, transitionsAnimations
Dio, interceptors, error handling, cachingNetworking
Form validation, FormField, input formattersForms
i18n, flutter_localizations, intlLocalization

Flutter, Dart, Material Design, and Cupertino are trademarks of Google LLC and Apple Inc. respectively. Riverpod, Bloc, and GoRouter are open-source packages by their respective maintainers.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Review a single academic paper, preprint, DOI, arXiv link, or user-provided PDF/text with source-grounded critique. Use for paper summaries, methodology review, novelty checks, reproducibility concerns, or "review this paper" requests; do not use for multi-paper surveys, systematic literature reviews, citation management, or implementation from a paper.

日本語の概要は準備中です。原文の説明を表示しています。

Rosetears520/aili-workflows22026年9月27日 更新

AI regression scouting routing. Use when agents, prompts, skills, model/tool routing, harness fixtures, or generated-output expectations change and need regression scenarios; do not use for ordinary product-code regressions.

日本語の概要は準備中です。原文の説明を表示しています。

Rosetears520/aili-workflows22026年9月27日 更新

Run the AILI delivery lifecycle from natural-language IDEATE, DEFINE, BUILD, and SHIP intent or the equivalent slash shortcuts; use for idea shaping, spec/test definition, bounded BUILD package queues, review-repair closeout, or adapter routing without exposing internal stage commands.

日本語の概要は準備中です。原文の説明を表示しています。

Rosetears520/aili-workflows22026年9月27日 更新

Android native Kotlin/Compose app development, Material 3 UI, accessibility, and Gradle builds.

日本語の概要は準備中です。原文の説明を表示しています。

Rosetears520/aili-workflows22026年9月27日 更新

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

日本語の概要は準備中です。原文の説明を表示しています。

Rosetears520/aili-workflows22026年9月27日 更新

Route an explicitly requested independent/delegated browser QA assignment or durable E2E evidence need; do not trigger for direct Playwright/DOM/console/network inspection, ordinary UI implementation, backend-only work, or production-mutating flows.

日本語の概要は準備中です。原文の説明を表示しています。

Rosetears520/aili-workflows22026年9月27日 更新

Rosetears520 のスキルをすべて見る

このスキルの問題を報告する