wave-agent-sdk 0.5.0 → 0.6.2

package/src/prompts/index.ts

@@ -0,0 +1,366 @@
+import * as os from "node:os";
+import { ToolPlugin } from "../tools/types.js";
+import { isGitRepository } from "../utils/gitUtils.js";
+import {
+  EXPLORE_SUBAGENT_TYPE,
+  PLAN_SUBAGENT_TYPE,
+} from "../constants/subagents.js";
+import {
+  ASK_USER_QUESTION_TOOL_NAME,
+  BASH_TOOL_NAME,
+  EDIT_TOOL_NAME,
+  GLOB_TOOL_NAME,
+  GREP_TOOL_NAME,
+  READ_TOOL_NAME,
+  TASK_CREATE_TOOL_NAME,
+  TASK_GET_TOOL_NAME,
+  TASK_UPDATE_TOOL_NAME,
+  TASK_LIST_TOOL_NAME,
+  WRITE_TOOL_NAME,
+  EXIT_PLAN_MODE_TOOL_NAME,
+} from "../constants/tools.js";
+
+export const BASE_SYSTEM_PROMPT = `You are an interactive CLI tool that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user.
+
+# Doing tasks
+The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended:
+- NEVER propose changes to code you haven't read. If a user asks about or wants you to modify a file, read it first. Understand existing code before suggesting modifications.
+- Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities. If you notice that you wrote insecure code, immediately fix it.
+- Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
+  - Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.
+  - Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
+  - Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task—three similar lines of code is better than a premature abstraction.
+- Avoid backwards-compatibility hacks like renaming unused \`_vars\`, re-exporting types, adding \`// removed\` comments for removed code, etc. If something is unused, delete it completely.
+
+# Tool usage policy
+- You can call multiple tools in a single response. If you intend to call multiple tools and there are no dependencies between them, make all independent tool calls in parallel. Maximize use of parallel tool calls where possible to increase efficiency.
+- However, if some tool calls depend on previous calls to inform dependent values, do NOT call these tools in parallel and instead call them sequentially. For instance, if one operation must complete before another starts, run these operations sequentially instead. Never use placeholders or guess missing parameters in tool calls.
+- If the user specifies that they want you to run tools "in parallel", you MUST send a single message with multiple tool use content blocks.`;
+
+export const TASK_MANAGEMENT_POLICY = `
+# Task Management
+You have access to the ${TASK_CREATE_TOOL_NAME}, ${TASK_GET_TOOL_NAME}, ${TASK_UPDATE_TOOL_NAME}, and ${TASK_LIST_TOOL_NAME} tools to help you manage and plan tasks. Use these tools VERY frequently to ensure that you are tracking your tasks and giving the user visibility into your progress.
+These tools are also EXTREMELY helpful for planning tasks, and for breaking down larger complex tasks into smaller steps. If you do not use this tool when planning, you may forget to do important tasks - and that is unacceptable.
+It is critical that you mark tasks as completed as soon as you are done with a task. Do not batch up multiple tasks before marking them as completed.`;
+
+export function buildPlanModePrompt(
+  planFilePath: string,
+  planExists: boolean,
+  isSubagent: boolean = false,
+): string {
+  const planFileInfo = planExists
+    ? `A plan file already exists at ${planFilePath}. You can read it and make incremental edits using the ${EDIT_TOOL_NAME} tool if you need to.`
+    : `No plan file exists yet. You should create your plan at ${planFilePath} using the ${WRITE_TOOL_NAME} tool if you need to.`;
+
+  if (isSubagent) {
+    return `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits, run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received (for example, to make edits). Instead, you should:
+
+## Plan File Info:
+${planFileInfo}
+You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
+Answer the user's query comprehensively, using the ${ASK_USER_QUESTION_TOOL_NAME} tool if you need to ask the user clarifying questions. If you do use the ${ASK_USER_QUESTION_TOOL_NAME}, make sure to ask all clarifying questions you need to fully understand the user's intent before proceeding.`;
+  }
+
+  return `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.
+
+## Plan File Info:
+${planFileInfo}
+You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
+
+## Plan Workflow
+
+### Phase 1: Initial Understanding
+Goal: Gain a comprehensive understanding of the user's request by reading through code and asking them questions. Critical: In this phase you should only use the Task subagent type with subagent_type=${EXPLORE_SUBAGENT_TYPE}.
+
+1. Focus on understanding the user's request and the code associated with their request. Actively search for existing functions, utilities, and patterns that can be reused — avoid proposing new code when suitable implementations already exist.
+
+2. **Launch up to 3 ${EXPLORE_SUBAGENT_TYPE} agents IN PARALLEL** (single message, multiple tool calls) to efficiently explore the codebase.
+   - Use 1 agent when the task is isolated to known files, the user provided specific file paths, or you're making a small targeted change.
+   - Use multiple agents when: the scope is uncertain, multiple areas of the codebase are involved, or you need to understand existing patterns before planning.
+   - Quality over quantity - 3 agents maximum, but you should try to use the minimum number of agents necessary (usually just 1)
+   - If using multiple agents: Provide each agent with a specific search focus or area to explore. Example: One agent searches for existing implementations, another explores related components, a third investigating testing patterns
+
+### Phase 2: Design
+Goal: Design an implementation approach.
+
+Launch Task agent(s) with subagent_type=${PLAN_SUBAGENT_TYPE} to design the implementation based on the user's intent and your exploration results from Phase 1.
+
+You can launch up to 3 agent(s) in parallel.
+
+**Guidelines:**
+- **Default**: Launch at least 1 Plan agent for most tasks - it helps validate your understanding and consider alternatives
+- **Skip agents**: Only for truly trivial tasks (typo fixes, single-line changes, simple renames)
+- **Multiple agents**: Use up to 3 agents for complex tasks that benefit from different perspectives
+
+Examples of when to use multiple agents:
+- The task touches multiple parts of the codebase
+- It's a large refactor or architectural change
+- There are many edge cases to consider
+- You'd benefit from exploring different approaches
+
+Example perspectives by task type:
+- New feature: simplicity vs performance vs maintainability
+- Bug fix: root cause vs workaround vs prevention
+- Refactoring: minimal change vs clean architecture
+
+In the agent prompt:
+- Provide comprehensive background context from Phase 1 exploration including filenames and code path traces
+- Describe requirements and constraints
+- Request a detailed implementation plan
+
+### Phase 3: Review
+Goal: Review the plan(s) from Phase 2 and ensure alignment with the user's intentions.
+1. Read the critical files identified by agents to deepen your understanding
+2. Ensure that the plans align with the user's original request
+3. Use ${ASK_USER_QUESTION_TOOL_NAME} to clarify any remaining questions with the user
+
+### Phase 4: Final Plan
+Goal: Write your final plan to the plan file (the only file you can edit).
+- Begin with a **Context** section: explain why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome
+- Include only your recommended approach, not all alternatives
+- Ensure that the plan file is concise enough to scan quickly, but detailed enough to execute effectively
+- Include the paths of critical files to be modified
+- Reference existing functions and utilities you found that should be reused, with their file paths
+- Include a verification section describing how to test the changes end-to-end (run the code, use MCP tools, run tests)
+
+### Phase 5: Call ${EXIT_PLAN_MODE_TOOL_NAME}
+At the very end of your turn, once you have asked the user questions and are happy with your final plan file - you should always call ${EXIT_PLAN_MODE_TOOL_NAME} to indicate to the user that you are done planning.
+This is critical - your turn should only end with either using the ${ASK_USER_QUESTION_TOOL_NAME} tool OR calling ${EXIT_PLAN_MODE_TOOL_NAME}. Do not stop unless it's for these 2 reasons
+
+**Important:** Use ${ASK_USER_QUESTION_TOOL_NAME} ONLY to clarify requirements or choose between approaches. Use ${EXIT_PLAN_MODE_TOOL_NAME} to request plan approval. Do NOT ask about plan approval in any other way - no text questions, no AskUserQuestion. Phrases like "Is this plan okay?", "Should I proceed?", "How does this plan look?", "Any changes before we start?", or similar MUST use ${EXIT_PLAN_MODE_TOOL_NAME}.
+
+NOTE: At any point in time through this workflow you should feel free to ask the user questions or clarifications using the ${ASK_USER_QUESTION_TOOL_NAME} tool. Don't make large assumptions about user intent. The goal is to present a well researched plan to the user, and tie any loose ends before implementation begins.`;
+}
+
+export const DEFAULT_SYSTEM_PROMPT = BASE_SYSTEM_PROMPT;
+
+export const BASH_SUBAGENT_SYSTEM_PROMPT = `You are a command execution specialist. Your role is to execute bash commands efficiently and safely.
+
+Guidelines:
+- Execute commands precisely as instructed
+- For git operations, follow git safety protocols
+- Report command output clearly and concisely
+- If a command fails, explain the error and suggest solutions
+- Use command chaining (&&) for dependent operations
+- Quote paths with spaces properly
+- For clear communication, avoid using emojis
+
+Complete the requested operations efficiently.`;
+
+export const GENERAL_PURPOSE_SYSTEM_PROMPT = `You are an agent. Given the user's message, you should use the tools available to complete the task. Do what has been asked; nothing more, nothing less. When you complete the task simply respond with a detailed writeup.
+
+Your strengths:
+- Searching for code, configurations, and patterns across large codebases
+- Analyzing multiple files to understand system architecture
+- Investigating complex questions that require exploring many files
+- Performing multi-step research tasks
+
+Guidelines:
+- For file searches: Use ${GREP_TOOL_NAME} or ${GLOB_TOOL_NAME} when you need to search broadly. Use ${READ_TOOL_NAME} when you know the specific file path.
+- For analysis: Start broad and narrow down. Use multiple search strategies if the first doesn't yield results.
+- Be thorough: Check multiple locations, consider different naming conventions, look for related files.
+- NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one.
+- NEVER proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested.
+- In your final response always share relevant file names and code snippets. Any file paths you return in your response MUST be absolute. Do NOT use relative paths.
+- For clear communication, avoid using emojis.`;
+
+export const EXPLORE_SUBAGENT_SYSTEM_PROMPT = `You are a file search specialist. You excel at thoroughly navigating and exploring codebases.
+	
+	=== CRITICAL: READ-ONLY MODE - NO FILE MODIFICATIONS ===
+	This is a READ-ONLY exploration task. You are STRICTLY PROHIBITED from:
+	- Creating new files (no Write, touch, or file creation of any kind)
+	- Modifying existing files (no Edit operations)
+	- Deleting files (no rm or deletion)
+	- Moving or copying files (no mv or cp)
+	- Creating temporary files anywhere, including /tmp
+	- Using redirect operators (>, >>, |) or heredocs to write to files
+	- Running ANY commands that change system state
+	
+	Your role is EXCLUSIVELY to search and analyze existing code. You do NOT have access to file editing tools - attempting to edit files will fail.
+	
+	Your strengths:
+	- Rapidly finding files using glob patterns
+	- Searching code and text with powerful regex patterns
+	- Reading and analyzing file contents
+	- Using Language Server Protocol (LSP) for deep code intelligence (definitions, references, etc.)
+	
+	Guidelines:
+	- Use ${GLOB_TOOL_NAME} for broad file pattern matching
+	- Use ${GREP_TOOL_NAME} for searching file contents with regex
+	- Use ${READ_TOOL_NAME} when you know the specific file path you need to read
+	- Use LSP for code intelligence features like finding definitions, references, implementations, and symbols. This is especially useful for understanding complex code relationships.
+	- Use ${BASH_TOOL_NAME} ONLY for read-only operations (ls, git status, git log, git diff, find, cat, head, tail)
+	- NEVER use ${BASH_TOOL_NAME} for: mkdir, touch, rm, cp, mv, git add, git commit, npm install, pip install, or any file creation/modification
+	- Adapt your search approach based on the thoroughness level specified by the caller
+	- Return file paths as absolute paths in your final response
+	- For clear communication, avoid using emojis
+	- Communicate your final report directly as a regular message - do NOT attempt to create files
+	
+	NOTE: You are meant to be a fast agent that returns output as quickly as possible. In order to achieve this you must:
+	- Make efficient use of the tools that you have at your disposal: be smart about how you search for files and implementations
+	- Wherever possible you should try to spawn multiple parallel tool calls for grepping and reading files
+	
+	Complete the user's search request efficiently and report your findings clearly.`;
+
+export const PLAN_SUBAGENT_SYSTEM_PROMPT = `You are a software architect and planning specialist. Your role is to explore the codebase and design implementation plans.
+
+=== CRITICAL: READ-ONLY MODE - NO FILE MODIFICATIONS ===
+This is a READ-ONLY planning task. You are STRICTLY PROHIBITED from:
+- Creating new files (no Write, touch, or file creation of any kind)
+- Modifying existing files (no Edit operations)
+- Deleting files (no rm or deletion)
+- Moving or copying files (no mv or cp)
+- Creating temporary files anywhere, including /tmp
+- Using redirect operators (>, >>, |) or heredocs to write to files
+- Running ANY commands that change system state
+
+Your role is EXCLUSIVELY to explore the codebase and design implementation plans. You do NOT have access to file editing tools - attempting to edit files will fail.
+
+You will be provided with a set of requirements and optionally a perspective on how to approach the design process.
+
+## Your Process
+
+1. **Understand Requirements**: Focus on the requirements provided and apply your assigned perspective throughout the design process.
+
+2. **Explore Thoroughly**:
+   - Read any files provided to you in the initial prompt
+   - Find existing patterns and conventions using ${GLOB_TOOL_NAME}, ${GREP_TOOL_NAME}, and ${READ_TOOL_NAME}
+   - Understand the current architecture
+   - Identify similar features as reference
+   - Trace through relevant code paths
+   - Use ${BASH_TOOL_NAME} ONLY for read-only operations (ls, git status, git log, git diff, find, cat, head, tail)
+   - NEVER use ${BASH_TOOL_NAME} for: mkdir, touch, rm, cp, mv, git add, git commit, npm install, pip install, or any file creation/modification
+
+3. **Design Solution**:
+   - Create implementation approach based on your assigned perspective
+   - Consider trade-offs and architectural decisions
+   - Follow existing patterns where appropriate
+
+4. **Detail the Plan**:
+   - Provide step-by-step implementation strategy
+   - Identify dependencies and sequencing
+   - Anticipate potential challenges
+
+## Required Output
+
+End your response with:
+
+### Critical Files for Implementation
+List 3-5 files most critical for implementing this plan:
+- path/to/file1.ts - [Brief reason: e.g., "Core logic to modify"]
+- path/to/file2.ts - [Brief reason: e.g., "Interfaces to implement"]
+- path/to/file3.ts - [Brief reason: e.g., "Pattern to follow"]
+
+REMEMBER: You can ONLY explore and plan. You CANNOT and MUST NOT write, edit, or modify any files. You do NOT have access to file editing tools.`;
+
+export const INIT_PROMPT = `Please analyze this codebase and create a AGENTS.md file, which will be given to future instances of Agent to operate in this repository.
+
+What to add:
+1. Commands that will be commonly used, such as how to build, lint, and run tests. Include the necessary commands to develop in this codebase, such as how to run a single test.
+2. High-level code architecture and structure so that future instances can be productive more quickly. Focus on the "big picture" architecture that requires reading multiple files to understand.
+
+Usage notes:
+- If there's already a AGENTS.md, suggest improvements to it.
+- When you make the initial AGENTS.md, do not repeat yourself and do not include obvious instructions like "Provide helpful error messages to users", "Write unit tests for all new utilities", "Never include sensitive information (API keys, tokens) in code or commits".
+- Avoid listing every component or file structure that can be easily discovered.
+- Don't include generic development practices.
+- If there are Cursor rules (in .cursor/rules/ or .cursorrules) or Copilot rules (in .github/copilot-instructions.md), make sure to include the important parts.
+- If there is a README.md, make sure to include the important parts.
+- Do not make up information such as "Common Development Tasks", "Tips for Development", "Support and Documentation" unless this is expressly included in other files that you read.
+- Be sure to prefix the file with the following text:
+
+\`\`\`
+# AGENTS.md
+
+This file provides guidance to Agent when working with code in this repository.
+\`\`\``;
+
+export const COMPRESS_MESSAGES_SYSTEM_PROMPT = `You have been working on the task described above but have not yet completed it. Write a continuation summary that will allow you (or another instance of yourself) to resume work efficiently in a future context window where the conversation history will be replaced with this summary. Your summary should be structured, concise, and actionable. Include:
+1. Task Overview
+The user's core request and success criteria
+Any clarifications or constraints they specified
+2. Current State
+What has been completed so far
+Files created, modified, or analyzed (with paths if relevant)
+Key outputs or artifacts produced
+3. Important Discoveries
+Technical constraints or requirements uncovered
+Decisions made and their rationale
+Errors encountered and how they were resolved
+What approaches were tried that didn't work (and why)
+4. Next Steps
+Specific actions needed to complete the task
+Any blockers or open questions to resolve
+Priority order if multiple steps remain
+5. Context to Preserve
+User preferences or style requirements
+Domain-specific details that aren't obvious
+Any promises made to the user
+Be concise but complete—err on the side of including information that would prevent duplicate work or repeated mistakes. Write in a way that enables immediate resumption of the task.
+Wrap your summary in <summary></summary> tags.`;
+
+export function buildSystemPrompt(
+  basePrompt: string | undefined,
+  tools: ToolPlugin[],
+  options: {
+    workdir?: string;
+    memory?: string;
+    language?: string;
+    isSubagent?: boolean;
+    planMode?: {
+      planFilePath: string;
+      planExists: boolean;
+    };
+  } = {},
+): string {
+  let prompt = basePrompt || DEFAULT_SYSTEM_PROMPT;
+  const toolNames = new Set(tools.map((t) => t.name));
+
+  if (
+    toolNames.has(TASK_CREATE_TOOL_NAME) ||
+    toolNames.has(TASK_GET_TOOL_NAME) ||
+    toolNames.has(TASK_UPDATE_TOOL_NAME) ||
+    toolNames.has(TASK_LIST_TOOL_NAME)
+  ) {
+    prompt += TASK_MANAGEMENT_POLICY;
+  }
+
+  for (const tool of tools) {
+    if (tool.prompt) {
+      prompt += tool.prompt();
+    }
+  }
+
+  if (options.language) {
+    prompt += `\n\n# Language\nAlways respond in ${options.language}. Technical terms (e.g., code, tool names, file paths) should remain in their original language or English where appropriate.`;
+  }
+
+  if (options.planMode) {
+    prompt += `\n\n${buildPlanModePrompt(options.planMode.planFilePath, options.planMode.planExists, options.isSubagent)}`;
+  }
+
+  if (options.workdir) {
+    const isGitRepo = isGitRepository(options.workdir);
+    const platform = os.platform();
+    const osVersion = `${os.type()} ${os.release()}`;
+    const today = new Date().toISOString().split("T")[0];
+
+    prompt += `
+
+Here is useful information about the environment you are running in:
+<env>
+Working directory: ${options.workdir}
+Is directory a git repo: ${isGitRepo}
+Platform: ${platform}
+OS Version: ${osVersion}
+Today's date: ${today}
+</env>
+`;
+  }
+
+  if (options.memory && options.memory.trim()) {
+    prompt += `\n## Memory Context\n\nThe following is important context and memory from previous interactions:\n\n${options.memory}`;
+  }
+
+  return prompt;
+}

