Merge pull request #126 from gemini-cli-extensions/feat/plan-mode

Plan mode changes:
*  Migrated interactive prompts to start using the `AskUser` tool
*  Add a warning note to prevent users from using Plan mode when using Conductor.

Author: moisgobg

README.md

@@ -33,6 +33,10 @@ Conductor is designed to manage the entire lifecycle of your development tasks.
 
 **Note on Token Consumption:** Conductor's context-driven approach involves reading and analyzing your project's context, specifications, and plans. This can lead to increased token consumption, especially in larger projects or during extensive planning and implementation phases. You can check the token consumption in the current session by running `/stats model`.
 
+> [!WARNING]
+> **Disable Gemini CLI's built-in Plan Mode for Conductor**
+> Conductor manages its own planning lifecycle. Gemini CLI's built-in Plan Mode will conflict with Conductor's state management. For the best Conductor experience, please disable Gemini CLI's built-in Plan Mode in your environment.
+
 ### 1. Set Up the Project (Run Once)
 
 When you run `/conductor:setup`, Conductor helps you define the core components of your project context. This context is then used for building new components or features by you or anyone on your team.

commands/conductor/implement.toml

@@ -35,13 +35,29 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 4.  **Select Track:**
     -   **If a track name was provided:**
         1.  Perform an exact, case-insensitive match for the provided name against the track descriptions you parsed.
-        2.  If a unique match is found, confirm the selection with the user: "I found track '<track_description>'. Is this correct?"
-        3.  If no match is found, or if the match is ambiguous, inform the user and ask for clarification. Suggest the next available track as below.
+        2.  If a unique match is found, immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
+            - **questions:**
+                - **header:** "Confirm"
+                - **question:** "I found track '<track_description>'. Is this correct?"
+                - **type:** "yesno"
+        3.  If no match is found, or if the match is ambiguous, immediately call the `ask_user` tool to inform the user and request the correct track name (do not repeat the question in the chat):
+            - **questions:**
+                - **header:** "Clarify"
+                - **question:** "I couldn't find a unique track matching the name you provided. Did you mean '<next_available_track>'? Or please type the exact track name."
+                - **type:** "text"
     -   **If no track name was provided (or if the previous step failed):**
         1.  **Identify Next Track:** Find the first track in the parsed tracks file that is NOT marked as `[x] Completed`.
         2.  **If a next track is found:**
-            -   Announce: "No track name provided. Automatically selecting the next incomplete track: '<track_description>'."
-            -   Proceed with this track.
+            -   Immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
+                - **questions:**
+                    - **header:** "Next Track"
+                    - **question:** "No track name provided. Would you like to proceed with the next incomplete track: '<track_description>'?"
+                    - **type:** "yesno"
+            -   If confirmed, proceed with this track. Otherwise, immediately call the `ask_user` tool to request the correct track name (do not repeat the question in the chat):
+                - **questions:**
+                    - **header:** "Clarify"
+                    - **question:** "Please type the exact name of the track you would like to implement."
+                    - **type:** "text"
         3.  **If no incomplete tracks are found:**
             -   Announce: "No incomplete tracks found in the tracks file. All tasks are completed!"
             -   Halt the process and await further user instructions.
@@ -71,6 +87,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     b. **Iterate Through Tasks:** You MUST now loop through each task in the track's **Implementation Plan** one by one.
     c. **For Each Task, You MUST:**
         i. **Defer to Workflow:** The **Workflow** file is the **single source of truth** for the entire task lifecycle. You MUST now read and execute the procedures defined in the "Task Workflow" section of the **Workflow** file you have in your context. Follow its steps for implementation, testing, and committing precisely.
+           - **CRITICAL:** Every human-in-the-loop interaction, confirmation, or request for feedback mentioned in the **Workflow** (e.g., manual verification plans or guidance on persistent failures) MUST be conducted using the `ask_user` tool.
 
 5.  **Finalize Track:**
     -   After all tasks in the track's local **Implementation Plan** are completed, you MUST update the track's status in the **Tracks Registry**.
@@ -99,31 +116,49 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     a.  **Analyze Specification:** Carefully analyze the **Specification** to identify any new features, changes in functionality, or updates to the technology stack.
     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, generate the proposed changes. Then, present them to the user for confirmation:
-            > "Based on the completed track, I propose the following updates to the **Product Definition**:"
-            > ```diff
-            > [Proposed changes here, ideally in a diff format]
-            > ```
-            > "Do you approve these changes? (yes/no)"
+        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"
+                    - **question:**
+                        Please review the proposed updates to the Product Definition below. Do you approve?
+
+                        ---
+
+                        <Insert Proposed product.md Updates/Diff Here>
+                    - **type:** "yesno"
         iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the **Product Definition** file. Keep a record of whether this file was changed.
     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, generate the proposed changes. Then, present them to the user for confirmation:
-            > "Based on the completed track, I propose the following updates to the **Tech Stack**:"
-            > ```diff
-            > [Proposed changes here, ideally in a diff format]
-            > ```
-            > "Do you approve these changes? (yes/no)"
+        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"
+                    - **question:**
+                        Please review the proposed updates to the Tech Stack below. Do you approve?
+
+                        ---
+
+                        <Insert Proposed tech-stack.md Updates/Diff Here>
+                    - **type:** "yesno"
         iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the **Tech Stack** file. Keep a record of whether this file was changed.
     d. **Update Product Guidelines (Strictly Controlled):**
         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, you MUST generate the proposed changes and present them to the user with a clear warning:
