feat: integrate Plan Mode and extension-native policies into Conductor #133
+84
−27
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -208,4 +208,4 @@ __marimo__/ | |
| # Conductor | ||
| tmp/ | ||
|
|
||
| /.gemini/tmp/ | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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 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. | ||
|
Contributor
There was a problem hiding this comment. urelated to this PR: what is this line 8 for?
Contributor
There was a problem hiding this comment. In the early days of Conductor, free-tier users were consuming too many tokens due to overuse of the pro model. Since there was no feature to dynamically select the model for certain instructions, this was an attempt to tell the agent to select the Flash agent more often. Let's brainstorm the best way to tackle this issue.
Contributor
Author
There was a problem hiding this comment. i needed to beef up to instructions to get it to stop spiraling if plan mode wasn't available - instead of stopping, conductor should try to navigate around it
Contributor
There was a problem hiding this comment. Given that it's about model quota concerns, I think we should now remove line 8 (in a separate PR though). |
||
|
|
||
| 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. | ||
|
Contributor
There was a problem hiding this comment. "Do not defer these actions to a" : what 'actions' are we referring to? Can we clarify
Contributor
Author
There was a problem hiding this comment. the plan mode instructions on gemini cli seem to encourage postponing non-readonly tool calls until after plan mode is executed. i added this to make sure the agent executes the tool call right away
Contributor
There was a problem hiding this comment. Shall we tell this to the model too? e.g. ".... Do not defer these actions to a final execution phase..." -> "... Do not defer needed tool calls in this phase to a final execution phase ..."
Contributor
There was a problem hiding this comment. Let's evaluate how impactful our instructions are, so we can use fewer tokens and make our commands easier to read and maintain. In the second paragraph before the CRITICAL section, since policies are the source of truth for allowing tools, how important is it to reiterate to the agent which tools are permitted and required? This is a note to open the discussion on evaluating, avoiding, and removing noisy instructions. Other cases: |
||
|
|
||
| --- | ||
|
|
||
| ## 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. **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. | ||
|
|
||
| 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." | ||
|
|
||
| 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. | ||
|
|
||
| 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. | ||
| 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." | ||
| 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"}` | ||
| 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 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.** | ||
|
Contributor
There was a problem hiding this comment. Let's discuss if we want to keep using explicit tool names in our prompts. This also applies to other cases like Should we write more flexible prompts that allow the assistant to choose the best tool for the job, or should we tell it exactly which tool to use? Notes |
||
| - **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,31 +415,59 @@ 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." | ||
|
|
||
| 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. | ||
| - **Formulation Guidelines:** Use "choice" type. Set `multiSelect` to `true` for additive answers. Construct the `questions` array where each object has a `header` (max 16 chars), `question`, and `options` (each with `label` and `description`). | ||
| - **Note:** Do NOT include an "Autogenerate" option here. | ||
| - **Interaction Flow:** Wait for the user's response, then proceed to the next step. | ||
|
|
||
| 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)**. | ||
| 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? | ||
|
|
||
| --- | ||
|
|
||
| <Insert Drafted Requirements Here> | ||
| - **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 the proposal: | ||
| - **questions:** | ||
| - **header:** "Confirm Track" | ||
| - **type:** "choice" | ||
| - **multiSelect:** false | ||
| - **question:** "To get the project started, I suggest the following track: '<Track Title>'. Do you want to proceed with this track?" | ||
| - **options:** | ||
| - Label: "Yes", Description: "Proceed with '<Track Title>'." | ||
| - Label: "Suggest changes", Description: "I want to define a different track." | ||
| 4. **Action:** | ||
| - **If user chose "Yes":** Use the suggested '<Track Title>' 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. **Exit Plan Mode:** Call the `exit_plan_mode` tool with the path: `<Tracks Directory>/<track_id>/index.md`. | ||
|
|
||
| f. **Announce Progress:** Announce that the track for "<Track Description>" 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. | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,8 @@ | ||
| { | ||
| "name": "conductor", | ||
| "version": "0.3.1", | ||
| "contextFileName": "GEMINI.md", | ||
| "plan": { | ||
| "directory": "conductor" | ||
| } | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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"] |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: see review comment here.