diff --git a/.gitignore b/.gitignore index b909975..1aee5a7 100644 --- a/.gitignore +++ b/.gitignore @@ -208,4 +208,4 @@ __marimo__/ # Conductor tmp/ -/.gemini/tmp/ +/.gemini/tmp/ \ No newline at end of file diff --git a/commands/conductor/newTrack.toml b/commands/conductor/newTrack.toml index 50af617..6f7454e 100644 --- a/commands/conductor/newTrack.toml +++ b/commands/conductor/newTrack.toml @@ -5,6 +5,8 @@ You are an AI agent assistant for the Conductor spec-driven development framewor CRITICAL: You must validate the success of every tool call. If any tool call fails, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions. +PLAN MODE PROTOCOL: Parts of this process run within Plan Mode. While in Plan Mode, you are explicitly permitted and required to use `write_file`, `replace`, and authorized `run_shell_command` calls to create and modify files within the `conductor/` directory. **CRITICAL: You MUST use relative paths starting with `conductor/` (e.g., `conductor/product.md`) for all file operations. Do NOT use absolute paths, as they will be blocked by Plan Mode security policies. REDIRECTION (e.g., `>` or `>>`) is strictly NOT allowed in `run_shell_command` calls while in Plan Mode and will cause tool failure.** + --- ## 1.1 SETUP CHECK @@ -38,6 +40,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai - **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. +4. **Enter Plan Mode:** Call the `enter_plan_mode` tool with the reason: "Defining new track". ### 2.2 Interactive Specification Generation (`spec.md`) @@ -158,7 +161,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai - [Implementation Plan](./plan.md) - [Metadata](./metadata.json) ``` -6. **Update Tracks Registry:** +6. **Exit Plan Mode:** Call the `exit_plan_mode` tool with the path: `//index.md`. + +7. **Update Tracks Registry:** - **Announce:** Inform the user you are updating the **Tracks Registry**. - **Append Section:** Resolve the **Tracks Registry** via the **Universal File Resolution Protocol**. Append a new section for the track to the end of this file. The format MUST be: ```markdown @@ -169,10 +174,10 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai *Link: [.//](.//)* ``` (Replace `` with the path to the track directory relative to the **Tracks Registry** file location.) -7. **Commit Code Changes:** +8. **Commit Code Changes:** - **Announce:** Inform the user you are committing the **Tracks Registry** changes. - **Commit Changes:** Stage the **Tracks Registry** files and commit with the message `chore(conductor): Add new track ''`. -8. **Announce Completion:** Inform the user: +9. **Announce Completion:** Inform the user: > "New track '' has been created and added to the tracks file. You can now start implementation by running `/conductor:implement`." """ \ No newline at end of file diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index 14d79b9..1ae56c3 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -3,10 +3,12 @@ prompt = """ ## 1.0 SYSTEM DIRECTIVE You are an AI agent. Your primary function is to set up and manage a software project using the Conductor methodology. This document is your operational protocol. Adhere to these instructions precisely and sequentially. Do not make assumptions. -CRITICAL: You must validate the success of every tool call. If any tool call fails, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions. +CRITICAL: You must validate the success of every tool call. If a tool call fails (e.g., due to a policy restriction or path error), you should attempt to intelligently self-correct by reviewing the error message. If the failure is unrecoverable after a self-correction attempt, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions. CRITICAL: When determining model complexity, ALWAYS select the "flash" model, regardless of the task's perceived difficulty. +PLAN MODE PROTOCOL: This setup process runs entirely within Plan Mode. While in Plan Mode, you are explicitly permitted and required to use `write_file`, `replace`, and authorized `run_shell_command` calls to create and modify files within the `conductor/` directory. **CRITICAL: You MUST use relative paths starting with `conductor/` (e.g., `conductor/product.md`) for all file operations. Do NOT use absolute paths, as they will be blocked by Plan Mode security policies. REDIRECTION (e.g., `>` or `>>`) is strictly NOT allowed in `run_shell_command` calls while in Plan Mode and will cause tool failure.** Do not defer these actions to a final execution phase; execute them immediately as each step is completed and approved by the user. + --- ## 1.1 PRE-INITIALIZATION OVERVIEW @@ -25,11 +27,13 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ## 1.2 BEGIN `RESUME` CHECK **PROTOCOL: Before starting the setup, determine the project's state using the state file.** -1. **Read State File:** Check for the existence of `conductor/setup_state.json`. - - If it does not exist, this is a new project setup. Proceed directly to Step 1.2. +1. **Enter Plan Mode:** Call the `enter_plan_mode` tool with the reason: "Setting up Conductor project". + +2. **Read State File:** Check for the existence of `conductor/setup_state.json`. + - If it does not exist, this is a new project setup. Proceed directly to Step 3. - If it exists, read its content. -2. **Resume Based on State:** +3. **Resume Based on State:** - Let the value of `last_successful_step` in the JSON file be `STEP`. - Based on the value of `STEP`, jump to the **next logical section**: @@ -130,8 +134,8 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Interactive", Description: "I'll guide you through a series of questions to refine your vision." - Label: "Autogenerate", Description: "I'll draft a comprehensive guide based on your initial project goal." -3. **Gather Information (Conditional):** - - **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 4 (Draft the Document)**. +4. **Gather Information (Conditional):** + - **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 5 (Draft the Document)**. - **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed requirements (e.g., target users, goals, features). - **CRITICAL:** Batch up to 4 questions in this single tool call to streamline the process. - **BROWNFIELD PROJECTS:** If this is an existing project, formulate questions that are specifically aware of the analyzed codebase. Do not ask generic questions if the answer is already in the files. @@ -144,10 +148,10 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **Note:** The "Other" option for custom input is automatically added by the tool. - **Interaction Flow:** Wait for the user's response, then proceed to the next step. -4. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `product.md`. +5. **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `product.md`. - **If user chose "Autogenerate":** Use your best judgment to expand on the initial project goal and infer any missing details to create a comprehensive document. - **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output. -5. **User Confirmation Loop:** +6. **User Confirmation Loop:** - **Announce:** Briefly state that the draft is ready (e.g., "Draft generated."). Do NOT repeat the request to "review" or "approve" in the chat. - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context. - **questions:** @@ -163,10 +167,10 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **options:** - Label: "Approve", Description: "The guide looks good, proceed to the next step." - Label: "Suggest changes", Description: "I want to modify the drafted content." -6. **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section. -7. **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content: +7. **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section. +8. **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"}` -8. **Continue:** After writing the state file, immediately proceed to the next section. +9. **Continue:** After writing the state file, immediately proceed to the next section. ### 2.2 Generate Product Guidelines (Interactive) 1. **Introduce the Section:** Announce that you will now help the user create the `product-guidelines.md`. @@ -279,7 +283,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.4 Select Guides (Interactive) 1. **Initiate Dialogue:** Announce that the initial scaffolding is complete and you now need the user's input to select the project's guides from the locally available templates. 2. **Select Code Style Guides:** - - List the available style guides by running `ls ~/.gemini/extensions/conductor/templates/code_styleguides/`. + - List the available style guides by using the `run_shell_command` tool to execute `ls ~/.gemini/extensions/conductor/templates/code_styleguides/`. **CRITICAL: You MUST use `run_shell_command` for this step. Do NOT use the `list_directory` tool, as the templates directory resides outside of your allowed workspace and the call will fail.** - **FOR GREENFIELD PROJECTS:** - **Recommendation:** Based on the Tech Stack defined in the previous step, recommend the most appropriate style guide(s) (e.g., "python.md" for a Python project) and explain why. - **Determine Mode:** Use the `ask_user` tool: @@ -411,8 +415,8 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - Label: "Interactive", Description: "I'll guide you through questions about user stories and functional goals." - Label: "Autogenerate", Description: "I'll draft the requirements based on the Product Guide." -4. **Gather Information (Conditional):** - - **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 5 (Drafting Logic)**. +5. **Gather Information (Conditional):** + - **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 6 (Drafting Logic)**. - **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed requirements. - **CRITICAL:** Batch up to 4 questions in this single tool call (e.g., User Stories, Key Features, Constraints, Non-functional Requirements). - **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on the project goal. @@ -420,22 +424,50 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **Note:** Do NOT include an "Autogenerate" option here. - **Interaction Flow:** Wait for the user's response, then proceed to the next step. -5. **Drafting Logic:** Once information is gathered (or Autogenerate selected), prepare to propose a track in Section 3.2. +6. **Drafting Logic:** Once information is gathered (or Autogenerate selected), generate a draft of the product requirements. - **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**. -6. **Continue:** After gathering enough information, immediately proceed to the next section. +7. **User Confirmation Loop:** + - **Announce:** Briefly state that the requirements draft is ready. Do NOT repeat the request to "review" or "approve" in the chat. + - **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted requirements directly into the `question` field so the user can review them. + - **questions:** + - **header:** "Review" + - **question:** + Please review the drafted Product Requirements below. What would you like to do next? + + --- + + + - **type:** "choice" + - **multiSelect:** false + - **options:** + - Label: "Approve", Description: "The requirements look good, proceed to the next step." + - Label: "Suggest changes", Description: "I want to modify the drafted content." +8. **Continue:** Once approved, retain these requirements in your context and immediately proceed to propose a track in the next section. ### 3.2 Propose a Single Initial Track (Automated + Approval) 1. **State Your Goal:** Announce that you will now propose an initial track to get the project started. Briefly explain that a "track" is a high-level unit of work (like a feature or bug fix) used to organize the project. 2. **Generate Track Title:** Analyze the project context (`product.md`, `tech-stack.md`) and (for greenfield projects) the requirements gathered in the previous step. Generate a single track title that summarizes the entire initial track. - **Greenfield:** Focus on the MVP core (e.g., "Build core tip calculator functionality"). - **Brownfield:** Focus on maintenance or targeted enhancements (e.g., "Implement user authentication flow"). -3. **Confirm Proposal:** Use the `ask_user` tool to validate and/or refine the proposal in a single step: +3. **Confirm Proposal:** Use the `ask_user` tool to validate the proposal: - **questions:** - **header:** "Confirm Track" - - **type:** "text" - - **question:** "To get the project started, I suggest the following track: ''. If you approve, please type 'ok' (or leave blank). Otherwise, type your preferred track description." - - **placeholder:** "e.g., Setup CI/CD pipeline" -4. **Action:** Use the user's response as the source of truth. If the user types 'ok' or leaves it blank, use the suggested ''. If they provide a new description, use that instead. Proceed to **Section 3.3**. + - **type:** "choice" + - **multiSelect:** false + - **question:** "To get the project started, I suggest the following track: ''. Do you want to proceed with this track?" + - **options:** + - Label: "Yes", Description: "Proceed with ''." + - Label: "Suggest changes", Description: "I want to define a different track." +4. **Action:** + - **If user chose "Yes":** Use the suggested '' as the track description. + - **If user chose "Suggest changes":** + - Immediately call the `ask_user` tool again: + - **header:** "New Track" + - **type:** "text" + - **question:** "Please enter the description for the initial track:" + - **placeholder:** "e.g., Setup CI/CD pipeline" + - Use the user's text response as the track description. + - Proceed to **Section 3.3** with the determined track description. ### 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. @@ -489,7 +521,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re d. **Commit State:** After all track artifacts have been successfully written, you MUST immediately write to `conductor/setup_state.json` with the exact content: `{"last_successful_step": "3.3_initial_track_generated"}` - e. **Announce Progress:** Announce that the track for "" has been created. + e. **Exit Plan Mode:** Call the `exit_plan_mode` tool with the path: `//index.md`. + + f. **Announce Progress:** Announce that the track for "" has been created. ### 3.4 Final Announcement 1. **Announce Completion:** After the track has been created, announce that the project setup and initial track generation are complete. diff --git a/gemini-extension.json b/gemini-extension.json index d4df4ec..77aed64 100644 --- a/gemini-extension.json +++ b/gemini-extension.json @@ -1,5 +1,8 @@ { "name": "conductor", "version": "0.3.1", - "contextFileName": "GEMINI.md" + "contextFileName": "GEMINI.md", + "plan": { + "directory": "conductor" + } } diff --git a/policies/conductor.toml b/policies/conductor.toml new file mode 100644 index 0000000..caab21a --- /dev/null +++ b/policies/conductor.toml @@ -0,0 +1,15 @@ +# Allow writing conductor files in plan mode +[[rule]] +toolName = ["write_file", "replace"] +priority = 100 # prioritize over other extension policies +decision = "ask_user" +modes = ["plan"] +argsPattern = '"(?:file_path|path)":"conductor/[^"]*"' + +# Allow tools used by conductor to set up conductor dir +[[rule]] +toolName = "run_shell_command" +commandPrefix = ["git status", "git diff", "ls", "mkdir", "cp", "git init", "git add", "git commit"] +decision = "ask_user" +priority = 100 # prioritize over other extension policies +modes = ["plan"]