@amical/aiagent-sdk 0.1.0 → 0.1.2

package/src/parser/index.ts

@@ -1,111 +0,0 @@
-import { AgentDefaultTool } from "../shared/tools"
-
-export type AssistantMessageContent = TextStreamContent | ToolUse | ReasoningStreamContent
-
-export { parseAssistantMessageV2 } from "./parse-assistant-message"
-
-export interface TextStreamContent {
-	type: "text"
-	content: string
-	partial: boolean
-}
-
-export const toolParamNames = [
-	"command",
-	"requires_approval",
-	"path",
-	"absolutePath",
-	"content",
-	"diff",
-	"regex",
-	"file_pattern",
-	"recursive",
-	"action",
-	"url",
-	"coordinate",
-	"text",
-	"query",
-	"allowed_domains",
-	"blocked_domains",
-	"prompt",
-	"server_name",
-	"tool_name",
-	"arguments",
-	"uri",
-	"question",
-	"options",
-	"response",
-	"result",
-	"context",
-	"title",
-	"what_happened",
-	"steps_to_reproduce",
-	"api_request_output",
-	"additional_context",
-	"needs_more_exploration",
-	"task_progress",
-	"timeout",
-	"input",
-	"from_ref",
-	"to_ref",
-	"skill_name",
-	"prompt_1",
-	"prompt_2",
-	"prompt_3",
-	"prompt_4",
-	"prompt_5",
-	"start_line",
-	"end_line",
-] as const
-
-export type ToolParamName = (typeof toolParamNames)[number]
-
-export interface ToolUse {
-	type: "tool_use"
-	name: AgentDefaultTool | string // id of the tool being used
-	// params is a partial record, allowing only some or none of the possible parameters to be used
-	params: Partial<Record<ToolParamName, string>>
-	partial: boolean
-	/**
-	 * Whether this tool use was initiated by a native tool call
-	 */
-	isNativeToolCall?: boolean
-	/**
-	 * The call / response ID this tool use is associated with.
-	 */
-	call_id?: string // optional call ID for tracking tool use calls
-	/**
-	 * Thought signature associated with this tool use, used by Gemini
-	 */
-	signature?: string
-}
-
-export interface ReasoningStreamContent {
-	type: "reasoning"
-	/**
-	 * The reasoning text generated by the model.
-	 * Redacted reasoning block will have this field set to "[REDACTED]" or an empty string.
-	 */
-	reasoning: string
-	/**
-	 * openrouter has various properties that we can pass back unmodified in api requests to preserve reasoning traces
-	 */
-	details?: any
-	/**
-	 * It's used when sending the thinking block back to the  API.
-	 * API expects this in completed form, not as array of deltas.
-	 */
-	signature?: string
-	/**
-	 * whether this reasoning block has been redacted
-	 */
-	redacted?: boolean
-	/**
-	 * redacted data
-	 */
-	data?: string
-	/**
-	 * Indicates whether this is a partial reasoning block
-	 */
-	partial: boolean
-}

package/src/parser/parse-assistant-message.ts

