/create-project

name: create-project
description: >
  Scaffold a new Dart or Flutter project from a Very Good CLI template, covering the
  flutter_app, dart_package, flutter_package, flutter_plugin, dart_cli, flame_game, and
  docs_site templates, inferring the right one from what the user wants to build and then
  installing dependencies. Use when the user says "create a new project", "start a new flutter
  app", "scaffold a package", "create a new package", "initialize a dart cli", "new flame
  game", or "generate a plugin". Use it for bare, vague, or under-specified scaffolding
  requests too — "create a new package for me", "make me a new app", "I need a new project",
  "set one up" — including ones that name no template, no project name, and no organization,
  or that only hint at what is being built. Missing or ambiguous details are a reason to use
  this skill, not a reason to skip it: it asks the clarifying questions and picks the
  template.
allowed-tools: mcp__very-good-cli__create mcp__very-good-cli__packages_get
argument-hint: "[template] [project-name]"

Create Project

Scaffold a new Dart or Flutter project using Very Good CLI templates.

> **Cross-harness fallbacks.** This skill drives the Very Good CLI MCP server and asks the user structured questions. On a host without this plugin's Bash hooks and without that MCP server connected, run the equivalent `very_good create …` and `very_good packages get` commands directly. On a host without `AskUserQuestion`, invoke whatever equivalent user-question tool the host provides; if it has none, ask the same questions as plain numbered text.

---

Core Standards

• **Use the Very Good CLI MCP server** to scaffold projects and install dependencies
• **Infer the template from context** — determine the right template based on what the user wants to build, not by asking them to pick a subcommand name
• **Use `AskUserQuestion` only for information you cannot infer** — project name and organization are the most common missing pieces
• **Install dependencies after creation**

---

Workflow

Step 1: Understand What the User Wants to Build

Infer the subcommand from the user's description — the available subcommands and their descriptions are defined by the Very Good CLI MCP server.

If the intent is ambiguous, use `AskUserQuestion` to clarify with a high-level question about what they're building — not which subcommand they want.

Step 2: Gather Missing Parameters

Use `AskUserQuestion` for what you cannot infer, in one call. Leave optional parameters (description, output directory, application ID) at their defaults unless the user raises them.

Step 3: Create and Set Up

1. Create the project using the Very Good CLI MCP server 2. Install dependencies using the Very Good CLI MCP server — pass `directory: '<path-to-created-project>'` to `packages_get` so it runs against the new project, not the workspace root

---

Key Domain Knowledge

• Use `dart_package` (not `flutter_package`) for data layer and repository layer packages in the **layered-architecture** pattern — these must not depend on Flutter SDK
• If a user provides a project name with dashes, convert to underscores — Dart package names only allow lowercase letters, numbers, and underscores
• Templates that produce apps, plugins, or games require an organization name — do not skip this or it defaults to a placeholder value
• If `packages_get` fails after creation, check that `directory` points at the new project and that the Dart SDK is on `PATH`

---

Anti-Patterns

| 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 |