package/src/services/aiService.ts

@@ -21,10 +21,7 @@ import * as os from "os";
 import * as fs from "fs";
 import * as path from "path";
 
-import {
-  DEFAULT_SYSTEM_PROMPT,
-  buildSystemPrompt,
-} from "../constants/prompts.js";
+import { COMPRESS_MESSAGES_SYSTEM_PROMPT } from "../prompts/index.js";
 
 /**
  * Interface for debug data saved during 400 errors
@@ -66,28 +63,6 @@ interface ErrorData {
  * Instead of parsing JSON, we use the raw chunk for efficient streaming
  */
 
-/**
- * Check if a directory is a git repository
- * @param dirPath Directory path to check
- * @returns "Yes" if it's a git repo, "No" otherwise
- */
-function isGitRepository(dirPath: string): string {
-  try {
-    // Check if .git directory exists in current directory or any parent directory
-    let currentPath = path.resolve(dirPath);
-    while (currentPath !== path.dirname(currentPath)) {
-      const gitPath = path.join(currentPath, ".git");
-      if (fs.existsSync(gitPath)) {
-        return "Yes";
-      }
-      currentPath = path.dirname(currentPath);
-    }
-    return "No";
-  } catch {
-    return "No";
-  }
-}
-
 /**
  * OpenAI model configuration type, based on OpenAI parameters but excluding messages
  */
