Migrate interactive prompts to AskUser tool

commands/conductor/implement.toml

@@ -35,7 +35,10 @@ 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?"
+        2.  If a unique match is found, confirm the selection with the user using the `ask_user` tool:
+            - **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, inform the user and ask for clarification. Suggest the next available track as below.
     -   **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`.
@@ -99,31 +102,25 @@ 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, generate the proposed changes. Then, present them to the user for confirmation using the `ask_user` tool:
+            - **header:** "Update Doc"
+            - **question:** "Based on the completed track, I propose the following updates to the **Product Definition**:\n\n```diff\n[Proposed changes here]\n```\n\nDo you approve these changes?"
+            - **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, generate the proposed changes. Then, present them to the user for confirmation using the `ask_user` tool:
+            - **header:** "Update Stack"
+            - **question:** "Based on the completed track, I propose the following updates to the **Tech Stack**:\n\n```diff\n[Proposed changes here]\n```\n\nDo you approve these changes?"
+            - **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, you MUST generate the proposed changes and present them to the user with a clear warning using the `ask_user` tool:
+            - **header:** "Update Guide"
+            - **question:** "WARNING: The completed track suggests a change to the core **Product Guidelines**. This is an unusual step. Please review carefully:\n\n```diff\n[Proposed changes here]\n```\n\nDo you approve these critical changes?"
+            - **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 +143,39 @@ 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:** You MUST prompt the user with the available options for the completed track using the `ask_user` tool.
+    - **header:** "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"
+        - Label: "Delete"
+        - Label: "Skip"
 
 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, you MUST ask for a final confirmation using the `ask_user` tool.
+            - **header:** "Confirm"
+            - **question:** "WARNING: This will permanently delete the track folder. 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."
-"""
+"""

commands/conductor/newTrack.toml

@@ -30,8 +30,11 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 1.  **Load Project Context:** Read and understand the content of the project documents (**Product Definition**, **Tech Stack**, etc.) resolved via the **Universal File Resolution Protocol**.
 2.  **Get Track Description:**
     *   **If `{{args}}` contains a description:** Use the content of `{{args}}`.
-    *   **If `{{args}}` is empty:** Ask the user:
-        > "Please provide a brief description of the track (feature, bug fix, chore, etc.) you wish to start."
+    *   **If `{{args}}` is empty:** Ask the user using the `ask_user` tool:
+        - **Header:** "Description"
+        - **Type:** "text"
+        - **Question:** "Please provide a brief description of the track (feature, bug fix, chore, etc.) you wish to start."
+        - **Placeholder:** "e.g., Implement user authentication"
         Await the user's response and use it as the track description.
 3.  **Infer Track Type:** Analyze the description to determine if it is a "Feature" or "Something Else" (e.g., Bug, Chore, Refactor). Do NOT ask the user to classify it.
 
@@ -40,48 +43,45 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 1.  **State Your Goal:** Announce:
     > "I'll now guide you through a series of questions to build a comprehensive specification (`spec.md`) for this track."
 
-2.  **Questioning Phase:** Ask a series of questions to gather details for the `spec.md`. Tailor questions based on the track type (Feature or Other).
-    *   **CRITICAL:** You MUST ask these questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
+2.  **Questioning Phase:** Ask a series of questions to gather details for the `spec.md` using the `ask_user` tool. You can batch up to 4 related questions in a single tool call to streamline the process. Tailor questions based on the track type (Feature or Other).
+    *   **CRITICAL:** Wait for the user's response after each `ask_user` tool call.
     *   **General Guidelines:**
         *   Refer to information in **Product Definition**, **Tech Stack**, etc., to ask context-aware questions.
         *   Provide a brief explanation and clear examples for each question.
         *   **Strongly Recommendation:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.
-        *   **Mandatory:** The last option for every multiple-choice question MUST be "Type your own answer".
 
-        *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either "Additive" or "Exclusive Choice".
-            *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.
-            *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.
-
-        *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:
-            *   **Strongly Recommended:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.
-            *   **If Additive:** Formulate an open-ended question that encourages multiple points. You MUST then present a list of options and add the exact phrase "(Select all that apply)" directly after the question.
-            *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add "(Select all that apply)".
-
-        *   **3. Interaction Flow:**
-            *   **CRITICAL:** You MUST ask questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
-            *   The last option for every multiple-choice question MUST be "Type your own answer".
-            *   Confirm your understanding by summarizing before moving on to the next question or section..
+        *   **1. Formulate the `ask_user` tool call:** Adhere to the following for each question in the `questions` array:
+            - **header:** Very short label (max 12 chars).
+            - **type:** "choice", "text", or "yesno".
+            - **multiSelect:** (Required for type: "choice") Set to `true` for multi-select (additive) or `false` for single-choice (exclusive).
+            - **options:** (Required for type: "choice") Provide 2-4 options. Note that "Other" is automatically added.
+            - **placeholder:** (For type: "text") Provide a hint.
+
+        *   **2. Interaction Flow:**
+            *   Wait for the user's response after each `ask_user` tool call.
+            *   If the user selects "Other", use a subsequent `ask_user` tool call with `type: "text"` to get their input if necessary.
+            *   Confirm your understanding by summarizing before moving on to drafting.
 
     *   **If FEATURE:**
-        *   **Ask 3-5 relevant questions** to clarify the feature request.
+        *   Ask 3-5 relevant questions to clarify the feature request using the `ask_user` tool.
         *   Examples include clarifying questions about the feature, how it should be implemented, interactions, inputs/outputs, etc.
         *   Tailor the questions to the specific feature request (e.g., if the user didn't specify the UI, ask about it; if they didn't specify the logic, ask about it).
 
     *   **If SOMETHING ELSE (Bug, Chore, etc.):**
-        *   **Ask 2-3 relevant questions** to obtain necessary details.
+        *   Ask 2-3 relevant questions to obtain necessary details using the `ask_user` tool.
         *   Examples include reproduction steps for bugs, specific scope for chores, or success criteria.
         *   Tailor the questions to the specific request.
 
 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:** Present the drafted `spec.md` content to the user for review and approval.
-    > "I've drafted the specification for this track. Please review the following:"
-    >
-    > ```markdown
-    > [Drafted spec.md content here]
-    > ```
-    >
-    > "Does this accurately capture the requirements? Please suggest any changes or confirm."
+4.  **User Confirmation:** Present the drafted `spec.md` content and ask for approval using the `ask_user` tool.
+    - **header:** "Confirm Spec"
+    - **question:** "I've drafted the specification for this track. Please review the following:\n\n```markdown\n[Drafted spec.md content here]\n```\n\nDoes this accurately capture the requirements?"
+    - **type:** "choice"
+    - **multiSelect:** `false`
+    - **options:**
+        - Label: "Approve"
+        - Label: "Revise"
     Await user feedback and revise the `spec.md` content until confirmed.
 
 ### 2.3 Interactive Plan Generation (`plan.md`)
@@ -99,14 +99,14 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
         - Sub-task: `    - [ ] ...`
     *   **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:** Present the drafted `plan.md` to the user for review and approval.
-    > "I've drafted the implementation plan. Please review the following:"
-    >
-    > ```markdown
-    > [Drafted plan.md content here]
-    > ```
-    >
-    > "Does this plan look correct and cover all the necessary steps based on the spec and our workflow? Please suggest any changes or confirm."
+3.  **User Confirmation:** Present the drafted `plan.md` content and ask for approval using the `ask_user` tool.
+    - **header:** "Confirm Plan"
+    - **question:** "I've drafted the implementation plan. Please review the following:\n\n```markdown\n[Drafted plan.md content here]\n```\n\nDoes this look correct based on the spec and workflow?"
+    - **type:** "choice"
+    - **multiSelect:** `false`
+    - **options:**
+        - Label: "Approve"
+        - Label: "Revise"
     Await user feedback and revise the `plan.md` content until confirmed.
 
 ### 2.4 Create Track Artifacts and Update Main Plan