@@ -1,240 +0,0 @@
-import { AgentDefaultTool, getToolUseNames } from "../shared/tools"
-import { nanoid } from "nanoid"
-import { AssistantMessageContent, TextStreamContent, ToolParamName, ToolUse } from "./index" // Assuming types are defined in index.ts or a similar file
-
-// parseAssistantmessageV1 removed in https://github.com/cline/cline/pull/5425
-
-/**
- * @description **Version 2**
- * Parses an assistant message string potentially containing mixed text and tool usage blocks
- * marked with XML-like tags into an array of structured content objects.
- *
- * This version aims for efficiency by avoiding the character-by-character accumulator of V1.
- * It iterates through the string using an index `i`. At each position, it checks if the substring
- * *ending* at `i` matches any known opening or closing tags for tools or parameters using `startsWith`
- * with an offset.
- * It uses pre-computed Maps (`toolUseOpenTags`, `toolParamOpenTags`) for quick tag lookups.
- * State is managed using indices (`currentTextContentStart`, `currentToolUseStart`, `currentParamValueStart`)
- * pointing to the start of the current block within the original `assistantMessage` string.
- * Slicing is used to extract content only when a block (text, parameter, or tool use) is completed.
- * Special handling for `write_to_file` and `new_rule` content parameters is included, using `indexOf`
- * and `lastIndexOf` on the relevant slice to handle potentially nested closing tags.
- * If the input string ends mid-block, the last open block is added and marked as partial.
- *
- * @param assistantMessage The raw string output from the assistant.
- * @returns An array of `AssistantMessageContent` objects, which can be `TextContent` or `ToolUse`.
- *          Blocks that were not fully closed by the end of the input string will have their `partial` flag set to `true`.
- */
-export function parseAssistantMessageV2(assistantMessage: string, toolParamNames: any): AssistantMessageContent[] {
-	const contentBlocks: AssistantMessageContent[] = []
-	let currentTextContentStart = 0 // Index where the current text block started
-	let currentTextContent: TextStreamContent | undefined
-	let currentToolUseStart = 0 // Index *after* the opening tag of the current tool use
-	let currentToolUse: ToolUse | undefined
-	let currentParamValueStart = 0 // Index *after* the opening tag of the current param
-	let currentParamName: ToolParamName | undefined
-
-	// Precompute tags for faster lookups
-	const toolUseOpenTags = new Map<string, string>()
-	const toolParamOpenTags = new Map<string, ToolParamName>()
-	for (const name of getToolUseNames()) {
-		toolUseOpenTags.set(`<${name}>`, name)
-	}
-	for (const name of toolParamNames) {
-		toolParamOpenTags.set(`<${name}>`, name)
-	}
-
-	const len = assistantMessage.length
-	for (let i = 0; i < len; i++) {
-		const currentCharIndex = i
-
-		// --- State: Parsing a Tool Parameter ---
-		if (currentToolUse && currentParamName) {
-			const closeTag = `</${currentParamName}>`
-			// Check if the string *ending* at index `i` matches the closing tag
-			if (
-				currentCharIndex >= closeTag.length - 1 &&
-				assistantMessage.startsWith(
-					closeTag,
-					currentCharIndex - closeTag.length + 1, // Start checking from potential start of tag
-				)
-			) {
-				// Found the closing tag for the parameter
-				const value = assistantMessage
-					.slice(
-						currentParamValueStart, // Start after the opening tag
-						currentCharIndex - closeTag.length + 1, // End before the closing tag
-					)
-					.trim()
-				currentToolUse.params[currentParamName] = value
-				currentParamName = undefined // Go back to parsing tool content
-				// We don't continue loop here, need to check for tool close or other params at index i
-			} else {
-				continue // Still inside param value, move to next char
-			}
-		}
-
-		// --- State: Parsing a Tool Use (but not a specific parameter) ---
-		if (currentToolUse && !currentParamName) {
-			// Ensure we are not inside a parameter already
-			// Check if starting a new parameter
-			let startedNewParam = false
-			for (const [tag, paramName] of toolParamOpenTags.entries()) {
-				if (currentCharIndex >= tag.length - 1 && assistantMessage.startsWith(tag, currentCharIndex - tag.length + 1)) {
-					currentParamName = paramName
-					currentParamValueStart = currentCharIndex + 1 // Value starts after the tag
-					startedNewParam = true
-					break
-				}
-			}
-			if (startedNewParam) {
-				continue // Handled start of param, move to next char
-			}
-
-			// Check if closing the current tool use
-			const toolCloseTag = `</${currentToolUse.name}>`
-			if (
-				currentCharIndex >= toolCloseTag.length - 1 &&
-				assistantMessage.startsWith(toolCloseTag, currentCharIndex - toolCloseTag.length + 1)
-			) {
-				// End of the tool use found
-				// Special handling for content params *before* finalizing the tool
-				const toolContentSlice = assistantMessage.slice(
-					currentToolUseStart, // From after the tool opening tag
-					currentCharIndex - toolCloseTag.length + 1, // To before the tool closing tag
-				)
-
-				// Check if content parameter needs special handling (write_to_file/new_rule)
-				// This check is important if the closing </content> tag was missed by the parameter parsing logic
-				// (e.g., if content is empty or parsing logic prioritizes tool close)
-				const contentParamName: ToolParamName = "content"
-				if (
-					currentToolUse.name === AgentDefaultTool.FILE_NEW /* || currentToolUse.name === "new_rule" */ &&
-					toolContentSlice.includes(`<${contentParamName}>`)
-				) {
-					const contentStartTag = `<${contentParamName}>`
-					const contentEndTag = `</${contentParamName}>`
-					const contentStart = toolContentSlice.indexOf(contentStartTag)
-					// Use lastIndexOf for robustness against nested tags
-					const contentEnd = toolContentSlice.lastIndexOf(contentEndTag)
-
-					if (contentStart !== -1 && contentEnd !== -1 && contentEnd > contentStart) {
-						const contentValue = toolContentSlice.slice(contentStart + contentStartTag.length, contentEnd).trim()
-						currentToolUse.params[contentParamName] = contentValue
-					}
-				}
-
-				currentToolUse.partial = false // Mark as complete
-				contentBlocks.push(currentToolUse)
-				currentToolUse = undefined // Reset state
-				currentTextContentStart = currentCharIndex + 1 // Potential text starts after this tag
-				continue // Move to next char
-			}
-			// If not starting a param and not closing the tool, continue accumulating tool content implicitly
-			continue
-		}
-
-		// --- State: Parsing Text / Looking for Tool Start ---
-		if (!currentToolUse) {
-			// Check if starting a new tool use
-			let startedNewTool = false
-			for (const [tag, toolName] of toolUseOpenTags.entries()) {
-				if (currentCharIndex >= tag.length - 1 && assistantMessage.startsWith(tag, currentCharIndex - tag.length + 1)) {
-					// End current text block if one was active
-					if (currentTextContent) {
-						currentTextContent.content = assistantMessage
-							.slice(
-								currentTextContentStart, // From where text started
-								currentCharIndex - tag.length + 1, // To before the tool tag starts
-							)
-							.trim()
-						currentTextContent.partial = false // Ended because tool started
-						if (currentTextContent.content.length > 0) {
-							contentBlocks.push(currentTextContent)
-						}
-						currentTextContent = undefined
-					} else {
-						// Check for any text between the last block and this tag
-						const potentialText = assistantMessage
-							.slice(
-								currentTextContentStart, // From where text *might* have started
-								currentCharIndex - tag.length + 1, // To before the tool tag starts
-							)
-							.trim()
-						if (potentialText.length > 0) {
-							contentBlocks.push({
-								type: "text",
-								content: potentialText,
-								partial: false,
-							})
-						}
-					}
-
-					// Start the new tool use
-					currentToolUse = {
-						type: "tool_use",
-						name: toolName as ToolParamName,
-						params: {},
-						partial: true, // Assume partial until closing tag is found
-						call_id: nanoid(8),
-						isNativeToolCall: false,
-					}
-					currentToolUseStart = currentCharIndex + 1 // Tool content starts after the opening tag
-					startedNewTool = true
-					break
-				}
-			}
-
-			if (startedNewTool) {
-				continue // Handled start of tool, move to next char
-			}
-
-			// If not starting a tool, it must be text content
-			if (!currentTextContent) {
-				// Start a new text block if we aren't already in one
-				currentTextContentStart = currentCharIndex // Text starts at the current character
-				// Check if the current char is the start of potential text *immediately* after a tag
-				// This needs the previous state - simpler to let slicing handle it later.
-				// Resetting start index accurately is key.
-				// It should be the index *after* the last processed tag.
-				// The logic managing currentTextContentStart after closing tags handles this.
-
-				currentTextContent = {
-					type: "text",
-					content: "", // Will be determined by slicing at the end or when a tool starts
-					partial: true,
-				}
-			}
-			// Continue accumulating text implicitly; content is extracted later.
-		}
-	} // End of loop
-
-	// --- Finalization after loop ---
-
-	// Finalize any open parameter within an open tool use
-	if (currentToolUse && currentParamName) {
-		currentToolUse.params[currentParamName] = assistantMessage
-			.slice(currentParamValueStart) // From param start to end of string
-			.trim()
-		// Tool use remains partial
-	}
-
-	// Finalize any open tool use (which might contain the finalized partial param)
-	if (currentToolUse) {
-		// Tool use is partial because the loop finished before its closing tag
-		contentBlocks.push(currentToolUse)
-	}
-	// Finalize any trailing text content
-	// Only possible if a tool use wasn't open at the very end
-	else if (currentTextContent) {
-		currentTextContent.content = assistantMessage
-			.slice(currentTextContentStart) // From text start to end of string
-			.trim()
-		// Text is partial because the loop finished
-		if (currentTextContent.content.length > 0) {
-			contentBlocks.push(currentTextContent)
-		}
-	}
-
-	return contentBlocks
-}