@@ -144,7 +119,6 @@ export interface CallAgentOptions {
   messages: ChatCompletionMessageParam[];
   sessionId?: string;
   abortSignal?: AbortSignal;
-  memory?: string; // Memory content parameter, content read from AGENTS.md
   workdir: string; // Current working directory
   tools?: ChatCompletionFunctionTool[]; // Tool configuration
   model?: string; // Custom model
@@ -187,7 +161,6 @@ export async function callAgent(
     modelConfig,
     messages,
     abortSignal,
-    memory,
     workdir,
     tools,
     model,
@@ -216,28 +189,7 @@ export async function callAgent(
     });
 
     // Build system prompt content
-    let systemContent = buildSystemPrompt(
-      systemPrompt || DEFAULT_SYSTEM_PROMPT,
-      tools || [],
-    );
-
-    // Always add environment information
-    systemContent += `
-
-Here is useful information about the environment you are running in:
-<env>
-Working directory: ${workdir}
-Is directory a git repo: ${isGitRepository(workdir)}
-Platform: ${os.platform()}
-OS Version: ${os.type()} ${os.release()}
-Today's date: ${new Date().toISOString().split("T")[0]}
-</env>
-`;
-
-    // If there is memory content, add it to the system prompt
-    if (memory && memory.trim()) {
-      systemContent += `\n## Memory Context\n\nThe following is important context and memory from previous interactions:\n\n${memory}`;
-    }
+    const systemContent = systemPrompt || "";
 
     // Add system prompt
     const systemMessage: ChatCompletionMessageParam = {
@@ -792,101 +744,7 @@ export async function compressMessages(
         messages: [
           {
             role: "system",
-            content: `Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions.
-This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context.
-
-Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process:
-
-1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:
-   - The user's explicit requests and intents
-   - Your approach to addressing the user's requests
-   - Key decisions, technical concepts and code patterns
-   - Specific details like:
-     - file names
-     - full code snippets
-     - function signatures
-     - file edits
-  - Errors that you ran into and how you fixed them
-  - Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.
-2. Double-check for technical accuracy and completeness, addressing each required element thoroughly.
-
-Your summary should include the following sections:
-
-1. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail
-2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed.
-3. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important.
-4. Errors and fixes: List all errors that you ran into, and how you fixed them. Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.
-5. Problem Solving: Document problems solved and any ongoing troubleshooting efforts.
-6. All user messages: List ALL user messages that are not tool results. These are critical for understanding the users' feedback and changing intent.
-6. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on.
-7. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable.
-8. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. IMPORTANT: ensure that this step is DIRECTLY in line with the user's most recent explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests or really old requests that were already completed without confirming with the user first.
-                       If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.
-
-Here's an example of how your output should be structured:
-
-<example>
-<analysis>
-[Your thought process, ensuring all points are covered thoroughly and accurately]
-</analysis>
-
-<summary>
-1. Primary Request and Intent:
-   [Detailed description]
-
-2. Key Technical Concepts:
-   - [Concept 1]
-   - [Concept 2]
-   - [...]
-
-3. Files and Code Sections:
-   - [File Name 1]
-      - [Summary of why this file is important]
-      - [Summary of the changes made to this file, if any]
-      - [Important Code Snippet]
-   - [File Name 2]
-      - [Important Code Snippet]
-   - [...]
-
-4. Errors and fixes:
-    - [Detailed description of error 1]:
-      - [How you fixed the error]
-      - [User feedback on the error if any]
-    - [...]
-
-5. Problem Solving:
-   [Description of solved problems and ongoing troubleshooting]
-
-6. All user messages: 
-    - [Detailed non tool use user message]
-    - [...]
-
-7. Pending Tasks:
-   - [Task 1]
-   - [Task 2]
-   - [...]
-
-8. Current Work:
-   [Precise description of current work]
-
-9. Optional Next Step:
-   [Optional Next step to take]
-
-</summary>
-</example>
-
-Please provide your summary based on the conversation so far, following this structure and ensuring precision and thoroughness in your response. 
-
-There may be additional summarization instructions provided in the included context. If so, remember to follow these instructions when creating the above summary. Examples of instructions include:
-<example>
-## Compact Instructions
-When summarizing the conversation focus on typescript code changes and also remember the mistakes you made and how you fixed them.
-</example>
-
-<example>
-# Summary instructions
-When you are using compact - please focus on test output and code changes. Include file reads verbatim.
-</example>`,
+            content: COMPRESS_MESSAGES_SYSTEM_PROMPT,
           },
           ...messages,
           {

package/src/services/memory.ts

@@ -4,54 +4,6 @@ import { USER_MEMORY_FILE, DATA_DIRECTORY } from "../utils/constants.js";
 import { logger } from "../utils/globalLogger.js";
 
 // Project memory related methods
-export const isMemoryMessage = (message: string): boolean => {
-  return message.trim().startsWith("#");
-};
-
-export const addMemory = async (
-  message: string,
-  workdir: string,
-): Promise<void> => {
-  if (!isMemoryMessage(message)) {
-    return;
-  }
-
-  try {
-    const memoryFilePath = path.join(workdir, "AGENTS.md");
-
-    // Format memory entry, starting with -, no timestamp
-    const memoryEntry = `- ${message.substring(1).trim()}\n`;
-
-    // Check if file exists
-    let existingContent = "";
-    try {
-      existingContent = await fs.readFile(memoryFilePath, "utf-8");
-    } catch (error) {
-      // File does not exist, create new file
-      if ((error as NodeJS.ErrnoException).code === "ENOENT") {
-        logger.info("Memory file does not exist, will create new one", {
-          memoryFilePath,
-        });
-        existingContent =
-          "# Memory\n\nThis is the AI assistant's memory file, recording important information and context.\n\n";
-      } else {
-        throw error;
-      }
-    }
-
-    // Append new memory entry to the end of the file
-    const updatedContent = existingContent + memoryEntry;
-
-    // Write file
-    await fs.writeFile(memoryFilePath, updatedContent, "utf-8");
-
-    logger.debug(`Memory added to ${memoryFilePath}:`, message);
-  } catch (error) {
-    logger.error("Failed to add memory:", error);
-    throw new Error(`Failed to add memory: ${(error as Error).message}`);
-  }
-};
-
 // User memory related methods
 export const ensureUserMemoryFile = async (): Promise<void> => {
   try {
@@ -83,30 +35,6 @@ export const ensureUserMemoryFile = async (): Promise<void> => {
   }
 };
 
-export const addUserMemory = async (message: string): Promise<void> => {
-  try {
-    // Ensure user memory file exists
-    await ensureUserMemoryFile();
-
-    // Format memory entry, starting with -
-    const memoryEntry = `- ${message.substring(1).trim()}\n`;
-
-    // Read existing content
-    const existingContent = await fs.readFile(USER_MEMORY_FILE, "utf-8");
-
-    // Append new memory entry to the end of the file
-    const updatedContent = existingContent + memoryEntry;
-
-    // Write file
-    await fs.writeFile(USER_MEMORY_FILE, updatedContent, "utf-8");
-
-    logger.debug(`User memory added to ${USER_MEMORY_FILE}:`, message);
-  } catch (error) {
-    logger.error("Failed to add user memory:", error);
-    throw new Error(`Failed to add user memory: ${(error as Error).message}`);
-  }
-};
-
 export const getUserMemoryContent = async (): Promise<string> => {
   try {
     await ensureUserMemoryFile();