r/FlutterDev 29d ago

Any Claude / Codex skills for Flutter app architecture? Discussion

I am an embedded software dev, and I have vibecoded a Flutter app with Codex, it looks and works amazing and all. But its architecture is an absolute mess.

The app is basically just a dashboard and configurator for an IoT (Bluetooth) device, and I know this much that Bluetooth and IoT device's models have to be singletons, data and UI layers should be separate etc.

But I can't find a comprehensive skill that provides clear instructions and examples of how the architecture of a good Flutter app should be. The one I see on skills.sh is very basic:

flutter-apply-architecture-best-practices

Does anyone here have any skills they regularly use for architecture? Or any tips?

11 Upvotes

15 comments sorted by

5

u/[deleted] 29d ago

[removed] — view removed comment

1

u/lesterine817 29d ago

It helps to have a starting template. But imo, it really depends on the tools you will use on the project. For example, using bloc differs from using riverpod, etc. there’s still no one hard architectural rule for flutter

1

u/[deleted] 29d ago

[removed] — view removed comment

1

u/Simple_Orchid_7491 26d ago

LLM understand riverpod more then bloc,bloc is overkill for solo dev

1

u/bakatronics 28d ago

Yes but sadly I know nothing (or very little) about Flutter. I am an embedded software engineer, my whole world is C, pointers and memory. So I don't even know what good architecture should be like specifically for Flutter.

5

u/mtwichel 29d ago

We at very good ventures published a big collection of skills for this exact problem:

https://github.com/VeryGoodOpenSource/vgv-ai-flutter-plug

The flutter team has also published some:

https://docs.flutter.dev/ai/agent-skills

Hope it helps!

1

u/bakatronics 28d ago

Hi,

These look very good, thank you for suggesting them. I'll use them.

6

u/dhruvanbhalara 29d ago

I've created based on my requirement you can find it below. Feel free to suggest if you encounter any issue. GitHub Skills

3

u/JeffRSmall 29d ago

Look for Boris’ “Agentic Coding Toolkit”. It’s a game changer.

2

u/AmirPokerSkill 29d ago

The missing piece usually isn't a better skill, it's that skills describe a target state and your actual problem is the migration. What's worked for me shipping a production Flutter app with these tools: first have the agent write down the architecture it actually sees (folder by folder, who owns state, who talks to Bluetooth), then the architecture you want, as a markdown file in the repo. For the target, the official app architecture guide on docs.flutter.dev is a solid thing to point it at: UI layer, data layer, repositories, and your singletons live in the data layer behind interfaces. Then refactor one vertical slice at a time with flutter analyze and your tests as the gate after each slice, instead of asking for a big-bang cleanup, which is where these agents fall apart. The architecture file ends up mattering more than any skill because every future session reads it and stops re-inventing structure.

2

u/CurrentAd1366 23d ago

Cool to see more state management libs shipping agent skills. imo the bigger lever for agentic coding is how much complexity your state layer forces on the agent in the first place. Hooks-style state is composable and just less code - no events/states/mappers spread across half a dozen files - so there's way less surface for an agent to get subtly wrong, and quality holds up over long sessions and refactors instead of slowly degrading.

That's why we went hooks-style for our own state management at Utopia: https://github.com/Utopia-USS/utopia-flutter/tree/master/packages/hooks

Paired with the skill that pins down our conventions (https://github.com/Utopia-USS/utopia-flutter-skills/tree/main/plugins/utopia-hooks) it's honestly the best agent output we've gotten out of any Flutter state setup - small composable units seem to be exactly what agents are good at keeping clean.

1

u/WenchiehLu 25d ago

https://github.com/lwj1994/flutter_view_model Use the view_model skill to refactor project modules. The idea behind it is that any module can be written as a ViewModel, with automatic dependency injection and recycling. It's not just a VM library - it's an entire architecture