Merge pull request #143 from gemini-cli-extensions/fix/bug-fixes

refactor: Streamline interactive prompts and remove redundant announcements

Author: moisgobg

commands/conductor/implement.toml

@@ -117,7 +117,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     b.  **Update Product Definition:**
         i. **Condition for Update:** Based on your analysis, you MUST determine if the completed feature or bug fix significantly impacts the description of the product itself.
         ii. **Propose and Confirm Changes:** If an update is needed:
-            -   **Announce:** Briefly state that updates are proposed. Do NOT repeat the request to review in the chat.
             -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed updates (in a diff format) directly into the `question` field so the user can review them in context.
                 - **questions:**
                     - **header:** "Product"
@@ -132,7 +131,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     c.  **Update Tech Stack:**
         i. **Condition for Update:** Similarly, you MUST determine if significant changes in the technology stack are detected as a result of the completed track.
         ii. **Propose and Confirm Changes:** If an update is needed:
-            -   **Announce:** Briefly state that updates are proposed. Do NOT repeat the request to review in the chat.
             -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed updates (in a diff format) directly into the `question` field so the user can review them in context.
                 - **questions:**
                     - **header:** "Tech Stack"
@@ -148,7 +146,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
         i. **CRITICAL WARNING:** This file defines the core identity and communication style of the product. It should be modified with extreme caution and ONLY in cases of significant strategic shifts, such as a product rebrand or a fundamental change in user engagement philosophy. Routine feature updates or bug fixes should NOT trigger changes to this file.
         ii. **Condition for Update:** You may ONLY propose an update to this file if the track's **Specification** explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.
         iii. **Propose and Confirm Changes:** If the conditions are met:
-            -   **Announce:** Briefly state that updates are proposed. Do NOT repeat the request to review in the chat.
             -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the proposed changes (in a diff format) directly into the `question` field, including a clear warning.
                 - **questions:**
                     - **header:** "Product"

commands/conductor/newTrack.toml

@@ -80,7 +80,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 3.  **Draft `spec.md`:** Once sufficient information is gathered, draft the content for the track's `spec.md` file, including sections like Overview, Functional Requirements, Non-Functional Requirements (if any), Acceptance Criteria, and Out of Scope.
 
 4.  **User Confirmation:**
-    -   **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
     -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
         - **questions:**
             - **header:** "Confirm Spec"
@@ -113,7 +112,6 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     *   **CRITICAL: Inject Phase Completion Tasks.** Determine if a "Phase Completion Verification and Checkpointing Protocol" is defined in the **Workflow**. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.
 
 3.  **User Confirmation:**
-    -   **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
     -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
         - **questions:**
             - **header:** "Confirm Plan"

commands/conductor/setup.toml

@@ -23,7 +23,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 ## 1.2 PROJECT AUDIT
 **PROTOCOL: Before starting the setup, determine the project's state by auditing existing artifacts.**
 
-1.  **Audit Artifacts:** Check the file system for the existence of the following files/directories in the `conductor/` directory:
+1.  **Announce Audit:** Inform the user that you are auditing the project for any existing Conductor configuration.
+
+2.  **Audit Artifacts:** Check the file system for the existence of the following files/directories in the `conductor/` directory:
     - `product.md`
     - `product-guidelines.md`
     - `tech-stack.md`
@@ -32,7 +34,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     - `index.md`
     - `tracks/*/` (specifically `plan.md` and `index.md`)
 
-2.  **Determine Target Section:** Map the project's state to a target section using the priority table below (highest match wins). **DO NOT JUMP YET.** Keep this target in mind.
+3.  **Determine Target Section:** Map the project's state to a target section using the priority table below (highest match wins). **DO NOT JUMP YET.** Keep this target in mind.
 
 | Artifact Exists | Target Section | Announcement |
 | :--- | :--- | :--- |
@@ -45,7 +47,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 | `product.md` | **Section 2.2** | "Resuming setup: Product Guide is complete. Next: create Product Guidelines." |
 | (None) | **Section 2.0** | (None) |
 
-3. **Proceed to Section 2.0:** You MUST proceed to Section 2.0 to establish the Greenfield/Brownfield context before jumping to your target.
+4. **Proceed to Section 2.0:** You MUST proceed to Section 2.0 to establish the Greenfield/Brownfield context before jumping to your target.
 
 ---
 
@@ -158,10 +160,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     -   **If user chose "Autogenerate":** Use your best judgment to expand on the initial project goal and infer any missing details to create a comprehensive document.
     -   **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
 5.  **User Confirmation Loop:**
-    -   **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
     -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
         - **questions:**
-            - **header:** "Review"
+            - **header:** "Review Draft"
             - **question:**
                 Please review the drafted Product Guide below. What would you like to do next?
 
@@ -206,10 +207,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     -   **If user chose "Autogenerate":** Use your best judgment to infer standard, high-quality guidelines suitable for the project type.
     -   **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
 5.  **User Confirmation Loop:**
-    -   **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
     -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
         - **questions:**
-            - **header:** "Review"
+            - **header:** "Review Draft"
             - **question:**
                 Please review the drafted Product Guidelines below. What would you like to do next?
 
@@ -262,10 +262,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     -   **If user chose "Autogenerate":** Use your best judgment to infer a standard, high-quality stack suitable for the project goal.
     -   **If user chose "Interactive" or corrected the Brownfield stack:** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**.
 5.  **User Confirmation Loop:**
-    -   **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat.
     -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
         - **questions:**
-            - **header:** "Review"
+            - **header:** "Review Draft"
             - **question:**
                 Please review the drafted Tech Stack below. What would you like to do next?