Flutter prompts for widgets, state, performance and tests

The best Flutter prompts give the model your Flutter version, target platforms and current state management approach, paste the real widget code and analyzer or console output, and ask for one specific change. Below are 12 Flutter prompts for ChatGPT, Claude, Claude Code and Codex covering widgets, architecture, async safety, performance, platform code and testing.

For general jobs such as explaining code or writing a commit message, see the coding prompts. If you also write native code, the Swift prompts and Kotlin prompts cover iOS and Android directly.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{state_approach:the one already in this code}} means the model should keep your existing approach unless you name another.

Three habits make the answers better:

• Give your version. The Flutter release notes list 3.47.0 as the latest stable release as of October 2026. Breaking changes land between releases, so paste the output of flutter --version.
• Name your state approach. If you don't, the model may rewrite your app around a library you don't use.
• Paste analyzer output. flutter analyze warnings carry lint names and line numbers the model can act on.

In an agent, let it run flutter analyze and flutter test itself and report the results.

How do you build Flutter widgets with AI?

1. Build a screen from a description

For a first version of a screen. Asking for small widget classes keeps it easy to change and cheaper to rebuild.

Build a Flutter screen for {{feature:a product detail page with an image carousel and an add to cart button}}.

Flutter version: {{flutter_version:3.47}}. Platforms: {{platforms:iOS and Android}}.

- Split the UI into small StatelessWidget classes, not helper functions that return widgets.
- Use const constructors wherever possible.
- Use Theme.of(context) for colors and text styles; no hardcoded colors.
- Keep business logic out of the widgets; take data and callbacks as constructor parameters.
- Make it work on small phones and tablets without overflow.

Use only the Flutter SDK unless I approve a package. List any assumption about the data.

2. Split a large build method

For a widget whose build() runs to hundreds of lines. Flutter's performance best practices advise splitting large widgets by how they change, and say: "To create reusable pieces of UIs, prefer using a StatelessWidget rather than a function."

This Flutter widget has a build method that is too large:

{{code}}

Split it into smaller widgets:
- Group parts by how often they change, so a setState in one part does not rebuild the rest.
- Turn helper methods that return widgets into StatelessWidget or StatefulWidget classes.
- Move setState calls down to the smallest widget that owns the changing state.
- Keep behavior and appearance exactly the same.

Show the new widget tree as a short outline before the code.

3. Fix a layout overflow

For the yellow and black overflow stripes or an unbounded height error.

My Flutter layout shows this error:

{{error:A RenderFlex overflowed by 42 pixels on the bottom.}}

Widget code:
{{code}}

Explain which widget gets constraints it cannot satisfy and why, in terms of constraints going down and sizes going up. Then give the smallest fix (Expanded, Flexible, scrolling, or a size limit) and explain why it is the right one here. Do not wrap everything in a SingleChildScrollView unless scrolling is actually the intended behavior.

How do you structure state and architecture?

4. Refactor a screen to MVVM

For a screen where widgets call APIs directly. Flutter's architecture guide recommends views, view models, repositories and services, and says: "Separation-of-concerns is the most important principle to follow when designing your Flutter app."

Refactor this Flutter feature to follow the layers in Flutter's architecture guide.

{{code}}

- View: widgets only, with no business logic beyond simple show/hide, layout and routing.
- View model: turns repository data into UI state and exposes commands for user actions.
- Repository: the source of truth for this data, with caching, error handling and retry.
- Service: wraps the API or plugin, holds no state, returns Future or Stream.

Keep using {{state_approach:the state management already in this code}} to connect the view to the view model. Show the files you would create and the code for each.

5. Fix BuildContext used across an async gap

For the use_build_context_synchronously lint. The Dart lint docs state the rule as "Do not use BuildContext across asynchronous gaps."

flutter analyze reports use_build_context_synchronously in this code:

{{code}}

For each await followed by a use of context:
- Explain what can go wrong if the widget is disposed during the await.
- Fix it with the right mounted check: the State's mounted property when using the State's context, or context.mounted for a context passed in as a parameter.
- Where possible, read what you need from context (Navigator, ScaffoldMessenger, Theme) before the await instead.

Do not silence the lint with an ignore comment.

6. Model loading, data and error states

For screens that juggle nullable fields and Bool flags. Dart's sealed classes and switch expressions make each state explicit.

This Flutter screen tracks {{feature:loading a list of orders}} with several nullable fields and bool flags:

{{code}}

Redesign the state as a sealed class with one subclass per state (for example loading, loaded with data, empty, error with message). Show how the view model emits it and how the widget renders it with an exhaustive switch expression. Explain any state you added or merged.

How do you fix Flutter performance problems?