package/src/prompt/NodePromptManager.ts

@@ -1,276 +0,0 @@
-import { IPromptManager } from "./index";
-import { defaultTools } from "@/shared/tools";
-
-export class NodePromptManager implements IPromptManager {
-
-  async getSystemPrompt(context: { cwd: string; os: string; shell: string; skills: any; customInstructions?: string; allowDefaultTools?: string[]; customTools?: any[]; }): Promise<string> {
-    let prompt = `# Role
-you are a highly skilled software engineer AI running in a Node.js/Desktop environment.
-You have FULL access to the local file system and can execute arbitrary shell commands on the user's machine.
-
-# Capabilities & Rules
-1. **File System**: You can read, write, create, and delete files/directories anywhere accessible to the user process. Always use absolute paths or paths relative to the Current Working Directory.
-2. **Terminal**: You can execute system commands (e.g., git, npm, python, file manipulation) directly.
-3. **Context**: You are running on a real machine, meaning you have access to real environment variables, local servers (localhost), and local network.
-4. **Destructive Actions**: Be extremely careful when executing commands that modify system state or delete files. Double-check paths and commands before execution.
-5. **Step-by-step**: Use tools one at a time. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
-6. **Verification**: Always verify the result of your actions (e.g., run tests, compile code, list directories) before proceeding to the next step or completing the task.
-7. **Communication**: Be concise and technical. Formulate your output strictly according to the tools' XML specification.
-
-TOOL USE
-
-You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
-
-# Tool Use Formatting
-
-Tool use is formatted using XML-style tags. The tool name is enclosed in opening and closing tags, and each parameter is similarly enclosed within its own set of tags. Here's the structure:
-
-<tool_name>
-<parameter1_name>value1</parameter1_name>
-<parameter2_name>value2</parameter2_name>
-...
-</tool_name>
-
-For example:
-
-<agent_read_file>
-<path>src/main.js</path>
-<task_progress>
-Checklist here (optional)
-</task_progress>
-</agent_read_file>
-
-Always adhere to this format for the tool use to ensure proper parsing and execution.
-`;
-
-    const skillsPrompt = await this.getSkillsPrompt(context.skills);
-    if (skillsPrompt) {
-      prompt += `\n${skillsPrompt}\n`;
-    }
-
-    prompt += `\n${this.getToolInstructions(context)}\n`;
-
-    const envPrompt = this.getEnvironmentInfoPrompt(context);
-    if (envPrompt) {
-      prompt += `\n${envPrompt}\n`;
-    }
-
-    if (context.customInstructions) {
-      prompt += `\n# User Custom Instructions\n${context.customInstructions}\n`;
-    }
-
-    return prompt;
-  }
-
-  getEnvironmentInfoPrompt(context: { cwd: string; os: string; shell: string }): string {
-    let environmentPrompt = `<environment_details>
-  # Environment Info
-- **Current Working Directory**: \`${context.cwd}\`
-- **Operating System**: \`${context.os}\`\n`;
-    if (context.shell) {
-      environmentPrompt += `- **Current Shell**: \`${context.shell}\`\n`;
-    }
-    return environmentPrompt + `\n</environment_details>`;
-  }
-
-  async getSkillsPrompt(skills: any[]): Promise<string> {
-    if (!skills || skills.length === 0) return "";
-
-    try {
-      let prompt = `# Available Skills\n`;
-      prompt += `You have access to the following skills. You can use the \`agent_load_skill\` tool to load any of them when needed.\n`;
-      for (const skill of skills) {
-        if (skill && skill.name && skill.description) {
-          prompt += `- **${skill.name}**: ${skill.description}\n`;
-        }
-      }
-      return prompt;
-    } catch (e) {
-      // Directory might not exist or not accessible
-      return "";
-    }
-  }
-
-  getToolInstructions(context: { cwd: string; os: string; allowDefaultTools?: string[]; customTools?: any[] }): string {
-    const allowDefaultTools = context.allowDefaultTools;
-    const customTools = context.customTools || [];
-    // 可用
-    let useDefaultTools = [...defaultTools] as any[];
-    if (allowDefaultTools) {
-      useDefaultTools = defaultTools.filter((tool: any) => allowDefaultTools.includes(tool.name));
-    }
-    return `# Available Tools
-You can use the following tools by formatting your output as XML blocks. Only use ONE tool per message, and ALWAYS wait for the user's response with the execution result before proceeding.
-
-${[...useDefaultTools, ...customTools].map((tool: any) => {
-  return `### ${tool.name}
-Description: ${tool.description}
-Parameters: 
-${Object.entries(tool.params as Record<string, string>).map(([name, description]) => `- ${name}: ${description.replaceAll('${context.cwd}', context.cwd)}`).join('\n')}
-- task_progress: (optional) A checklist showing task progress after this tool use is completed. The task_progress parameter must be included as a separate parameter inside of the parent tool call, it must be separate from other parameters such as content, arguments, etc. (See 'UPDATING TASK PROGRESS' section for more details)
-Usage: 
-<${tool.name}>
-${Object.entries(tool.params  as Record<string, string>).map(([name, description]) => `<${name}>${description.replaceAll('${context.cwd}', context.cwd)}</${name}>`).join('\n')}
-<task_progress>Checklist here (optional)</task_progress>
-</${tool.name}>
-`;
-}).join('\n')}
-
-# Tool Use Examples
-${useDefaultTools.filter(item => Boolean(item.example)).map((item: any) => item.example).join('\n')}}
-
-# Tool Use Guidelines
-
-1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.
-2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like \`ls\` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
-3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
-4. Formulate your tool use using the XML format specified for each tool.
-5. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
-  - Information about whether the tool succeeded or failed, along with any reasons for failure.
-  - Linter errors that may have arisen due to the changes you made, which you'll need to address.
-  - New terminal output in reaction to the changes, which you may need to consider or act upon.
-  - Any other relevant feedback or information related to the tool use.
-6. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
-
-It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
-1. Confirm the success of each step before proceeding.
-2. Address any issues or errors that arise immediately.
-3. Adapt your approach based on new information or unexpected results.
-4. Ensure that each action builds correctly on the previous ones.
-
-By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
-
-====
-
-UPDATING TASK PROGRESS
-
-You can track and communicate your progress on the overall task using the task_progress parameter supported by every tool call. Using task_progress ensures you remain on task, and stay focused on completing the user's objective. This parameter can be used in any mode, and with any tool call.
-
-- When switching from PLAN MODE to ACT MODE, you must create a comprehensive todo list for the task using the task_progress parameter
-- Todo list updates should be done silently using the task_progress parameter - do not announce these updates to the user
-- Use standard Markdown checklist format: "- [ ]" for incomplete items and "- [x]" for completed items
-- Keep items focused on meaningful progress milestones rather than minor technical details. The checklist should not be so granular that minor implementation details clutter the progress tracking.
-- For simple tasks, short checklists with even a single item are acceptable. For complex tasks, avoid making the checklist too long or verbose.
-- If you are creating this checklist for the first time, and the tool use completes the first step in the checklist, make sure to mark it as completed in your task_progress parameter.
-- Provide the whole checklist of steps you intend to complete in the task, and keep the checkboxes updated as you make progress. It's okay to rewrite this checklist as needed if it becomes invalid due to scope changes or new information.
-- If a checklist is being used, be sure to update it any time a step has been completed.
-- The system will automatically include todo list context in your prompts when appropriate - these reminders are important.
-
-Example:
-<agent_execute_command>
-<command>npm install react</command>
-<requires_approval>false</requires_approval>
-<task_progress>
-- [x] Set up project structure
-- [x] Install dependencies
-- [ ] Create components
-- [ ] Test application
-</task_progress>
-</agent_execute_command>
-
-====
-
-EDITING FILES
-
-You have access to two tools for working with files: **agent_write_to_file** and **agent_replace_in_file**. Understanding their roles and selecting the right one for the job will help ensure efficient and accurate modifications.
-
-# agent_write_to_file
-
-## Purpose
-
-- Create a new file, or overwrite the entire contents of an existing file.
-
-## When to Use
-
-- Initial file creation, such as when scaffolding a new project.  
-- Overwriting large boilerplate files where you want to replace the entire content at once.
-- When the complexity or number of changes would make agent_replace_in_file unwieldy or error-prone.
-- When you need to completely restructure a file's content or change its fundamental organization.
-
-## Important Considerations
-
-- Using agent_write_to_file requires providing the file's complete final content.  
-- If you only need to make small changes to an existing file, consider using agent_replace_in_file instead to avoid unnecessarily rewriting the entire file.
-- While agent_write_to_file should not be your default choice, don't hesitate to use it when the situation truly calls for it.
-
-# agent_replace_in_file
-
-## Purpose
-
-- Make targeted edits to specific parts of an existing file without overwriting the entire file.
-
-## When to Use
-
-- Small, localized changes like updating a few lines, function implementations, changing variable names, modifying a section of text, etc.
-- Targeted improvements where only specific portions of the file's content needs to be altered.
-- Especially useful for long files where much of the file will remain unchanged.
-
-## Advantages
-
-- More efficient for minor edits, since you don't need to supply the entire file content.  
-- Reduces the chance of errors that can occur when overwriting large files.
-
-# Choosing the Appropriate Tool
-
-- **Default to agent_replace_in_file** for most changes. It's the safer, more precise option that minimizes potential issues.
-- **Use agent_write_to_file** when:
-  - Creating new files
-  - The changes are so extensive that using agent_replace_in_file would be more complex or risky
-  - You need to completely reorganize or restructure a file
-  - The file is relatively small and the changes affect most of its content
-  - You're generating boilerplate or template files
-
-# Auto-formatting Considerations
-
-- After using either agent_write_to_file or agent_replace_in_file, the user's editor may automatically format the file
-- This auto-formatting may modify the file contents, for example:
-  - Breaking single lines into multiple lines
-  - Adjusting indentation to match project style (e.g. 2 spaces vs 4 spaces vs tabs)
-  - Converting single quotes to double quotes (or vice versa based on project preferences)
-  - Organizing imports (e.g. sorting, grouping by type)
-  - Adding/removing trailing commas in objects and arrays
-  - Enforcing consistent brace style (e.g. same-line vs new-line)
-  - Standardizing semicolon usage (adding or removing based on style)
-- The agent_write_to_file and agent_replace_in_file tool responses will include the final state of the file after any auto-formatting
-- Use this final state as your reference point for any subsequent edits. This is ESPECIALLY important when crafting SEARCH blocks for replace_in_file which require the content to match what's in the file exactly.
-
-# Workflow Tips
-
-1. Before editing, assess the scope of your changes and decide which tool to use.
-2. For targeted edits, apply agent_replace_in_file with carefully crafted SEARCH/REPLACE blocks. If you need multiple changes, you can stack multiple SEARCH/REPLACE blocks within a single agent_replace_in_file call.
-3. IMPORTANT: When you determine that you need to make several changes to the same file, prefer to use a single replace_in_file call with multiple SEARCH/REPLACE blocks. DO NOT prefer to make multiple successive replace_in_file calls for the same file. For example, if you were to add a component to a file, you would use a single replace_in_file call with a SEARCH/REPLACE block to add the import statement and another SEARCH/REPLACE block to add the component usage, rather than making one replace_in_file call for the import statement and then another separate replace_in_file call for the component usage.
-4. For major overhauls or initial file creation, rely on agent_write_to_file.
-5. Once the file has been edited with either agent_write_to_file or agent_replace_in_file, the system will provide you with the final state of the modified file. Use this updated content as the reference point for any subsequent SEARCH/REPLACE operations, since it reflects any auto-formatting or user-applied changes.  
-By thoughtfully selecting between agent_write_to_file and agent_replace_in_file, you can make your file editing process smoother, safer, and more efficient.
-
-====
-`;
-  }
-
-  getNoUseToolInstructions(context: any): string {
-    return `[ERROR] You did not use a tool in your previous response! Please retry with a tool use.
-
-# Reminder: Instructions for Tool Use
-Tool uses are formatted using XML-style tags. The tool name is enclosed in opening and closing tags, and each parameter is similarly enclosed within its own set of tags. Here's the structure:
-<tool_name>
-<parameter1_name>value1</parameter1_name>
-<parameter2_name>value2</parameter2_name>
-...
-</tool_name>
-For example:
-<agent_attempt_completion>
-<result>
-I have completed the task...
-</result>
-</agent_attempt_completion>
-Always adhere to this format for all tool uses to ensure proper parsing and execution.
-
-# Next Steps
-
-If you have completed the user's task, use the attempt_completion tool. 
-If you require additional information from the user, use the ask_followup_question tool. 
-Otherwise, if you have not completed the task and do not need additional information, then proceed with the next step of the task. 
-(This is an automated message, so do not respond to it conversationally.)
-${this?.getEnvironmentInfoPrompt?.(context)}`;
-  }
-}