From 36433993cbed75f60a485c4485faf948e18d7d18 Mon Sep 17 00:00:00 2001 From: Jerop Kipruto Date: Thu, 29 Jan 2026 13:06:12 -0500 Subject: [PATCH 1/3] feat(conductor): migrate interactive prompts to AskUser tool Refactors the interactive flows in `implement`, `newTrack`, `revert`, and `setup` commands to utilize the `AskUser` tool. This replaces free-text parsing with structured inputs (choice, yesno, text), improving the reliability and user experience of the CLI interactions. Updates: - `implement.toml`: specific prompts for track selection, document synchronization (with diff previews), and cleanup options using the `AskUser` tool. - `newTrack.toml`: structured questions for track specification and planning with the `AskUser` tool, including Markdown previews. Removed redundant option descriptions. - `revert.toml`: better selection menus for reverting tracks/tasks and plan confirmation using the `AskUser` tool. Removed redundant option descriptions. - `setup.toml`: enhanced project initialization and configuration questionnaires using the `AskUser` tool, including document previews. Removed redundant option descriptions. Explicitly mentions AskUser tool calls. --- commands/conductor/implement.toml | 70 +++--- commands/conductor/newTrack.toml | 72 +++--- commands/conductor/revert.toml | 56 ++--- commands/conductor/setup.toml | 363 +++++++++++++++--------------- 4 files changed, 274 insertions(+), 287 deletions(-) diff --git a/commands/conductor/implement.toml b/commands/conductor/implement.toml index e7597919..0016507b 100644 --- a/commands/conductor/implement.toml +++ b/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 ''. 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 ''. 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 '' 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 '' 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/`. 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 ''`. v. **Announce Success:** Announce: "Track '' 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 `/`. 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 ''`. d. **Announce Success:** Announce: "Track '' 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." -""" +""" \ No newline at end of file diff --git a/commands/conductor/newTrack.toml b/commands/conductor/newTrack.toml index aab88e8b..406eaf64 100644 --- a/commands/conductor/newTrack.toml +++ b/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 `AskUser` 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 `AskUser` 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 `AskUser` 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 `AskUser` 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 `AskUser` tool call. + * If the user selects "Other", use a subsequent `AskUser` 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 `AskUser` 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 `AskUser` 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 `AskUser` 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 '' (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 `AskUser` 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 diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 478b2c01..2e228abb 100644 --- a/commands/conductor/revert.toml +++ b/commands/conductor/revert.toml @@ -37,10 +37,10 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai * **PATH A: Direct Confirmation** 1. Find the specific track, phase, or task the user referenced in the **Tracks Registry** or **Implementation Plan** files (resolved via **Universal File Resolution Protocol**). - 2. Ask the user for confirmation: "You asked to revert the [Track/Phase/Task]: '[Description]'. Is this correct?". - - **Structure:** - A) Yes - B) No + 2. Ask the user for confirmation using the `AskUser` tool: + - **header:** "Confirm" + - **question:** "You asked to revert the [Track/Phase/Task]: '[Description]'. Is this correct?" + - **type:** "yesno" 3. If "yes", establish this as the `target_intent` and proceed to Phase 2. If "no", ask clarifying questions to find the correct item to revert. * **PATH B: Guided Selection Menu** @@ -48,31 +48,17 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai * **Scan All Plans:** You MUST read the **Tracks Registry** and every track's **Implementation Plan** (resolved via **Universal File Resolution Protocol** using the track's index file). * **Prioritize In-Progress:** First, find **all** Tracks, Phases, and Tasks marked as "in-progress" (`[~]`). * **Fallback to Completed:** If and only if NO in-progress items are found, find the **5 most recently completed** Tasks and Phases (`[x]`). - 2. **Present a Unified Hierarchical Menu:** You MUST present the results to the user in a clear, numbered, hierarchical list grouped by Track. The introductory text MUST change based on the context. - * **Example when in-progress items are found:** - > "I found multiple in-progress items. Please choose which one to revert: - > - > Track: track_20251208_user_profile - > 1) [Phase] Implement Backend API - > 2) [Task] Update user model - > - > 3) A different Track, Task, or Phase." - * **Example when showing recently completed items:** - > "No items are in progress. Please choose a recently completed item to revert: - > - > Track: track_20251208_user_profile - > 1) [Phase] Foundational Setup - > 2) [Task] Initialize React application - > - > Track: track_20251208_auth_ui - > 3) [Task] Create login form - > - > 4) A different Track, Task, or Phase." + 2. **Present a Unified Hierarchical Menu:** You MUST present the results to the user using the `AskUser` tool. + - **header:** "Select Item" + - **question:** "I found multiple in-progress items (or recently completed items). Please choose which one to revert:" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** Provide the identified items as options. Group them by Track in the description if possible. + - **Example Option Label:** "[Task] Update user model", **Description:** "Track: track_20251208_user_profile" + - **Include an option Label:** "Other", **Description:** "A different Track, Task, or Phase." 3. **Process User's Choice:** - * If the user's response is **A** or **B**, set this as the `target_intent` and proceed directly to Phase 2. - * If the user's response is **C** or another value that does not match A or B, you must engage in a dialogue to find the correct target. Ask clarifying questions like: - * "What is the name or ID of the track you are looking for?" - * "Can you describe the task you want to revert?" + * If the user selects a specific item from the list, set this as the `target_intent` and proceed directly to Phase 2. + * If the user selects "Other" (automatically added for "choice") or the explicit "Other" option provided, you must engage in a dialogue to find the correct target using `AskUser` tool with `type: "text"`. * Once a target is identified, loop back to Path A for final confirmation. 4. **Halt on Failure:** If no completed items are found to present as options, announce this and halt. @@ -105,17 +91,21 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai **GOAL: Present a clear, final plan of action to the user before modifying anything.** 1. **Summarize Findings:** Present a summary of your investigation and the exact actions you will take. - > "I have analyzed your request. Here is the plan:" + > **Example Plan:** > * **Target:** Revert Task '[Task Description]'. > * **Commits to Revert:** 2 > ` - ('feat: Add user profile')` > ` - ('conductor(plan): Mark task complete')` > * **Action:** I will run `git revert` on these commits in reverse order. -2. **Final Go/No-Go:** Ask for final confirmation: "**Do you want to proceed? (yes/no)**". - - **Structure:** - A) Yes - B) No +2. **Final Go/No-Go:** Ask for final confirmation using the `AskUser` tool: + - **header:** "Confirm Plan" + - **question:** "I've drafted the revert plan. Please review the following:\n\n[Drafted plan details here]\n\nDo you want to proceed with the revert plan?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Approve" + - Label: "Revise" 3. If "yes", proceed to Phase 4. If "no", ask clarifying questions to get the correct plan for revert. --- diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index 2f6850c3..dc913700 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -66,16 +66,16 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Announce that an existing project has been detected. - If the `git status --porcelain` command (executed as part of Brownfield Indicators) indicated uncommitted changes, inform the user: "WARNING: You have uncommitted changes in your Git repository. Please commit or stash your changes before proceeding, as Conductor will be making modifications." - **Begin Brownfield Project Initialization Protocol:** - - **1.0 Pre-analysis Confirmation:** + - **1.0 Pre-analysis Confirmation:** 1. **Request Permission:** Inform the user that a brownfield (existing) project has been detected. - 2. **Ask for Permission:** Request permission for a read-only scan to analyze the project with the following options using the next structure: - > A) Yes - > B) No - > - > Please respond with A or B. + 2. **Ask for Permission:** Request permission for a read-only scan to analyze the project using the `AskUser` tool with the following options: + - **Header:** "Permission" + - **Question:** "A brownfield (existing) project has been detected. May I perform a read-only scan to analyze the project?" + - **Options:** + - Label: "Yes" + - Label: "No" 3. **Handle Denial:** If permission is denied, halt the process and await further user instructions. 4. **Confirmation:** Upon confirmation, proceed to the next step. - - **2.0 Code Analysis:** 1. **Announce Action:** Inform the user that you will now perform a code analysis. 2. **Prioritize README:** Begin by analyzing the `README.md` file, if it exists. @@ -105,7 +105,11 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - If a `.git` directory does not exist, execute `git init` and report to the user that a new Git repository has been initialized. 4. **Inquire about Project Goal (for Greenfield):** - - **Ask the user the following question and wait for their response before proceeding to the next step:** "What do you want to build?" + - **Ask the user the following question using the `AskUser` tool and wait for their response before proceeding to the next step:** + - **Header:** "Project Goal" + - **Type:** "text" + - **Question:** "What do you want to build?" + - **Placeholder:** "e.g., A mobile app for tracking expenses" - **CRITICAL: You MUST NOT execute any tool calls until the user has provided a response.** - **Upon receiving the user's response:** - Execute `mkdir -p conductor`. @@ -117,49 +121,37 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.1 Generate Product Guide (Interactive) 1. **Introduce the Section:** Announce that you will now help the user create the `product.md`. -2. **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information. - - **CONSTRAINT:** Limit your inquiry to a maximum of 5 questions. - - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have. - - **Example Topics:** Target users, goals, features, etc - * **General Guidelines:** - * **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: - * **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)". +2. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. + - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. + - **Example Topics:** Target users, goals, features, etc. + - **General Guidelines:** + * **1. Formulate the `AskUser` 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. Autogenerate Option:** For the final question in a batch, include a "choice" option: + - Label: "Autogenerate", Description: "Autogenerate and review product.md" + - **multiSelect:** `false` (Exclusive choice) * **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 two options for every multiple-choice question MUST be "Type your own answer", and "Autogenerate and review product.md". - * Confirm your understanding by summarizing before moving on. - - **Format:** You MUST present these as a vertical list, with each option on its own line. - - **Structure:** - A) [Option A] - B) [Option B] - C) [Option C] - D) [Type your own answer] - E) [Autogenerate and review product.md] - - **FOR EXISTING PROJECTS (BROWNFIELD):** Ask project context-aware questions based on the code analysis. - - **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section. Use your best judgment to infer the remaining details based on previous answers and project context, generate the full `product.md` content, write it to the file, and proceed to the next section. -3. **Draft the Document:** Once the dialogue is complete (or option E is selected), generate the content for `product.md`. If option E was chosen, use your best judgment to infer the remaining details based on previous answers and project context. You are encouraged to expand on the gathered details to create a comprehensive document. - - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented. - - **Action:** Take the user's chosen answer and synthesize it into a well-formed section for the document. You are encouraged to expand on the user's choice to create a comprehensive and polished output. DO NOT include the conversational options (A, B, C, D, E) in the final file. -4. **User Confirmation Loop:** Present the drafted content to the user for review and begin the confirmation loop. - > "I've drafted the product guide. Please review the following:" - > - > ```markdown - > [Drafted product.md content here] - > ``` - > - > "What would you like to do next? - > A) **Approve:** The document is correct and we can proceed. - > B) **Suggest Changes:** Tell me what to modify. - > - > You can always edit the generated file with the Gemini CLI built-in option "Modify with external editor" (if present), or with your favorite external editor after this step. - > Please respond with A or B." - - **Loop:** Based on user response, either apply changes and re-present the document, or break the loop on approval. + * Wait for the user's response after each `AskUser` tool call. + * If the user selects "Autogenerate", stop asking questions and proceed to drafting. + * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. + - **FOR EXISTING PROJECTS (BROWNFIELD):** Batch project context-aware questions based on the code analysis. +3. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" is selected), generate the content for `product.md`. Use your best judgment to infer any missing details. + - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. +4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `AskUser` tool. + - **header:** "Review" + - **question:** "I've drafted the product guide. Please review the following:\n\n```markdown\n[Drafted product.md content here]\n```\n\nWhat would you like to do next?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Approve" + - Label: "Edit" 5. **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section. 6. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "2.1_product_guide"}` @@ -167,49 +159,34 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.2 Generate Product Guidelines (Interactive) 1. **Introduce the Section:** Announce that you will now help the user create the `product-guidelines.md`. -2. **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information. - - **CONSTRAINT:** Limit your inquiry to a maximum of 5 questions. - - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have. Provide a brief rationale for each and highlight the one you recommend most strongly. - - **Example Topics:** Prose style, brand messaging, visual identity, etc +2. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. + - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. Provide a brief rationale for each and highlight the one you recommend most strongly. + - **Example Topics:** Prose style, brand messaging, visual identity, etc. * **General Guidelines:** - * **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: - * **Suggestions:** When presenting options, you should provide a brief rationale for each and highlight the one you recommend most strongly. - * **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)". + * **1. Formulate the `AskUser` 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:** Set to `true` for additive questions, `false` for exclusive choice. + - **options:** Provide 2-4 options for "choice" types. Note that "Other" is automatically added. + - **placeholder:** For "text" type. + * **2. Autogenerate Option:** For the final question in a batch, include a "choice" option: + - Label: "Autogenerate", Description: "Autogenerate and review product-guidelines.md" * **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 two options for every multiple-choice question MUST be "Type your own answer" and "Autogenerate and review product-guidelines.md". - * Confirm your understanding by summarizing before moving on. - - **Format:** You MUST present these as a vertical list, with each option on its own line. - - **Structure:** - A) [Option A] - B) [Option B] - C) [Option C] - D) [Type your own answer] - E) [Autogenerate and review product-guidelines.md] - - **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section and proceed to the next step to draft the document. -3. **Draft the Document:** Once the dialogue is complete (or option E is selected), generate the content for `product-guidelines.md`. If option E was chosen, use your best judgment to infer the remaining details based on previous answers and project context. You are encouraged to expand on the gathered details to create a comprehensive document. - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented. - - **Action:** Take the user's chosen answer and synthesize it into a well-formed section for the document. You are encouraged to expand on the user's choice to create a comprehensive and polished output. DO NOT include the conversational options (A, B, C, D, E) in the final file. -4. **User Confirmation Loop:** Present the drafted content to the user for review and begin the confirmation loop. - > "I've drafted the product guidelines. Please review the following:" - > - > ```markdown - > [Drafted product-guidelines.md content here] - > ``` - > - > "What would you like to do next? - > A) **Approve:** The document is correct and we can proceed. - > B) **Suggest Changes:** Tell me what to modify. - > - > You can always edit the generated file with the Gemini CLI built-in option "Modify with external editor" (if present), or with your favorite external editor after this step. - > Please respond with A or B." - - **Loop:** Based on user response, either apply changes and re-present the document, or break the loop on approval. + * Wait for the user's response after each `AskUser` tool call. + * If the user selects "Autogenerate", stop asking questions and proceed to drafting. + * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. +3. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" is selected), generate the content for `product-guidelines.md`. Use your best judgment to infer any missing details. + **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. +4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `AskUser` tool. + - **header:** "Review" + - **question:** "I've drafted the product guidelines. Please review the following:\n\n```markdown\n[Drafted product-guidelines.md content here]\n```\n\nWhat would you like to do next?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Approve" + - Label: "Edit" 5. **Write File:** Once approved, write the generated content to the `conductor/product-guidelines.md` file. 6. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "2.2_product_guidelines"}` @@ -217,56 +194,42 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.3 Generate Tech Stack (Interactive) 1. **Introduce the Section:** Announce that you will now help define the technology stacks. -2. **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information. - - **CONSTRAINT:** Limit your inquiry to a maximum of 5 questions. - - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have. - - **Example Topics:** programming languages, frameworks, databases, etc +2. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. + - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. + - **Example Topics:** programming languages, frameworks, databases, etc. * **General Guidelines:** - * **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: - * **Suggestions:** When presenting options, you should provide a brief rationale for each and highlight the one you recommend most strongly. - * **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)". + * **1. Formulate the `AskUser` 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:** Set to `true` for additive questions, `false` for exclusive choice. + - **options:** Provide 2-4 options for "choice" types. Note that "Other" is automatically added. + - **placeholder:** For "text" type. + * **2. Autogenerate Option:** For the final question in a batch, include a "choice" option: + - Label: "Autogenerate", Description: "Autogenerate and review tech-stack.md" * **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 two options for every multiple-choice question MUST be "Type your own answer" and "Autogenerate and review tech-stack.md". - * Confirm your understanding by summarizing before moving on. - - **Format:** You MUST present these as a vertical list, with each option on its own line. - - **Structure:** - A) [Option A] - B) [Option B] - C) [Option C] - D) [Type your own answer] - E) [Autogenerate and review tech-stack.md] + * Wait for the user's response after each `AskUser` tool call. + * If the user selects "Autogenerate", stop asking questions and proceed to drafting. + * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. - **FOR EXISTING PROJECTS (BROWNFIELD):** - **CRITICAL WARNING:** Your goal is to document the project's *existing* tech stack, not to propose changes. - - **State the Inferred Stack:** Based on the code analysis, you MUST state the technology stack that you have inferred. Do not present any other options. - - **Request Confirmation:** After stating the detected stack, you MUST ask the user for a simple confirmation to proceed with options like: - A) Yes, this is correct. - B) No, I need to provide the correct tech stack. - - **Handle Disagreement:** If the user disputes the suggestion, acknowledge their input and allow them to provide the correct technology stack manually as a last resort. - - **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section. Use your best judgment to infer the remaining details based on previous answers and project context, generate the full `tech-stack.md` content, write it to the file, and proceed to the next section. -3. **Draft the Document:** Once the dialogue is complete (or option E is selected), generate the content for `tech-stack.md`. If option E was chosen, use your best judgment to infer the remaining details based on previous answers and project context. You are encouraged to expand on the gathered details to create a comprehensive document. - - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented. - - **Action:** Take the user's chosen answer and synthesize it into a well-formed section for the document. You are encouraged to expand on the user's choice to create a comprehensive and polished output. DO NOT include the conversational options (A, B, C, D, E) in the final file. -4. **User Confirmation Loop:** Present the drafted content to the user for review and begin the confirmation loop. - > "I've drafted the tech stack document. Please review the following:" - > - > ```markdown - > [Drafted tech-stack.md content here] - > ``` - > - > "What would you like to do next? - > A) **Approve:** The document is correct and we can proceed. - > B) **Suggest Changes:** Tell me what to modify. - > - > You can always edit the generated file with the Gemini CLI built-in option "Modify with external editor" (if present), or with your favorite external editor after this step. - > Please respond with A or B." - - **Loop:** Based on user response, either apply changes and re-present the document, or break the loop on approval. + - **State the Inferred Stack:** Based on the code analysis, you MUST state the technology stack that you have inferred. + - **Request Confirmation:** After stating the detected stack, you MUST ask the user for confirmation using the `AskUser` tool: + - **Header:** "Stack" + - **Question:** "Based on my analysis, this is the inferred tech stack:\n\n[List of inferred technologies]\n\nIs this correct?" + - **type:** "yesno" + - **Handle Disagreement:** If the user disputes the suggestion, acknowledge their input and allow them to provide the correct technology stack manually using `AskUser` tool with `type: "text"`. +3. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" is selected), generate the content for `tech-stack.md`. Use your best judgment to infer any missing details. + - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. +4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `AskUser` tool. + - **header:** "Review" + - **question:** "I've drafted the tech stack. Please review the following:\n\n```markdown\n[Drafted tech-stack.md content here]\n```\n\nWhat would you like to do next?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Approve" + - Label: "Edit" 6. **Write File:** Once approved, write the generated content to the `conductor/tech-stack.md` file. 7. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "2.3_tech_stack"}` @@ -278,18 +241,32 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - List the available style guides by running `ls ~/.gemini/extensions/conductor/templates/code_styleguides/`. - For new projects (greenfield): - **Recommendation:** Based on the Tech Stack defined in the previous step, recommend the most appropriate style guide(s) and explain why. - - Ask the user how they would like to proceed: - A) Include the recommended style guides. - B) Edit the selected set. - - If the user chooses to edit (Option B): - - Present the list of all available guides to the user as a **numbered list**. - - Ask the user which guide(s) they would like to copy. + - Ask the user how they would like to proceed using the `AskUser` tool: + - **header:** "Style Guides" + - **question:** "How would you like to proceed with the code style guides?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Recommended" + - Label: "Edit" + - If the user chooses "Edit": + - Present the list of all available guides to the user using the `AskUser` tool: + - **header:** "Select" + - **type:** "choice" + - **multiSelect:** `true` + - **question:** "Which code style guide(s) would you like to include?" + - **options:** Use the list of available guides as labels. - For existing projects (brownfield): - **Announce Selection:** Inform the user: "Based on the inferred tech stack, I will copy the following code style guides: ." - - **Ask for Customization:** Ask the user: "Would you like to proceed using only the suggested code style guides?" - - Ask the user for a simple confirmation to proceed with options like: - A) Yes, I want to proceed with the suggested code style guides. - B) No, I want to add more code style guides. + - **Ask for Customization:** Ask the user if they'd like to proceed using the `AskUser` tool: + - **header:** "Confirm" + - **question:** "Would you like to proceed using only the suggested code style guides?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Yes" + - Label: "Add More" + - **Handle Selection:** If the user chooses "Add More", present the full list using `AskUser` tool with `multiSelect: true`. - **Action:** Construct and execute a command to create the directory and copy all selected files. For example: `mkdir -p conductor/code_styleguides && cp ~/.gemini/extensions/conductor/templates/code_styleguides/python.md ~/.gemini/extensions/conductor/templates/code_styleguides/javascript.md conductor/code_styleguides/` - **Commit State:** Upon successful completion of the copy command, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "2.4_code_styleguides"}` @@ -298,23 +275,40 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re 1. **Copy Initial Workflow:** - Copy `~/.gemini/extensions/conductor/templates/workflow.md` to `conductor/workflow.md`. 2. **Customize Workflow:** - - Ask the user: "Do you want to use the default workflow or customize it?" - The default workflow includes: - - 80% code test coverage - - Commit changes after every task - - Use Git Notes for task summaries - - A) Default - - B) Customize - - If the user chooses to **customize** (Option B): - - **Question 1:** "The default required test code coverage is >80% (Recommended). Do you want to change this percentage?" - - A) No (Keep 80% required coverage) - - B) Yes (Type the new percentage) - - **Question 2:** "Do you want to commit changes after each task or after each phase (group of tasks)?" - - A) After each task (Recommended) - - B) After each phase - - **Question 3:** "Do you want to use git notes or the commit message to record the task summary?" - - A) Git Notes (Recommended) - - B) Commit Message + - Ask the user if they want to customize the workflow using the `AskUser` tool: + - **header:** "Workflow" + - **question:** "Do you want to use the default workflow or customize it?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Default" + - Label: "Customize" + - If the user chooses "Customize": + - **Question 1:** Use `AskUser` tool. + - **header:** "Coverage" + - **question:** "The default required test code coverage is >80%. Do you want to change this percentage?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "No" + - Label: "Yes" + - If "Yes", use `AskUser` tool with `type: "text"` to get the value. + - **Question 2:** Use `AskUser` tool. + - **header:** "Commits" + - **question:** "Do you want to commit changes after each task or after each phase (group of tasks)?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Per Task" + - Label: "Per Phase" + - **Question 3:** Use `AskUser` tool. + - **header:** "Summaries" + - **question:** "Do you want to use git notes or the commit message to record the task summary?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Git Notes" + - Label: "Commits" - **Action:** Update `conductor/workflow.md` based on the user's responses. - **Commit State:** After the `workflow.md` file is successfully written or updated, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "2.5_workflow"}` @@ -353,31 +347,24 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 3.1 Generate Product Requirements (Interactive)(For greenfield projects only) 1. **Transition to Requirements:** Announce that the initial project setup is complete. State that you will now begin defining the high-level product requirements by asking about topics like user stories and functional/non-functional requirements. 2. **Analyze Context:** Read and analyze the content of `conductor/product.md` to understand the project's core concept. -3. **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information. - - **CONSTRAINT** Limit your inquiries to a maximum of 5 questions. - - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have. +3. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT** Limit your total inquiry for this section to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. + - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. * **General Guidelines:** - * **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: - * **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)". + * **1. Formulate the `AskUser` 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:** Set to `true` for additive questions, `false` for exclusive choice. + - **options:** Provide 2-4 options for "choice" types. Note that "Other" is automatically added. + - **placeholder:** For "text" type. + * **2. Autogenerate Option:** For the final question in a batch, include a "choice" option: + - Label: "Autogenerate", Description: "Auto-generate the rest of requirements" * **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 two options for every multiple-choice question MUST be "Type your own answer" and "Auto-generate the rest of requirements and move to the next step". - * Confirm your understanding by summarizing before moving on. - - **Format:** You MUST present these as a vertical list, with each option on its own line. - - **Structure:** - A) [Option A] - B) [Option B] - C) [Option C] - D) [Type your own answer] - E) [Auto-generate the rest of requirements and move to the next step] - - **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section. Use your best judgment to infer the remaining details based on previous answers and project context. -- **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented. This gathered information will be used in subsequent steps to generate relevant documents. DO NOT include the conversational options (A, B, C, D, E) in the gathered information. + * Wait for the user's response after each `AskUser` tool call. + * If the user selects "Autogenerate", stop asking questions and proceed. + * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. +- **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**. 4. **Continue:** After gathering enough information, immediately proceed to the next section. ### 3.2 Propose a Single Initial Track (Automated + Approval) @@ -393,7 +380,15 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re To create the first track of this project, I suggest the following track: - Create user authentication flow for user sign in. ``` -3. **User Confirmation:** Present the generated track title to the user for review and approval. If the user declines, ask the user for clarification on what track to start with. +3. **User Confirmation:** Present the generated track title to the user for review and approval using the `AskUser` tool. + - **header:** "Confirm" + - **question:** "To get the project started, I suggest the following track: . Do you approve?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Approve" + - Label: "Revise" + - If the user declines, ask the user for clarification on what track to start with using `AskUser` tool with `type: "text"`. ### 3.3 Convert the Initial Track into Artifacts (Automated) 1. **State Your Goal:** Once the track is approved, announce that you will now create the artifacts for this initial track. From cd3e374fdad845ec3e5720f580d57ddf102f3684 Mon Sep 17 00:00:00 2001 From: Jerop Kipruto Date: Thu, 29 Jan 2026 15:36:11 -0500 Subject: [PATCH 2/3] chore(conductor): rename AskUser tool to ask_user --- commands/conductor/newTrack.toml | 20 +++++----- commands/conductor/revert.toml | 8 ++-- commands/conductor/setup.toml | 68 ++++++++++++++++---------------- 3 files changed, 48 insertions(+), 48 deletions(-) diff --git a/commands/conductor/newTrack.toml b/commands/conductor/newTrack.toml index 406eaf64..eeea7107 100644 --- a/commands/conductor/newTrack.toml +++ b/commands/conductor/newTrack.toml @@ -30,7 +30,7 @@ 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 using the `AskUser` tool: + * **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." @@ -43,14 +43,14 @@ 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` using the `AskUser` 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 `AskUser` tool call. +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. - * **1. Formulate the `AskUser` tool call:** Adhere to the following for each question in the `questions` array: + * **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). @@ -58,23 +58,23 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai - **placeholder:** (For type: "text") Provide a hint. * **2. Interaction Flow:** - * Wait for the user's response after each `AskUser` tool call. - * If the user selects "Other", use a subsequent `AskUser` tool call with `type: "text"` to get their input if necessary. + * 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 using the `AskUser` tool. + * 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 using the `AskUser` tool. + * 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 and ask for approval using the `AskUser` tool. +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" @@ -99,7 +99,7 @@ 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 '' (Protocol in workflow.md)`. -3. **User Confirmation:** Present the drafted `plan.md` content and ask for approval using the `AskUser` tool. +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" diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 2e228abb..17efb0bf 100644 --- a/commands/conductor/revert.toml +++ b/commands/conductor/revert.toml @@ -37,7 +37,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai * **PATH A: Direct Confirmation** 1. Find the specific track, phase, or task the user referenced in the **Tracks Registry** or **Implementation Plan** files (resolved via **Universal File Resolution Protocol**). - 2. Ask the user for confirmation using the `AskUser` tool: + 2. Ask the user for confirmation using the `ask_user` tool: - **header:** "Confirm" - **question:** "You asked to revert the [Track/Phase/Task]: '[Description]'. Is this correct?" - **type:** "yesno" @@ -48,7 +48,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai * **Scan All Plans:** You MUST read the **Tracks Registry** and every track's **Implementation Plan** (resolved via **Universal File Resolution Protocol** using the track's index file). * **Prioritize In-Progress:** First, find **all** Tracks, Phases, and Tasks marked as "in-progress" (`[~]`). * **Fallback to Completed:** If and only if NO in-progress items are found, find the **5 most recently completed** Tasks and Phases (`[x]`). - 2. **Present a Unified Hierarchical Menu:** You MUST present the results to the user using the `AskUser` tool. + 2. **Present a Unified Hierarchical Menu:** You MUST present the results to the user using the `ask_user` tool. - **header:** "Select Item" - **question:** "I found multiple in-progress items (or recently completed items). Please choose which one to revert:" - **type:** "choice" @@ -58,7 +58,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai - **Include an option Label:** "Other", **Description:** "A different Track, Task, or Phase." 3. **Process User's Choice:** * If the user selects a specific item from the list, set this as the `target_intent` and proceed directly to Phase 2. - * If the user selects "Other" (automatically added for "choice") or the explicit "Other" option provided, you must engage in a dialogue to find the correct target using `AskUser` tool with `type: "text"`. + * If the user selects "Other" (automatically added for "choice") or the explicit "Other" option provided, you must engage in a dialogue to find the correct target using `ask_user` tool with `type: "text"`. * Once a target is identified, loop back to Path A for final confirmation. 4. **Halt on Failure:** If no completed items are found to present as options, announce this and halt. @@ -98,7 +98,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai > ` - ('conductor(plan): Mark task complete')` > * **Action:** I will run `git revert` on these commits in reverse order. -2. **Final Go/No-Go:** Ask for final confirmation using the `AskUser` tool: +2. **Final Go/No-Go:** Ask for final confirmation using the `ask_user` tool: - **header:** "Confirm Plan" - **question:** "I've drafted the revert plan. Please review the following:\n\n[Drafted plan details here]\n\nDo you want to proceed with the revert plan?" - **type:** "choice" diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index dc913700..cff1fad3 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -68,7 +68,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **Begin Brownfield Project Initialization Protocol:** - **1.0 Pre-analysis Confirmation:** 1. **Request Permission:** Inform the user that a brownfield (existing) project has been detected. - 2. **Ask for Permission:** Request permission for a read-only scan to analyze the project using the `AskUser` tool with the following options: + 2. **Ask for Permission:** Request permission for a read-only scan to analyze the project using the `ask_user` tool with the following options: - **Header:** "Permission" - **Question:** "A brownfield (existing) project has been detected. May I perform a read-only scan to analyze the project?" - **Options:** @@ -105,7 +105,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - If a `.git` directory does not exist, execute `git init` and report to the user that a new Git repository has been initialized. 4. **Inquire about Project Goal (for Greenfield):** - - **Ask the user the following question using the `AskUser` tool and wait for their response before proceeding to the next step:** + - **Ask the user the following question using the `ask_user` tool and wait for their response before proceeding to the next step:** - **Header:** "Project Goal" - **Type:** "text" - **Question:** "What do you want to build?" @@ -121,12 +121,12 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.1 Generate Product Guide (Interactive) 1. **Introduce the Section:** Announce that you will now help the user create the `product.md`. -2. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. - - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. +2. **Gather Information:** Use the `ask_user` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `ask_user` tool calls. - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. - **Example Topics:** Target users, goals, features, etc. - **General Guidelines:** - * **1. Formulate the `AskUser` tool call:** Adhere to the following for each question in the `questions` array: + * **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). @@ -138,13 +138,13 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **multiSelect:** `false` (Exclusive choice) * **3. Interaction Flow:** - * Wait for the user's response after each `AskUser` tool call. + * Wait for the user's response after each `ask_user` tool call. * If the user selects "Autogenerate", stop asking questions and proceed to drafting. * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. - **FOR EXISTING PROJECTS (BROWNFIELD):** Batch project context-aware questions based on the code analysis. 3. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" is selected), generate the content for `product.md`. Use your best judgment to infer any missing details. - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. -4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `AskUser` tool. +4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `ask_user` tool. - **header:** "Review" - **question:** "I've drafted the product guide. Please review the following:\n\n```markdown\n[Drafted product.md content here]\n```\n\nWhat would you like to do next?" - **type:** "choice" @@ -159,12 +159,12 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.2 Generate Product Guidelines (Interactive) 1. **Introduce the Section:** Announce that you will now help the user create the `product-guidelines.md`. -2. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. - - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. +2. **Gather Information:** Use the `ask_user` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `ask_user` tool calls. - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. Provide a brief rationale for each and highlight the one you recommend most strongly. - **Example Topics:** Prose style, brand messaging, visual identity, etc. * **General Guidelines:** - * **1. Formulate the `AskUser` tool call:** Adhere to the following for each question in the `questions` array: + * **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:** Set to `true` for additive questions, `false` for exclusive choice. @@ -174,12 +174,12 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Autogenerate", Description: "Autogenerate and review product-guidelines.md" * **3. Interaction Flow:** - * Wait for the user's response after each `AskUser` tool call. + * Wait for the user's response after each `ask_user` tool call. * If the user selects "Autogenerate", stop asking questions and proceed to drafting. * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. 3. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" is selected), generate the content for `product-guidelines.md`. Use your best judgment to infer any missing details. **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. -4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `AskUser` tool. +4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `ask_user` tool. - **header:** "Review" - **question:** "I've drafted the product guidelines. Please review the following:\n\n```markdown\n[Drafted product-guidelines.md content here]\n```\n\nWhat would you like to do next?" - **type:** "choice" @@ -194,12 +194,12 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.3 Generate Tech Stack (Interactive) 1. **Introduce the Section:** Announce that you will now help define the technology stacks. -2. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. - - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. +2. **Gather Information:** Use the `ask_user` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT:** Limit your inquiry to a maximum of 5-8 details gathered across 1 or 2 `ask_user` tool calls. - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. - **Example Topics:** programming languages, frameworks, databases, etc. * **General Guidelines:** - * **1. Formulate the `AskUser` tool call:** Adhere to the following for each question in the `questions` array: + * **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:** Set to `true` for additive questions, `false` for exclusive choice. @@ -209,20 +209,20 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Autogenerate", Description: "Autogenerate and review tech-stack.md" * **3. Interaction Flow:** - * Wait for the user's response after each `AskUser` tool call. + * Wait for the user's response after each `ask_user` tool call. * If the user selects "Autogenerate", stop asking questions and proceed to drafting. * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. - **FOR EXISTING PROJECTS (BROWNFIELD):** - **CRITICAL WARNING:** Your goal is to document the project's *existing* tech stack, not to propose changes. - **State the Inferred Stack:** Based on the code analysis, you MUST state the technology stack that you have inferred. - - **Request Confirmation:** After stating the detected stack, you MUST ask the user for confirmation using the `AskUser` tool: + - **Request Confirmation:** After stating the detected stack, you MUST ask the user for confirmation using the `ask_user` tool: - **Header:** "Stack" - **Question:** "Based on my analysis, this is the inferred tech stack:\n\n[List of inferred technologies]\n\nIs this correct?" - **type:** "yesno" - - **Handle Disagreement:** If the user disputes the suggestion, acknowledge their input and allow them to provide the correct technology stack manually using `AskUser` tool with `type: "text"`. + - **Handle Disagreement:** If the user disputes the suggestion, acknowledge their input and allow them to provide the correct technology stack manually using `ask_user` tool with `type: "text"`. 3. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" is selected), generate the content for `tech-stack.md`. Use your best judgment to infer any missing details. - **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. -4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `AskUser` tool. +4. **User Confirmation Loop:** Present the drafted content and ask for approval using the `ask_user` tool. - **header:** "Review" - **question:** "I've drafted the tech stack. Please review the following:\n\n```markdown\n[Drafted tech-stack.md content here]\n```\n\nWhat would you like to do next?" - **type:** "choice" @@ -241,7 +241,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - List the available style guides by running `ls ~/.gemini/extensions/conductor/templates/code_styleguides/`. - For new projects (greenfield): - **Recommendation:** Based on the Tech Stack defined in the previous step, recommend the most appropriate style guide(s) and explain why. - - Ask the user how they would like to proceed using the `AskUser` tool: + - Ask the user how they would like to proceed using the `ask_user` tool: - **header:** "Style Guides" - **question:** "How would you like to proceed with the code style guides?" - **type:** "choice" @@ -250,7 +250,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Recommended" - Label: "Edit" - If the user chooses "Edit": - - Present the list of all available guides to the user using the `AskUser` tool: + - Present the list of all available guides to the user using the `ask_user` tool: - **header:** "Select" - **type:** "choice" - **multiSelect:** `true` @@ -258,7 +258,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **options:** Use the list of available guides as labels. - For existing projects (brownfield): - **Announce Selection:** Inform the user: "Based on the inferred tech stack, I will copy the following code style guides: ." - - **Ask for Customization:** Ask the user if they'd like to proceed using the `AskUser` tool: + - **Ask for Customization:** Ask the user if they'd like to proceed using the `ask_user` tool: - **header:** "Confirm" - **question:** "Would you like to proceed using only the suggested code style guides?" - **type:** "choice" @@ -266,7 +266,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **options:** - Label: "Yes" - Label: "Add More" - - **Handle Selection:** If the user chooses "Add More", present the full list using `AskUser` tool with `multiSelect: true`. + - **Handle Selection:** If the user chooses "Add More", present the full list using `ask_user` tool with `multiSelect: true`. - **Action:** Construct and execute a command to create the directory and copy all selected files. For example: `mkdir -p conductor/code_styleguides && cp ~/.gemini/extensions/conductor/templates/code_styleguides/python.md ~/.gemini/extensions/conductor/templates/code_styleguides/javascript.md conductor/code_styleguides/` - **Commit State:** Upon successful completion of the copy command, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "2.4_code_styleguides"}` @@ -275,7 +275,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re 1. **Copy Initial Workflow:** - Copy `~/.gemini/extensions/conductor/templates/workflow.md` to `conductor/workflow.md`. 2. **Customize Workflow:** - - Ask the user if they want to customize the workflow using the `AskUser` tool: + - Ask the user if they want to customize the workflow using the `ask_user` tool: - **header:** "Workflow" - **question:** "Do you want to use the default workflow or customize it?" - **type:** "choice" @@ -284,7 +284,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Default" - Label: "Customize" - If the user chooses "Customize": - - **Question 1:** Use `AskUser` tool. + - **Question 1:** Use `ask_user` tool. - **header:** "Coverage" - **question:** "The default required test code coverage is >80%. Do you want to change this percentage?" - **type:** "choice" @@ -292,8 +292,8 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **options:** - Label: "No" - Label: "Yes" - - If "Yes", use `AskUser` tool with `type: "text"` to get the value. - - **Question 2:** Use `AskUser` tool. + - If "Yes", use `ask_user` tool with `type: "text"` to get the value. + - **Question 2:** Use `ask_user` tool. - **header:** "Commits" - **question:** "Do you want to commit changes after each task or after each phase (group of tasks)?" - **type:** "choice" @@ -301,7 +301,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **options:** - Label: "Per Task" - Label: "Per Phase" - - **Question 3:** Use `AskUser` tool. + - **Question 3:** Use `ask_user` tool. - **header:** "Summaries" - **question:** "Do you want to use git notes or the commit message to record the task summary?" - **type:** "choice" @@ -347,11 +347,11 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 3.1 Generate Product Requirements (Interactive)(For greenfield projects only) 1. **Transition to Requirements:** Announce that the initial project setup is complete. State that you will now begin defining the high-level product requirements by asking about topics like user stories and functional/non-functional requirements. 2. **Analyze Context:** Read and analyze the content of `conductor/product.md` to understand the project's core concept. -3. **Gather Information:** Use the `AskUser` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. - - **CONSTRAINT** Limit your total inquiry for this section to a maximum of 5-8 details gathered across 1 or 2 `AskUser` tool calls. +3. **Gather Information:** Use the `ask_user` tool to ask relevant questions. You can batch up to 4 related questions in a single tool call to streamline the process. + - **CONSTRAINT** Limit your total inquiry for this section to a maximum of 5-8 details gathered across 1 or 2 `ask_user` tool calls. - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context. * **General Guidelines:** - * **1. Formulate the `AskUser` tool call:** Adhere to the following for each question in the `questions` array: + * **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:** Set to `true` for additive questions, `false` for exclusive choice. @@ -361,7 +361,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Autogenerate", Description: "Auto-generate the rest of requirements" * **3. Interaction Flow:** - * Wait for the user's response after each `AskUser` tool call. + * Wait for the user's response after each `ask_user` tool call. * If the user selects "Autogenerate", stop asking questions and proceed. * If the user provides "Other" for a choice, follow up with a "text" type question if necessary. - **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**. @@ -380,7 +380,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re To create the first track of this project, I suggest the following track: - Create user authentication flow for user sign in. ``` -3. **User Confirmation:** Present the generated track title to the user for review and approval using the `AskUser` tool. +3. **User Confirmation:** Present the generated track title to the user for review and approval using the `ask_user` tool. - **header:** "Confirm" - **question:** "To get the project started, I suggest the following track: . Do you approve?" - **type:** "choice" @@ -388,7 +388,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **options:** - Label: "Approve" - Label: "Revise" - - If the user declines, ask the user for clarification on what track to start with using `AskUser` tool with `type: "text"`. + - If the user declines, ask the user for clarification on what track to start with using `ask_user` tool with `type: "text"`. ### 3.3 Convert the Initial Track into Artifacts (Automated) 1. **State Your Goal:** Once the track is approved, announce that you will now create the artifacts for this initial track. From fef5dd29ef2e839dd06452b3b8a57c1f07bae007 Mon Sep 17 00:00:00 2001 From: Jerop Kipruto Date: Thu, 29 Jan 2026 15:46:56 -0500 Subject: [PATCH 3/3] feat(conductor): use ask_user tool in review command --- commands/conductor/review.toml | 58 ++++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 21 deletions(-) diff --git a/commands/conductor/review.toml b/commands/conductor/review.toml index 17304f12..7851f284 100644 --- a/commands/conductor/review.toml +++ b/commands/conductor/review.toml @@ -41,8 +41,15 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai 2. **Auto-Detect Scope:** - If no input, read the **Tracks Registry**. - Look for a track marked as `[~] In Progress`. - - If one exists, ask the user: "Do you want to review the in-progress track ''? (yes/no)" - - If no track is in progress, or user says "no", ask: "What would you like to review? (Enter a track name, or typing 'current' for uncommitted changes)" + - If one exists, ask the user using the `ask_user` tool: + - **header:** "Review Track" + - **question:** "Do you want to review the in-progress track ''?" + - **type:** "yesno" + - If no track is in progress, or user says "no", ask using the `ask_user` tool: + - **header:** "Select Scope" + - **question:** "What would you like to review?" + - **type:** "text" + - **placeholder:** "Enter track name, or 'current' for uncommitted changes" 3. **Confirm Scope:** Ensure you and the user agree on what is being reviewed. ### 2.2 Retrieve Context @@ -120,15 +127,18 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai - If only **Medium/Low** issues found: "Recommend **APPROVE WITH COMMENTS**." - If no issues found: "Recommend **APPROVE**." - **Action:** - - **If issues found:** Ask: - > "Do you want me to apply the suggested fixes, fix them manually yourself, or proceed to complete the track? - > A. **Apply Fixes:** Automatically apply the suggested code changes. - > B. **Manual Fix:** Stop so you can fix issues yourself. - > C. **Complete Track:** Ignore warnings and proceed to cleanup. - > Please enter your choice (A, B, or C)." - - **If "A" (Apply Fixes):** Apply the code modifications suggested in the findings using file editing tools. Then Proceed to next step. - - **If "B" (Manual Fix):** Terminate operation to allow user to edit code. - - **If "C" (Complete Track):** Proceed to the next step. + - **If issues found:** Ask using the `ask_user` tool: + - **header:** "Decision" + - **question:** "How would you like to proceed with the findings?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Apply Fixes" + - Label: "Manual Fix" + - Label: "Complete Track" + - **If "Apply Fixes":** Apply the code modifications suggested in the findings using file editing tools. Then Proceed to next step. + - **If "Manual Fix":** Terminate operation to allow user to edit code. + - **If "Complete Track":** Proceed to the next step. - **If no issues found:** Proceed to the next step. 2. **Track Cleanup:** @@ -136,23 +146,29 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai a. **Context Check:** If you are NOT reviewing a specific track (e.g., just reviewing current changes without a track context), SKIP this entire section. - b. **Ask for User Choice:** - > "Review complete. What would you like to do with track ''? - > A. **Archive:** Move to `conductor/archive/` and update registry. - > B. **Delete:** Permanently remove from system. - > C. **Skip:** Leave as is. - > Please enter your choice (A, B, or C)." + b. **Ask for User Choice:** Prompt the user with the available options for the reviewed track using the `ask_user` tool: + - **header:** "Cleanup" + - **question:** "Review complete. What would you like to do with track ''?" + - **type:** "choice" + - **multiSelect:** `false` + - **options:** + - Label: "Archive" + - Label: "Delete" + - Label: "Skip" c. **Handle User Response:** - * **If "A" (Archive):** + * **If "Archive":** i. **Setup:** Ensure `conductor/archive/` exists. ii. **Move:** Move track folder to `conductor/archive/`. iii. **Update Registry:** Remove track section from **Tracks Registry**. iv. **Commit:** Stage registry and archive. Commit: `chore(conductor): Archive track ''`. v. **Announce:** "Track '' archived." - * **If "B" (Delete):** - i. **Confirm:** "WARNING: Irreversible deletion. Proceed? (yes/no)" + * **If "Delete":** + i. **Confirm:** Ask for final confirmation using the `ask_user` tool: + - **header:** "Confirm" + - **question:** "WARNING: This is an irreversible deletion. Do you want to proceed?" + - **type:** "yesno" ii. **If yes:** Delete track folder, remove from **Tracks Registry**, commit (`chore(conductor): Delete track ''`), announce success. iii. **If no:** Cancel. - * **If "C" (Skip):** Leave track as is. + * **If "Skip":** Leave track as is. """