Very Good CLI: Dart and Flutter project templates, tests and license checks in one command

The blank-repository problem Very Good CLI is built to remove

Starting a Dart or Flutter project by hand means writing a pubspec, choosing analysis options, wiring a test runner, and deciding on a folder layout. Every team does this slightly differently, and the differences surface later as merge friction and inconsistent lint rules. Very Good CLI packages those decisions into named templates. The README lists eight create subcommands: app_ui_package, dart_cli, dart_package, docs_site, flame_game, flutter_app, flutter_package, and flutter_plugin. The audience is Dart and Flutter developers who want the same starting point across repositories, and CI environments that need to generate a project non-interactively. It is not a framework. It does not add runtime code to your app; what it produces is files, and those files are what you then maintain.

How the create subcommands and the rest of the tool fit together

The CLI is a Dart package installed globally, with the entry point under bin/ and templates stored as bricks, a term from the Mason templating system that also appears as mason.yaml in the repository root. The templates are not compiled into the binary as strings; they are brick definitions that get rendered with your arguments. That explains why flags like --desc, --org, --application-id, --executable-name and --platforms exist per subcommand rather than globally: each brick declares the variables it needs. Around the scaffolding sit three other command groups. `very_good test` wraps test execution and can enforce a coverage floor. `very_good packages get` fetches dependencies, optionally across a directory tree. `very_good packages check licenses` reads the resolved dependency graph and reports or filters by license identifier. A newer `very_good mcp` command exposes create, tests, packages_check_licenses and packages_get as Model Context Protocol tools, which the README explicitly labels experimental and tied to the Dart MCP Server. Treat that last one as a preview surface, not a stable interface.

Installing Very Good CLI and generating your first Flutter app

Installation is a single global activation through the Dart pub tool. The README gives this as the primary path, and notes you may need to set up your PATH afterwards so the `very_good` executable resolves.

dart pub global activate very_good_cli

If you need to pin a release, the README shows appending a version taken from the pub.dev versions page. In CI containers where global activation is not possible, the documented fallback is to invoke the package directly.

dart pub global run very_good_cli:very_good <command> <args>

Creating a project then takes one line plus whatever metadata you want to override. The example below sets the description and the organization used for the bundle identifier.

very_good create flutter_app my_app --desc "My new Flutter app" --org "com.custom.org"

After it finishes you should have a directory named my_app containing the generated project. The README does not document a dry-run flag for create, so inspect the output directory before wiring it into anything automated. Running tests with a hard coverage threshold is the other command most teams adopt early.

very_good test --coverage --min-coverage 100

What the license check actually reports, and where it stops

The license command is the least glamorous part of the tool and probably the most useful in a regulated codebase. It reads package licenses and lets you allow or deny by SPDX-style identifier. The README shows an allowlist, a denylist, a dependency-type filter and a CSV reporter.

very_good packages check licenses --allowed="MIT,BSD-3-Clause,BSD-2-Clause,Apache-2.0"

The `--forbidden="unknown"` example is telling: unknown licenses are the case teams actually get bitten by, and the tool lets you fail the build on them. The `--dependency-type="direct-main,transitive"` filter matters because transitive dependencies are where surprising licenses hide. What the command does not do is interpret your obligations. It reports identifiers; it does not tell you whether an Apache-2.0 dependency in a shipped binary requires a NOTICE file. That judgement stays with you. The README also does not describe how the tool resolves a package that ships no license file beyond classifying it, so expect to investigate the unknown bucket manually rather than assume the report is exhaustive.

Where Very Good CLI is the wrong tool

The templates are opinionated and the CLI gives you no supported way to fork them in place. If your team's conventions diverge from the generated layout, you will either edit every generated project afterwards or maintain your own brick, and the README does not document a mechanism for pointing create at a custom template. The second boundary is scope. This is a scaffolding and test-runner wrapper, not a build or release system; there is no command here for producing artifacts or publishing. Third, `very_good mcp` is flagged experimental in the README and depends on an external Dart MCP Server that the documentation says may change or become unstable without notice, so building an internal workflow on those four MCP tools is a bet on an interface the project itself declines to guarantee. Finally, if you are not on Dart or Flutter, none of this applies to you.

Mason compared with Very Good CLI

Mason is the templating engine underneath, and the difference is one of packaging. Mason gives you the brick format and a `mason make` command; you supply the template, the variables and the prompts. Very Good CLI ships a fixed set of eight bricks behind named subcommands with curated flags, so you get a working Flutter app or Dart package without authoring anything. The trade runs the other way too: with Mason you can publish and version your own bricks and compose them, while Very Good CLI's templates are the ones the maintainers chose. A team with strong internal conventions usually ends up on Mason directly; a team that wants a good default today installs Very Good CLI. They are not mutually exclusive, since the repository itself carries a mason.yaml, which is a reasonable hint about how the two relate.

Maintenance cadence, licence and upgrade cost

The repository is not archived, and its last push was on 2026-09-28. Releases are frequent: v1.5.0 on 2026-09-08, v1.4.0 on 2026-08-10, v1.3.0 on 2026-06-29. The presence of .release-please-config.json and .release-please-manifest.json indicates automated release management, so version bumps follow a configured rather than manual rhythm. The project is MIT licensed, which permits commercial use and modification; the usual MIT condition is that the copyright notice and permission notice travel with copies or substantial portions. That is a statement about the licence text, not advice about your obligations. The upgrade cost worth planning for is regeneration: when a template changes between versions, existing projects in your organisation do not update themselves, and the README documents no migration command. Pinning a version per team, as the README's specific-version install shows, keeps generated projects comparable.

Editorial conclusion

Adopt Very Good CLI if you want a repeatable project skeleton and a coverage gate in CI, and you are already on Dart or Flutter. Skip it if you need a build system, a release pipeline, or a template that differs from the eight subcommands it ships. Before committing, run `very_good create dart_package my_pkg` in a scratch directory and read the generated pubspec, analysis_options.yaml and CI files, because those files are the actual contract you are accepting, not the CLI itself.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. VeryGoodOpenSource/very_good_cli on GitHub