7. Diagnose jank in a screen

For dropped frames while scrolling or animating. The performance guide notes that on a 60Hz display you have 16ms for building and 16ms for rendering each frame.

This Flutter screen janks when {{action:scrolling the feed}}.

Code:
{{code}}

What I measured in profile mode (DevTools frame chart, if I have it):
{{measurements:not measured yet}}

Check for: expensive work inside build methods, setState called high in the tree, Opacity or clipping inside animations, widgets that trigger saveLayer, intrinsic layout passes, and images decoded at full size.

Rank the likely causes, show a fix for each, and tell me exactly what to look at in DevTools to confirm.

8. Make a long list lazy

For a Column or ListView built from a full list of children. Flutter's docs say to use the lazy builder methods so "only the visible portion of the screen is built at startup time."

This Flutter list renders {{count:2,000}} items and is slow to open:

{{code}}

Rewrite it with a lazy builder (ListView.builder, ListView.separated, GridView.builder or slivers as appropriate).
- Give items stable keys if they can be reordered, inserted or removed.
- Keep each item widget const where possible.
- Add pagination that loads {{page_size:50}} more items near the end of the list.

Explain what changes in memory use and build cost.

How do you call native platform code?

9. Replace a MethodChannel with Pigeon

For platform channel code that breaks when someone renames a method. The platform channels docs say MethodChannel "is not type safe" and suggest the Pigeon package to generate type-safe messaging code.

Replace this MethodChannel code with Pigeon.

Dart side:
{{dart_code}}

Native side ({{native:Kotlin and Swift}}):
{{native_code}}

1. Write the Pigeon definition file with the API and data classes.
2. Show the Pigeon command to generate the code.
3. Show the Dart call site and the native implementations using the generated interfaces.
4. Make sure native handlers run on the platform's main thread unless the work is heavy, and say where you used a background thread.

How do you test Flutter apps with AI?

10. Write widget tests

For screens and components. Flutter's testing overview describes a widget test as one that verifies "the widget's UI looks and interacts as expected."

Write widget tests for this Flutter widget using flutter_test.

{{code}}

- Pump the widget inside the minimum app wrapper it needs (MaterialApp, theme, providers).
- Use fakes for repositories and services, not real network calls.
- Cover: initial render, each user interaction, loading, empty and error states.
- Find widgets by key or semantics label rather than by text that might be translated.
- Use pumpAndSettle only where an animation must finish, and explain each use.

11. Write an integration test for a critical flow

For the few flows that must never break, such as sign-in or checkout. The testing overview notes that the SDK's integration_test package cannot interact with native UI such as permission dialogs.

Write an integration test for this flow in my Flutter app: {{flow:sign in, add an item to the cart, check out}}.

Relevant screens and keys:
{{code}}

- Use the integration_test package and flutter_test.
- Use a test backend or fakes injected at startup, not production services.
- Tell me which steps involve native UI (permission dialogs, system sheets) that integration_test cannot tap, and how to work around each one.
- Give the command to run it on a connected device or emulator.

12. Review a screen for accessibility

For a screen before release. Flutter's accessibility docs say tappable targets should be at least 48x48 pixels, recommend a contrast ratio of at least 4.5:1, and ask you to test with TalkBack and VoiceOver.

Review this Flutter screen for accessibility.

{{code}}

Check:
- Every interactive widget has a meaningful semantics label, and decorative images are excluded from semantics.
- Tap targets are at least 48x48.
- Text and controls have at least 4.5:1 contrast with the background.
- The layout still works at very large text scale factors.

For each issue, show the code fix and say how to verify it with TalkBack on Android and VoiceOver on iOS.

What should you check before you accept the answer?

AI-written Flutter code tends to fail in the same few places:

• New packages. Check every package the model added on pub.dev before you accept it. The SDK often covers the need.
• A different state approach. If the answer switched state libraries without being asked, reject it and restate yours.
• Context after await. Search the diff for await followed by context with no mounted check.
• Real results. Run flutter analyze and flutter test yourself, or have an agent run them and paste the output.

For a deeper accessibility pass, the accessibility prompts work for Flutter screens too.

How do you keep your best Flutter prompts?

Once a prompt becomes a habit, turn it into a skill so Claude Code or Codex uses it without being asked. The build method split and the async gap fix are good first candidates. Paste one into the free SKILL.md generator, which runs in the browser with no sign-up, and it becomes a valid SKILL.md.

To keep prompts like these close, save them in Kipt. Your library lives as Markdown in a private GitHub repo you own, each blank stays fillable when you copy, and Cmd+K finds any prompt by name or tag. For more test prompts, see the unit test prompts.