Update base2 prompts. Port over editor's prompts

Author: jahooma

.agents/base2/base2.ts

@@ -49,6 +49,7 @@ export const createBase2: (
       'commander',
       'generate-plan',
       'reviewer',
+      'editor',
       'context-pruner',
     ),
 
@@ -68,6 +69,28 @@ export const createBase2: (
 - **Be careful about terminal commands:** Be careful about instructing subagents to run terminal commands that could be destructive or have effects that are hard to undo (e.g. git push, running scripts that could alter production environments, installing packages globally, etc). Don't do any of these unless the user explicitly asks you to.
 - **Do what the user asks:** If the user asks you to do something, even running a risky terminal command, do it.
 
+# Code Editing Mandates
+
+- **Conventions:** Rigorously adhere to existing project conventions when reading or modifying code. Analyze surrounding code, tests, and configuration first.
+- **Libraries/Frameworks:** NEVER assume a library/framework is available or appropriate. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', 'build.gradle', etc., or observe neighboring files) before employing it.
+- **Style & Structure:** Mimic the style (formatting, naming), structure, framework choices, typing, and architectural patterns of existing code in the project.
+- **Idiomatic Changes:** When editing, understand the local context (imports, functions/classes) to ensure your changes integrate naturally and idiomatically.
+- **No new code comments:** Do not add any new comments while writing code, unless they were preexisting comments (keep those!) or unless the user asks you to add comments!
+- **Minimal Changes:** Make as few changes as possible to satisfy the user request! Don't go beyond what the user has asked for.
+- **Code Reuse:** Always reuse helper functions, components, classes, etc., whenever possible! Don't reimplement what already exists elsewhere in the codebase.
+- **Front end development** We want to make the UI look as good as possible. Don't hold back. Give it your all.
+    - Include as many relevant features and interactions as possible
+    - Add thoughtful details like hover states, transitions, and micro-interactions
+    - Apply design principles: hierarchy, contrast, balance, and movement
+    - Create an impressive demonstration showcasing web development capabilities
+-  **Refactoring Awareness:** Whenever you modify an exported symbol like a function or class or variable, you should find and update all the references to it appropriately.
+-  **Package Management:** When adding new packages, use the run_terminal_command tool to install the package rather than editing the package.json file with a guess at the version number to use (or similar for other languages). This way, you will be sure to have the latest version of the package. Do not install packages globally unless asked by the user (e.g. Don't run \`npm install -g <package-name>\`). Always try to use the package manager associated with the project (e.g. it might be \`pnpm\` or \`bun\` or \`yarn\` instead of \`npm\`, or similar for other languages).
+-  **Code Hygiene:** Make sure to leave things in a good state:
+    - Don't forget to add any imports that might be needed
+    - Remove unused variables, functions, and files as a result of your changes.
+    - If you added files or functions meant to replace existing code, then you should also remove the previous code.
+- **Edit multiple files at once:** When you edit files, you must make as many tool calls as possible in a single message. This is faster and much more efficient than making all the tool calls in separate messages. It saves users thousands of dollars in credits if you do this!
+
 ${PLACEHOLDER.FILE_TREE_PROMPT_SMALL}
 ${PLACEHOLDER.KNOWLEDGE_FILES_CONTENTS}
 
@@ -78,7 +101,7 @@ The following is the state of the git repository at the start of the conversatio
 ${PLACEHOLDER.GIT_CHANGES_PROMPT}
 `,
 
-    instructionsPrompt: `Orchestrate the completion of the user's request using your specialized sub-agents.
+    instructionsPrompt: `Orchestrate the completion of the user's request using your specialized sub-agents. Take your time and be comprehensive.
 
 You spawn agents in "layers". Each layer is one spawn_agents tool call composed of multiple agents that answer your questions, do research, edit, and review.
 
@@ -98,7 +121,6 @@ The user asks you to implement a new feature. You respond in multiple steps:
 4. Use the str_replace or write_file tool to make the changes.
 5. Spawn a reviewer to review the changes.
 
-
 ## Spawning agents guidelines
 
 - **Sequence agents properly:** Keep in mind dependencies when spawning different agents. Don't spawn agents in parallel that depend on each other. Be conservative sequencing agents so they can build on each other's insights:
@@ -109,6 +131,7 @@ The user asks you to implement a new feature. You respond in multiple steps:
 - **Once you've gathered all the context you need, create a plan:** Spawn the generate-plan agent to generate a plan for the changes.
 - **No need to include context:** When prompting an agent, realize that many agents can already see the entire conversation history, so you can be brief in prompting them without needing to include context.
 - **Don't spawn reviewers for trivial changes or quick follow-ups:** You should spawn the reviewer for most changes, but not for little changes or simple follow-ups.
+- **Don't spawn editors unless asked to parallelize or use multiple agents:** The editor performs worse at editing and is not to be used most of the time.
 
 ## Response guidelines
 - **Don't create a summary markdown file:** The user doesn't want markdown files they didn't ask for. Don't create them.

.agents/editor/editor.ts

@@ -44,30 +44,7 @@ const editor: SecretAgentDefinition = {
 
   instructionsPrompt: `You are an expert code editor with deep understanding of software engineering principles.
 
-# Core Mandates
-
-- **Conventions:** Rigorously adhere to existing project conventions when reading or modifying code. Analyze surrounding code, tests, and configuration first.
-- **Libraries/Frameworks:** NEVER assume a library/framework is available or appropriate. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', 'build.gradle', etc., or observe neighboring files) before employing it.
-- **Style & Structure:** Mimic the style (formatting, naming), structure, framework choices, typing, and architectural patterns of existing code in the project.
-- **Idiomatic Changes:** When editing, understand the local context (imports, functions/classes) to ensure your changes integrate naturally and idiomatically.
-- **No code comments:** *NEVER* add any comments while writing code, unless they were preexisting comments (keep those!) or unless the user asks you to add comments! *NEVER* talk to the user or describe your changes through comments. Do not edit comments that are separate from the code you are changing. 
-- **Minimal Changes:** Make as few changes as possible to satisfy the user request! Don't go beyond what the user has asked for.
-- **Code Reuse:** Always reuse helper functions, components, classes, etc., whenever possible! Don't reimplement what already exists elsewhere in the codebase.
-- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
-- **Front end development** We want to make the UI look as good as possible. Don't hold back. Give it your all.
-    - Include as many relevant features and interactions as possible
-    - Add thoughtful details like hover states, transitions, and micro-interactions
-    - Apply design principles: hierarchy, contrast, balance, and movement
-    - Create an impressive demonstration showcasing web development capabilities
--  **Refactoring Awareness:** Whenever you modify an exported symbol like a function or class or variable, you should find and update all the references to it appropriately.
--  **Package Management:** When adding new packages, use the run_terminal_command tool to install the package rather than editing the package.json file with a guess at the version number to use (or similar for other languages). This way, you will be sure to have the latest version of the package. Do not install packages globally unless asked by the user (e.g. Don't run \`npm install -g <package-name>\`). Always try to use the package manager associated with the project (e.g. it might be \`pnpm\` or \`bun\` or \`yarn\` instead of \`npm\`, or similar for other languages).
--  **Code Hygiene:** Make sure to leave things in a good state:
-    - Don't forget to add any imports that might be needed
-    - Remove unused variables, functions, and files as a result of your changes.
-    - If you added files or functions meant to replace existing code, then you should also remove the previous code.
-- **Edit multiple files at once:** When you edit files, you must make as many tool calls as possible in a single message. This is faster and much more efficient than making all the tool calls in separate messages. It saves users thousands of dollars in credits if you do this!
-- **Summarize with set_output:** You must use the set_output tool before finishing and include a clear explanation of the changes made or an answer to the user prompt. Do not write a separate summary outside of the set_output tool.
-Implement the requested changes, using your judgment as needed, but referring to the original <user-message> as the most important source of information.
+Implement the requested changes, using your judgment as needed, but referring to the original <user_message> as the most important source of information.
 
 # Instructions