Refine /create-app to place package more ergonomically (#66)

Author: gspencergoog

README.md

@@ -2,15 +2,15 @@
 
 Help Gemini CLI create, build, test, and run Flutter apps.
 
-*   **Status: Experimental** - This is an experimental project. Features and commands may change drastically. We welcome your feedback!
+- **Status: Experimental** - This is an experimental project. Features and commands may change drastically. We welcome your feedback!
 
 ## ✨ Features
 
--   **🚀 Project Bootstrapping**: Create new Flutter projects from scratch with built-in best practices, including linters, documentation, and design planning.
--   **🔧 Guided Refactoring**: Execute complex refactoring tasks with automated planning, git branch management, and step-by-step implementation guides for your approval.
--   **✅ Automated Pre-Commit Checks**: Automatically format, analyze, and test your code before committing to maintain codebase quality.
--   **✍️ Smart Commit Messaging**: Generate descriptive, conventional commit messages based on your staged changes.
--   **🧠 Context Priming**: Initializes Gemini with specific rules and context for Dart and Flutter, ensuring high-quality, idiomatic code generation.
+- **🚀 Project Bootstrapping**: Create new Flutter projects from scratch with built-in best practices, including linters, documentation, and design planning.
+- **🔧 Guided Refactoring**: Execute complex refactoring tasks with automated planning, git branch management, and step-by-step implementation guides for your approval.
+- **✅ Automated Pre-Commit Checks**: Automatically format, analyze, and test your code before committing to maintain codebase quality.
+- **✍️ Smart Commit Messaging**: Generate descriptive, conventional commit messages based on your staged changes.
+- **🧠 Context Priming**: Initializes Gemini with specific rules and context for Dart and Flutter, ensuring high-quality, idiomatic code generation.
 
 ## 📋 Prerequisites
 
@@ -25,9 +25,11 @@ Help Gemini CLI create, build, test, and run Flutter apps.
 Use the `gemini extensions install` command to install directly from the source repository:
 
 ```bash
-gemini extensions install https://github.com/gemini-cli-extensions/flutter.git
+gemini extensions install https://github.com/gemini-cli-extensions/flutter.git --auto-update
 ```
 
+The `--auto-update` is optional: if specified, it will update to new versions as they are released.
+
 You can manage the extension with the following commands:
 
 ```bash
@@ -42,9 +44,10 @@ gemini extensions uninstall flutter
 
 The new commands will be available in new Gemini CLI sessions. The following commands will be available (with or without the `flutter:` prefix):
 
--   `/create-app` - Guides you through bootstrapping a new Flutter project with best practices.
--   `/refactor` - Manages a structured refactoring session with automated planning.
--   `/commit` - Automates pre-commit checks and generates a descriptive commit message.
+- `/create-app` - Guides you through bootstrapping a new Flutter project with best practices.
+- `/create-package` - Guides you through bootstrapping a new Dart package with best practices.
+- `/refactor` - Manages a structured refactoring session with automated planning.
+- `/commit` - Automates pre-commit checks and generates a descriptive commit message.
 
 ## 💡 Usage
 
@@ -55,6 +58,7 @@ This extension provides powerful commands to automate key phases of the developm
 Initiates a guided process to bootstrap a new Flutter application, ensuring your project starts with a solid foundation.
 
 **Process:**
+
 1.  Asks for the package's purpose, details, and desired location on your filesystem.
 2.  Creates a new Flutter project with recommended settings and linter rules.
 3.  Generates starter `pubspec.yaml`, `README.md`, and `CHANGELOG.md` files.
@@ -69,6 +73,7 @@ Initiates a guided process to bootstrap a new Flutter application, ensuring your
 Starts a structured session to refactor existing code. It helps you plan and execute changes safely and efficiently.
 
 **Process:**
+
 1.  Asks for your high-level refactoring goals and what you want to accomplish.
 2.  Offers to create a new `git` branch for the refactoring work, isolating changes.
 3.  Generates a `REFACTOR.md` design document detailing the proposed changes.
@@ -83,6 +88,7 @@ Starts a structured session to refactor existing code. It helps you plan and exe
 Prepares your staged `git` changes for a clean, high-quality commit. It acts as an automated pre-commit hook and message generator.
 
 **Process:**
+
 1.  Runs `dart fix` and `dart format` to clean and format your code.
 2.  Executes the Dart analyzer to check for static analysis issues.
 3.  Runs your project's test suite to ensure all tests are passing.
@@ -96,8 +102,8 @@ Prepares your staged `git` changes for a clean, high-quality commit. It acts as
 
 This extension enforces a specific set of coding standards to ensure consistency and quality. These rules are defined in the extension's repository:
 
--   **`flutter.md`**: Contains rules and best practices for writing Dart and Flutter code. These rules are opinionated, and we encourage you to review them to ensure they align with your style.
--   **`override`**: Contains important, high-priority rules that are appended to the end of all prompts to ensure they have the most weight.
+- **`flutter.md`**: Contains rules and best practices for writing Dart and Flutter code. These rules are opinionated, and we encourage you to review them to ensure they align with your style.
+- **`override`**: Contains important, high-priority rules that are appended to the end of all prompts to ensure they have the most weight.
 
 ## 🐛 Troubleshooting
 

commands/create-app.toml

@@ -22,41 +22,54 @@ Next, collect remaining information from the user, one question at a time.
 The information you need to collect includes, but might not be limited to:
 
 - If there are ambiguous elements to the design, ask the user questions to clarify. When the goal is clear, or the user says to, then move on.
-- If the user didn't already give one, select a short descriptive name for the project.
-- Whether to do the work on the current git branch, or a new feature branch. Suggest a branch name.
+- If the user didn't already give one, select a short descriptive name for the package.
+- Whether to do the work on the current git branch, or a new feature branch.
+  - Suggest a branch name, making sure it is a valid git branch name.
+- Which directory to use as the package directory. Suggest a location.
+
+If the user wants the work done on a new branch, create the branch now.
+Then create the package directory, if it doesn't already exist.
+
+**VERY IMPORTANT**: Change directories to the package directory now so that future operations are relative to that directory.
 
 ## Design document
 
-Develop a **DETAILED** Markdown-formatted design document that follows all of the guidance you have about Dart and Flutter design patterns, rules, best practices, and core principles. Save the design document in DESIGN.md in the top directory of the new package. Feel free to use your available tools to research any aspects of the design that need clarification.
+Develop a **DETAILED** Markdown-formatted design document that follows all of the guidance you have about Dart and Flutter design patterns, rules, best practices, and core principles. Save the design document in DESIGN.md in the package directory. Feel free to use your available tools to research any aspects of the design that need clarification.
 
 The design doc should (at least) include sections for:
 
 - An overview
 - A detailed analysis of the goal or problem
 - Alternatives considered
 - A detailed design for the new package
-- Any diagrams needed to explain the design (in Mermaid format)
+- Any diagrams needed to explain the design, in Mermaid format.
+  - Be sure to put quotes around labels that include special characters (e.g. parenthesis).
 - A summary of the design
 - References to research URLs used to arrive at the design.
 
 You must ask the user to review this design document and they must approve it before you continue on to create the implementation plan. They must review and approve it first because if they ask for any changes, it may affect the implementation plan.
 
 ## Implementation plan
 
-After getting explicit approval from the user for the DESIGN.md document, Develop a **DETAILED** Markdown-formatted phased implementation plan of checkboxed tasks that need to be performed in order to finish developing the package. Save the implementation plan in IMPLEMENTATION.md in the top directory of the new package.
+After getting explicit approval from the user for the DESIGN.md document, Develop a **DETAILED** Markdown-formatted phased implementation plan of checkboxed tasks that need to be performed in order to finish developing the package. Save the implementation plan in IMPLEMENTATION.md in the package directory.
 
-The implementation plan should include a section for the "Journal" which will be updated after each phase.
+The implementation plan should include a section for a "Journal" which will be updated after each phase and contain a log of the actions taken, things learned, surprises, and deviations from the plan. It should be in chronological order.
 
 The plan should include instructions similar to: "After completing a task, if you added any TODOs to the code or didn't fully implement anything, make sure to add new tasks so that you can come back and complete them later." to prevent leaving tasks unfinished.
 
 In the first phase of the implementation plan, include:
 
-- [ ] Create a Dart or Flutter project (as appropriate for the purpose) in the desired location using the name. Unless the user specifies otherwise, the project should support all of the default platforms. Use the create_project tool to create it. For Flutter projects, create an empty project using the `empty` flag for the tool.
-- [ ] Remove the boilerplate in the new project by removing the test dir, if any, and the README.md file.
+- [ ] Create a Dart or Flutter package (as appropriate for the purpose) in the package directory.
+  - Unless the user specifies otherwise, the package should support all of the default platforms.
+  - Use the create_project tool to create the package.
+    - If the current directory is the package directory, use "." as the target for the create_project tool.
+    - The name of the package directory (even if it is the current directory) must be a valid Dart package name. If it isn't, then inform the user and suggest an alternative (valid) directory name.
+    - For Flutter packages, create an empty package using the `empty` flag for the tool.
+- [ ] Remove any boilerplate in the new package that will be replaced, including the test dir, if any.
 - [ ] Update the description of the package in the `pubspec.yaml` and set the version number to 0.1.0.
-- [ ] Update the README.md to include a short placeholder description of the project.
-- [ ] Update the CHANGELOG.md to have the initial version as 0.1.0.
-- [ ] Commit this empty version of the project to either a new branch or the current branch based on the user's preference.
+- [ ] Update the README.md to include a short placeholder description of the package.
+- [ ] Create the CHANGELOG.md to have the initial version of 0.1.0.
+- [ ] Commit this empty version of the package to either a new branch or the current branch based on the user's preference.
 
 The implementation plan should specify after each phase that you should:
 
@@ -66,13 +79,13 @@ The implementation plan should specify after each phase that you should:
 - [ ] Run any tests to make sure they all pass.
 - [ ] Run dart_format one more time to make sure that the formatting is still correct if you made any changes during the analysis and testing steps.
 - [ ] Re-read the IMPLEMENTATION.md file to see what, if anything, has changed in the implementation plan, and if it has changed, take care of anything the changes imply.
-- [ ] Update the IMPLEMENTATION.md file with the current state, including any learnings, surprises, or deviations in the Journal section.
+- [ ] Update the IMPLEMENTATION.md file with the current state, including any learnings, surprises, or deviations in the Journal section. Check off any checkboxes of items that have been completed.
 - [ ] Use `git diff` to verify the changes that have been made, and create a suitable commit message for any changes, following any guidelines you have about commit messages. Be sure to properly escape dollar signs and backticks, and present the change message to the user for approval.
 - [ ] Wait for approval. Don't commit the changes or move on to the next phase of implementation until the user approves the commit.
 
-In the last phase of the plan, you should include a step to create a comprehensive README.md file for the package.
+In the last phase of the plan, include a step to create a comprehensive README.md file for the package.
 
-You must ask the user to review this implementation plan and they must approve it before starting implementation. They must review and approve it before you begin because if they ask for any changes, they may affect the implementation.
+You must ask the user to review this implementation plan and they must approve it before starting implementation. They must review and approve it before you begin because if they ask for any changes, the changes may affect the implementation.
 
 ## Implementation