-            > "WARNING: The completed track suggests a change to the core **Product Guidelines**. This is an unusual step. Please review carefully:"
-            > ```diff
-            > [Proposed changes here, ideally in a diff format]
-            > ```
-            > "Do you approve these critical changes to the **Product Guidelines**? (yes/no)"
+        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"
+                    - **question:**
+                        WARNING: This is a sensitive action as it impacts core product guidelines. Please review the proposed changes below. Do you approve these critical changes?
+
+                        ---
+
+                        <Insert Proposed product-guidelines.md Updates/Diff Here>
+                    - **type:** "yesno"
         iv. **Action:** Only after receiving explicit user confirmation, perform the file edits. Keep a record of whether this file was changed.
 
 6.  **Final Report:** Announce the completion of the synchronization process and provide a summary of the actions taken.
@@ -146,34 +181,41 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 1.  **Execution Trigger:** This protocol MUST only be executed after the current track has been successfully implemented and the `SYNCHRONIZE PROJECT DOCUMENTATION` step is complete.
 
-2.  **Ask for User Choice:** You MUST prompt the user with the available options for the completed track.
-    > "Track '<track_description>' is now complete. What would you like to do?
-    > A.  **Review (Recommended):** Run the review command to verify changes before finalizing.
-    > B.  **Archive:** Move the track's folder to `conductor/archive/` and remove it from the tracks file.
-    > C.  **Delete:** Permanently delete the track's folder and remove it from the tracks file.
-    > D.  **Skip:** Do nothing and leave it in the tracks file.
-    > Please enter the option of your choice (A, B, C, or D)."
+2.  **Ask for User Choice:** Immediately call the `ask_user` tool to prompt the user (do not repeat the question in the chat):
+    - **questions:**
+        - **header:** "Track Cleanup"
+        - **question:** "Track '<track_description>' is now complete. What would you like to do?"
+        - **type:** "choice"
+        - **multiSelect:** false
+        - **options:**
+            - Label: "Review", Description: "Run the review command to verify changes before finalizing."
+            - Label: "Archive", Description: "Move the track's folder to `conductor/archive/` and remove it from the tracks file."
+            - Label: "Delete", Description: "Permanently delete the track's folder and remove it from the tracks file."
+            - Label: "Skip", Description: "Do nothing and leave it in the tracks file."
 
 3.  **Handle User Response:**
-    *   **If user chooses "A" (Review):**
+    *   **If user chooses "Review":**
         *   Announce: "Please run `/conductor:review` to verify your changes. You will be able to archive or delete the track after the review."
-    *   **If user chooses "B" (Archive):**
+    *   **If user chooses "Archive":**
         i.   **Create Archive Directory:** Check for the existence of `conductor/archive/`. If it does not exist, create it.
         ii.  **Archive Track Folder:** Move the track's folder from its current location (resolved via the **Tracks Directory**) to `conductor/archive/<track_id>`.
         iii. **Remove from Tracks File:** Read the content of the **Tracks Registry** file, remove the entire section for the completed track (the part that starts with `---` and contains the track description), and write the modified content back to the file.
         iv.  **Commit Changes:** Stage the **Tracks Registry** file and `conductor/archive/`. Commit with the message `chore(conductor): Archive track '<track_description>'`.
         v.   **Announce Success:** Announce: "Track '<track_description>' has been successfully archived."
-    *   **If user chooses "C" (Delete):**
-        i. **CRITICAL WARNING:** Before proceeding, you MUST ask for a final confirmation due to the irreversible nature of the action.
-            > "WARNING: This will permanently delete the track folder and all its contents. This action cannot be undone. Are you sure you want to proceed? (yes/no)"
+    *   **If user chooses "Delete":**
+        i. **CRITICAL WARNING:** Before proceeding, immediately call the `ask_user` tool to ask for final confirmation (do not repeat the warning in the chat):
+            - **questions:**
+                - **header:** "Confirm"
+                - **question:** "WARNING: This will permanently delete the track folder and all its contents. This action cannot be undone. Are you sure?"
+                - **type:** "yesno"
         ii. **Handle Confirmation:**
             - **If 'yes'**:
                 a. **Delete Track Folder:** Resolve the **Tracks Directory** and permanently delete the track's folder from `<Tracks Directory>/<track_id>`.
                 b. **Remove from Tracks File:** Read the content of the **Tracks Registry** file, remove the entire section for the completed track, and write the modified content back to the file.
                 c. **Commit Changes:** Stage the **Tracks Registry** file and the deletion of the track directory. Commit with the message `chore(conductor): Delete track '<track_description>'`.
                 d. **Announce Success:** Announce: "Track '<track_description>' has been permanently deleted."
-            - **If 'no' (or anything else)**:
+            - **If 'no'**:
                 a. **Announce Cancellation:** Announce: "Deletion cancelled. The track has not been changed."
-    *   **If user chooses "D" (Skip) or provides any other input:**
+    *   **If user chooses "Skip":**
         *   Announce: "Okay, the completed track will remain in your tracks file for now."
-"""
+"""