원클릭으로
vgv-create-project
// Scaffold a new Dart or Flutter project from a Very Good CLI template. Supports flutter_app, dart_package, flutter_package, flutter_plugin, dart_cli, flame_game, and docs_site templates.
// Scaffold a new Dart or Flutter project from a Very Good CLI template. Supports flutter_app, dart_package, flutter_package, flutter_plugin, dart_cli, flame_game, and docs_site templates.
| name | vgv-create-project |
| description | Scaffold a new Dart or Flutter project from a Very Good CLI template. Supports flutter_app, dart_package, flutter_package, flutter_plugin, dart_cli, flame_game, and docs_site templates. |
| when_to_use | Use when user says "create a new project", "start a new flutter app", "scaffold a package", "initialize a dart cli", "new flame game", or "generate a plugin". |
| allowed-tools | mcp__very-good-cli__create mcp__very-good-cli__packages_get |
| argument-hint | [template] [project-name] |
| model | haiku |
Scaffold a new Dart or Flutter project using Very Good CLI templates.
AskUserQuestion only for information you cannot infer — project name and organization are the most common missing piecesInfer the subcommand from the user's description — the available subcommands and their descriptions are defined by the Very Good CLI MCP server. Do NOT ask users to pick a subcommand name — figure it out from context.
If the intent is ambiguous, use AskUserQuestion to clarify with a high-level question about what they're building — not which subcommand they want.
Use AskUserQuestion to collect only what you cannot infer. Batch questions into a single call when possible. Do NOT ask for optional parameters (description, output directory, application ID, etc.) unless the user brings them up.
directory: '<path-to-created-project>' to packages_get so it runs against the new project, not the workspace rootdart_package (not flutter_package) for data layer and repository layer packages in the layered-architecture pattern — these must not depend on Flutter SDKflutter_appdart_package, name weather_api_client, output packages/my-app to my_appdirectory: '<path-to-created-project>' to packages_get so it targets the new project| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Asking user to pick a template name | Users think in terms of what they're building, not CLI subcommands | Infer the template from context |
| Over-asking for optional parameters | Slows down the workflow | Only ask for what you cannot infer |
Using flutter_package for a data layer | Adds unnecessary Flutter SDK dependency | Use dart_package for data and repository layer packages |
| Skipping organization name for apps/plugins | Defaults to a placeholder value | Ask when the template requires it |
Audit or remediate Flutter widgets against WCAG 2.2 accessibility conformance levels A, AA, or AAA across iOS, Android, Web, macOS, Windows, and Linux.
VGV-specific reference for bumping Dart and Flutter SDK constraints across packages. Covers pubspec.yaml environment constraints, CI workflow Flutter versions, and SDK upgrade PR preparation. CI uses ^MAJOR.MINOR.x to resolve to the latest patch; pubspec pins the exact patch version (e.g., ^3.50.1).
Best practices for Flutter animations using the built-in animation framework. Use when creating, modifying, or reviewing animations, transitions, motion, or animated widgets. Covers implicit animations, explicit animations, page transitions, and Material 3 motion tokens.
Best practices for Dart unit tests, Flutter widget tests, and golden file tests.
Best practices for VGV layered monorepo architecture in Flutter.
Audits package dependency licenses using the Very Good CLI packages_check_licenses MCP tool. Flags non-compliant or unknown licenses and produces a compliance summary.