clone-template

name	clone-template
description	Scaffold a brand-new Flutter app from this template. Asks the user a small set of clarifying questions (app name, organisation, first feature), then runs `tool/clone_template.dart` and lays out the initial feature stubs in the new directory. Use this when the user says "start a new app from the template", "scaffold a new project", or similar.

clone-template

Drive tool/clone_template.dart interactively. The goal is a working sibling project, named correctly, with package + bundle identifiers rewritten and an initial feature scaffold in place.

When to invoke

Trigger on user phrases like:

• "scaffold a new app from this template"
• "clone the template into "
• "start a new Flutter project based on this template"

If the user is inside a project that already extends from this template (check for ARCHITECTURE.md referencing the 3-layer model, and a tool/clone_template.dart script), they probably do not want this skill — they want to add a feature instead.

Required information

Ask the user for these in one batched message (or infer from context):

1. App name — lower_snake_case, ≥ 2 chars, e.g. pulse_tracker.
2. Organisation reverse-DNS — e.g. com.example, dev.acme.
3. Destination directory — defaults to ../<app_name> (sibling of the template). Confirm with the user if there is any ambiguity.
4. Primary first feature — the one thing the app does on day one. A short phrase. Optional; default is to keep only home + dev/env_switcher.
5. Backend shape — REST/GraphQL/Firebase/none. Optional; default REST (the template already has dio wired).

Validate before running:

• App name matches ^[a-z][a-z0-9_]+$.
• Org matches ^[a-z][a-z0-9_]+(\.[a-z][a-z0-9_]+)+$.
• Destination does not yet exist.

Steps

1. Confirm intent. Echo the four pieces of info back to the user in one line and wait for an OK before mutating anything. Do not ask piecemeal.
2. Run the cloner:

   dart run tool/clone_template.dart --name <name> --org <org> --dest <dest>
   

   If --no-git or --no-pub-get is desired, pass them through.
3. Verify the result. Inside <dest>:
   • flutter pub get already ran (unless skipped).
   • dart run tool/check_architecture_violations.dart passes.
   • dart analyze passes.
4. Scaffold the first feature (if the user named one). Create:
   • lib/ui/features/<feature>/<feature>_page.dart (HookConsumerWidget, extending the page-owns-its-route convention).
   • lib/ui/features/<feature>/<feature>_notifier.dart (Riverpod AsyncNotifier or FutureProvider, depending on intent).
   • A matching DTO + repo stub in lib/data/ and a use-case stub in lib/domain/use_cases/ if the feature has a clear data dependency.
   • Add <FeaturePage>.route() to lib/ui/shared/router/app_routes.dart.
   • Make the FAB on HomePage navigate to the new feature (or delete the env-switcher entry-point if the user prefers).
5. Report. Tell the user the new path, how to run the app, and what to edit next (env files + repo endpoint).

Things to avoid

• Do not modify the original template directory. All edits happen in <dest>.
• Do not invent extra abstractions beyond what ARCHITECTURE.md describes. If the user asks for something the architecture forbids (e.g. registering use-cases in GetIt), push back and reference the doc.
• Do not skip the layer-boundary check. If it fails after scaffolding, fix the violation before reporting success.

Reference

Architecture lives in ARCHITECTURE.md of the template repo. Agent conventions live in AGENTS.md. Re-read them when in doubt.