[Skill idea] flutter-scaffold-mvvm-feature — generate a complete MVVM feature in one shot

Start by reviewing the existing flutter-apply-architecture-best-practices skill and how skills are structured in this repository. Define the generation flow around the listed inputs and outputs, then verify that a generated feature includes the Page, ViewModel, Status, optional Effect, route export, DI registration, and ViewModel unit-test stub consistently.

Environment

• Language model: Claude Opus 4.7
• Agent harness: Claude Code
• Project type: Production Flutter app (logistics / driver-facing), strict MVVM

The current flutter-apply-architecture-best-practices skill is educational — it teaches the layered MVVM pattern. What's missing is a generative counterpart that scaffolds a full feature end-to-end: Page + ViewModel + Status + (optional) Effect + Route + DI registration + unit test, all wired and consistent.

Today, generating a new feature in a strict-MVVM app is a 10–15 file edit dance that's easy to get inconsistent (route variant wrong, DI not registered, ViewModel imports flutter/material, test missing mocks). A single skill that drives this correctly removes a recurring source of drift.

Proposed skill

Name: flutter-scaffold-mvvm-feature

Description (draft):

Scaffold a complete MVVM feature (Page, ViewModel, Status, optional Effect, Route, DI registration, and unit test) wired consistently across layers. Use when adding a new screen, sheet, or dialog to an app that already follows the MVVM pattern, to guarantee correct layer separation and DI on first generation.

Inputs the skill should ask upfront (in a single batch):

1. Feature name (snake_case)
2. Page type (full-screen / bottom-sheet / dialog)
3. Needs Effects? (snackbars, async navigation events)
4. Needs offline/connectivity awareness?
5. Domain model the page receives (or none)
6. Initial Status fields

Outputs:

• lib/features/{name}/{name}_page.dart
• lib/features/{name}/{name}_view_model.dart
• lib/features/{name}/{name}_status.dart
• lib/features/{name}/{name}_effect.dart (only if Effects needed)
• Route file + export
• DI factory registration
• Unit test stub for the ViewModel

Why this is hard for a single-pass skill

Layer-correct generation benefits from parallel sub-agents (one per layer: data/VM, UI, tests) so the skill can produce 5–7 files coherently in one turn. We've implemented this pattern internally and it works well — happy to share the orchestration approach if useful.

Real-world reference

We run an internal version of this in production (Claude Code, ~9k LOC monthly throughput). Generation success rate (no follow-up edit needed) is materially higher than per-file generation.

Roadmap fit

This complements flutter-apply-architecture-best-practices (P1, already published) — that one teaches the pattern, this one applies it.